阿里巴巴容量规划设计初步说明

针对今天容量规划沙龙由于时间关系没有回答的问题--阿里巴巴的容量规划设计方案，做一个简单的说明。
呵呵，我去年10月份这个问题写了很长的技术方案书。大致思路如下

容量规划方案贯穿软件开发整个流程。
针对已经上线运行的系统

1) 性能需求： 从数据仓库平台或者web 日志分析工具awstats分析access_log日志得到用户访问模型；
从监控中心(cacti 和nigos ) 获取服务器资源消耗数据，如cpu,io,内存，网络等细节，得到系统资源消耗模型。
如果要求更细致的颗粒，可以在应用层加以监控，如jmx获取JVM 的性能；oracle db 通过statspack获取性能       

2) 性能测试与监控

  建立性能测试场景（用户、数据量、硬件、软件系统等)，执行性能测试；获取当前系统的承受负荷以及获取临界值。
  经过确认，系统经过良好调优、且无伸缩性问题后。可以按照容量规划理论来看，寻求伸缩因子。其=1/(1-利用率%)。

  比如找到瓶颈资源临界点，如50%资源消耗，75%资源消耗。一旦伸缩因子>2后，容量预测的估计偏差难以估计，因为已经不是线性关系
   
3) 建模以及预测
  
   采用开源工具java model tool或者 pdq （2工具可以从sourceforge.net下载) ，建立客户到达时间分布与服务时间分布等众多容量规划参数，模型可以选择排队网络。流程：建模->MVA求解- 与性能测试结果对比校准模型,迭代逼近误差容忍范围。

  what-if 预测可以从 增加并发数、合并/拆分应用、变更硬件等角度考虑

  呵呵，当然也可以尝试找teamquest临时 license。


针对新开发系统：

1） 性能需求： 可以定义得更加苛刻一些。
    参考同类系统，初步用TPCC 等参数比较。

    实际上，这样可能误差较大。
    另外，需要架构师评估系统是否有代码保证最大连接数限制
        
2)  性能测试与监控

     场景细分更加细致，获取新系统承受负荷以及获取临界值。

3)  建模与预测
     
     模型校准的工作量比较大。
     需要长期与生产系统实际的用户行为、系统资源消耗、响应时间、吞吐率等SLA指标比较，修正容量规划模型。
这个过程可能很漫长。