前两文，分别介绍了访问量以及性能指标的概念，回顾如下：
再次总结下：
parameters of load ： 访问量的衡量
requests per second 每秒处理多少请求，平均值和峰值
one request completed in seconds 一次请求花费多少时间
metrics to measure the performance - percentile 性能衡量指标
多少请求落在中位数响应时间之下？50%的请求，其实没有意义。
多少请求落在99%响应时间之下？99%的请求，落在这个响应时间之下！
更多的时候，是先求得99%的响应时间，再出报告。只有从实际请求的统计中求得50%,95%,99%的response time 才可以对我们的系统性能做出准确的阐述。
比如 50%的请求，响应时间在200ms以下，95%的请求，响应时间在 500ms以下，99%的请求，响应时间在 1.5s以下，而这些响应时间，是由log 做记录，统计出来的。
对付性能问题，主要有两种做法
1 scaling up 换一台高性能的计算机，比如Oracle Extract One。不足的地方是，性能超好的一体机，价格也贵。而且不能一遇到性能问题，就通过换机器来解决，也没有办法在线直接扩展，必须有停机时间，通过上线部署，完成性能的扩容；
2 scaling out 换一群计算机来满足并发的需求。不足之处是增加了复杂度，使得维护变得极其困难。好处是在线扩容性能强劲，不浪费前期的投资。
对付性能问题，没有统一不变的架构，没有银弹！
比如每秒 12000次请求，每次 1K 数据量，和每分钟 3 次请求，每次 2GB 的数据量，在架构与设计上，就完全不同。所以具体问题还得具体分析。
在设计构架的时候，还是有些共同之处，普适的共性需要考虑的：
Maintainability ( 可维护性 )
软件的成本，最大部分不是来自于开发阶段，而是之后的维护期，这是一项共识。保证软件系统的健壮性，控制服务可用的时间，减少故障等待的时间，为扩展寻找合适的解决方案，都是需要开发之后考虑的问题。
operability 可操作性: 一个普遍的认识就是，优秀的软件，由于人为的误操作，也变得不能顺利使用；而一个糟糕的软件，由于规范了操作流程，也变得好用起来。有很多措施可以帮助提高软件的操作型，比如自动化的工具，流程文档的规范以及故障可恢复性。
simplicity 简单化：写一个软件不能可从到尾都是用汇编语言来写，中间会使用不同的语言，各个语言负责自己最强的部分，比如底层语言负责与操作系统交互，而高级语言，比如SQL，就负责业务层面的操作，从而封装了机器语言的复杂性。所以使软件简单化的一种工具，就是增加抽象。
evolvability 可进化性：软件系统开发完毕之后 ，不可能从业务一开始就一直支持业务蒸蒸日上的发展，针对以前的架构，需要与时俱进的提高软件的适配性，来应付业务的需要。所以可进化性，要做的事情就是简单扩展就能支持新业务的开展。比如 Agile 的 TDD(测试驱动开发） 和 Refactoring（重构）.