愿君学长松,慎勿作桃李。这篇文章主要讲述高可用之容量设计相关的知识,希望能为你提供帮助。
1.容量预估容量预估是架构师必备的技能之一。所谓容量预估,就是系统在被压垮之前所能承受的最大业务负载,这是技术人员了解系统性能的重要指标。容量预估一般通过全链路压测、线性分析、相似类比、经验判断等多种手段,综合评估当前应用系统所能承载的业务容量。业务容量是指针对特定业务场景,系统所能处理的峰值每秒事务数(Transactions Per Second,TPS)、吞吐量、响应时间(Reaction Time,RT)等性能指标。
- 峰值TPS:后台系统不被压垮的前提下系统每秒最多能够接收多大的前端并发请求量。
- 吞吐量:系统每秒最多能够处理的业务量,其与TPS是两个不同的含义。TPS是指系统每秒能够接收的请求量,而吞吐量则真正反映系统的处理能力。
- 响应时间:所有的容量预估都必须确保系统的RT在业务可接受的范围内,RT如果超出这个范围,即便系统能够处理更多的请求,也没什么意义。
容量测试是性能测试里的一种测试方法,目的是测量系统的最大容量,为系统扩容、性能优化提供参考,节省成本投入,提高资源利用率。由于测试环境跟生产环境的差异性(包括服务器差异、网络差异、数据差异、流量差异),因此测试环境下通过压测得出的系统容量并不能完全真实地体现生产环境下的处理能力。在测试环境压测,首先需要考虑硬件环境能否做到跟生产环境的等比配置,如果成本不允许,可以按一定比例缩小,然后根据线性分析的结果测算出测试环境跟生产环境的容量比例。在测试环境压测时,压测数据(包括打底数据和流量请求数据)尽可能采用生产环境脱敏后的真实数据,以提高测试场景的业务覆盖度。
2.容量规划容量规划是在容量预估的基础上,根据业务的发展规划,指出为了适应业务发展的需要,未来系统所能承受的业务容量规模,以及为了达到这样的容量规模,系统需要经过什么样的投入和改造。要完成容量规划,必须要做的3件事如下:
- 找出系统瓶颈点。应用系统生产环境一般是由网络设备、Web服务器、消息队列、缓存、数据库等组成的一系列复杂集群。在分布式系统中,任何节点出现瓶颈,都有可能导致雪崩效应,最后整个集群垮掉(雪崩效应是指系统中一个小问题会逐渐扩大,最后造成整个集群死机)。所以,要规划整个平台的容量,就必须计算出每一个节点的容量,找出任何可能出现的瓶颈所在。
- 线性分析。根据系统架构(集群、分布式、微服务)特点,通过多轮的对比压测得到资源节点的增加(尤其瓶颈点的资源增加)和系统性能提升的线性比例关系。通过线上采集的系统数据,分析出过去某段时间(或某个业务)的高峰流量,然后通过计算得到扩容所需投入的实际资源数量。
- 容量应急预案。根据压测的结果,设定限流、服务降级等系统保护措施,来预防当实际流量超过系统所能承受的最大流量时系统无法提供服务。
推荐阅读
- (OK) 编译cBPM-android—CentOS 7—NDK8—androideabi-4.7— API14
- SharePoint 2010 权限管理
- "三关" + "一关"
- (OK) 编译xerces-c-3.1.2(静态库)—CentOS 7— android-ndk
- 欢迎进入 Windows8 的世界!
- 和学生们的合影-20160522-chenqingy-zhaoq
- (OK) 编译xerces-c-3.1.2(动态库)—CentOS 7— android-ndk
- 开发 Windows 8 应用 - 0 - windows 8 开发资源
- DRT移植各种成熟稳定的C工具包到DELPHI