甄品速览丨如何在海量数据及高并发下保证系统的高可用性？

1.服务器资源易扩展性

OP产品：服务器资源一次性购买，很难快速扩展。
SaaS产品：可以根据实际使用情况按需自动化分配。

2.性能满足方式

OP产品：由于服务器资源是一次性购买很难快速扩展，所以通常采取预估数年后系统最大并发数及业务数据量，进行一次性性能测试，以满足未来数年随着用户数及业务数据量不断增长对系统带来的重大性能挑战。

SaaS产品：由于服务器资源可以根据实际使用情况按需自动化分配，所以通常有两种方式来满足随着用户数及业务数据量不断增长对系统带来的重大性能挑战。一种是根据系统负载情况自动水平扩展硬件资源直线提升系统性能(硬件可以及时扩展，系统架构支持水平扩展。所能支撑的并发可以及时扩展)。另外一种是定期性能测试(根据未来一段时间客户增长情况进行定期性能测试)。

02 性能测试的难点

性能测试的原理并不复杂，但要想切实发挥其作用，还是会面临诸多难点：

1.测试覆盖度很难度量

因客户所属行业、组织形态、管理模式和业务类型等要素的天然差异性，客户对SaaS产品存在海量的应用场景及业务功能的使用，如果对这些业务功能进行枚举会得到一个非常庞大的性能测试清单，考虑到人力及时间成本这种穷举性的测试几乎是不可能的，这就需要有科学的性能测试用例设计方法作为支撑。

2.性能指标很难设定

每个业务功能的性能指标必须基于并发用户数、数据库垫底业务数据量、每次业务操作数据量来进行设定，SaaS产品客户数众多，对每个业务功能的使用频次、完成业务操作所需及产生的业务数据量都大相径庭，而且SaaS产品的客户会不断增加，对各业务功能的使用也会不断变化，这使得各业务功能性能指标设定的难度非常巨大，因此需要完备的性能指标评估体系。

3.性能测试数据很难模拟

数据库垫底业务数据量、业务数据分布、每次业务操作数据量及数据结构对性能影响非常大，不同场景设置多少垫底业务数据量、业务数据如何分布，不同业务场景每次业务操作数据量设定多少行、构造怎样的数据结构就变得至关重要，同时也给性能测试数据模拟带来了极大的难度。

03 甄云数字化采购平台性能测试是怎么做的

1.科学的方法构建性能测试场景

现有功能会根据业务经验梳理出核心场景、数据量大存在一定性能风险的场景作为初始性能测试场景。同时甄云有一整套用于完善产品、持续提升用户对产品的使用体验的监控体系分析用户行为，基于该监控系统拉取各模块各功能访问次数(PV)，选择高PV和响应较慢的功能作为补充性能测试场景。

对于扩展的新场景首先会从业务设计视角考虑用户使用场景、使用频率、操作数据量、一定时间内可能产生的业务数据量等识别出需要纳入性能测试的场景，新场景上线后也会借助监控工具对性能测试场景不断补充完善。

最终形成一份较为全面且不断迭代更新的全量性能测试场景清单。这样既保证了现有功能也兼顾了新场景，同时覆盖了核心场景、大数据量、用户高频操作、慢响应等业务。

2.完备的性能指标评估体系

不同场景使用频率不同，可能面临的并发数不同，场景复杂度不同，要求的响应时间不同。甄云基于监控拉取历史各场景的并发数并做较大上浮作为对应场景测试的最低档并发数，并且为了应对突发场景以及未来不断增大的用户体量，我们同时会进行最大并发测试。最终得到不同场景差异化的阶梯式并发数与响应时间等指标要求。 

3.合理的性能测试模拟数据

垫底数据：不同的垫底数据量、不同的数据分布对性能影响极大，因此需要尽量模拟真实的数据量与数据分布。甄云首先基于监控系统拉取性能测试场景各功能高频执行的SQL，分析SQL得到哪些维度会影响程序性能，然后评估各维度的数据分布，最后得到各单据各维度的数据分布要求，据此在性能测试专用环境构造垫底数据。

测试数据：一次性操作的数据量显著影响程序响应时间，为了模拟用户批量操作的场景，测试脚本都是进行多行操作，基于各场景的特点来评估一次性操作的行数。

部署架构：性能测试专用环境完全模拟生产环境的部署架构与服务器配置。

以上是甄云科技在性能测试的分享，目前该系列已经推出了“基线测试”和“性能测试”两个专题，后续将继续带来测试领域又一项挑战“体验性测试”