比如国内发生了重大事件，用户量陡增，监控系统能够及时识别出用户量监控曲线一个非常明显的跳跃过程（比如持续事件超过某个值，且曲线斜率超过某个值），发出告警，并且自动扩容来应付潜在的风险。这些，都是建立在常规的业务运营数据收集基础之上的，然后需要做数据挖掘，给出关键点。
再比如互联网应用“缓存为王”。对于缓存的设计，甚至很大程度上决定了应用的成败（如果你很有钱，靠大量的CDN这种非常规路线的另说，呵呵）。缓存的设计需要考虑到缓存的大小、分级、队列、命中率计算、生命周期、更新换页、数据分发、数据一致性和数据持久化等等问题，这些东西往往被很多只重视那些页面展示效果和功能的人所忽视，但如果你是优秀的设计者，你需要积累这些思考。
Think big。有这样一个真实的例子，我们曾经发现页面模板的OGNL性能不高（两次反射之故），遂在项目中把大部分OGNL表达式都改成了EL表达式，花了很多时间精力，性能也确实提高了，但是能提高多少呢？大概只有30%，这是一种细水长流的改进，对系统的破坏性不大，但是收效也不足以令人沾沾自喜，还失去了一些OGNL的灵活性。之后，我们换了一个思路，从大局入手，给页面划分区域，定制缓存框架，引入页面缓存能力，虽然整套方案有些复杂，但是这种架构上的进化，由于页面的生成或者部分生成直接命中了缓存文件，性能一下有了飞跃，提高了600%~800%。这就是Think big，从大处着想，见得到工程大块的结构，需要足够的视野、足够的经验和积累，可以带来显著的效果。
通常系统容量的设计都会要求到峰值容量以上，如果是像秒杀、抢购之类对性能要求非常高的系统，往往还存在一个问题：设计了这么大的容量，平时大部分时间业务量都比较小，这些资源浪费怎么办？（题外话：这大概也是Amazon涉足云存储和云计算的初始缘由吧）
我们来看这样一个在性能驱动下架构变迁发展的例子：
初期，只有简单的应用服务器和DB服务器分家，使用简单的Jetty容器，系统的瓶颈在DB侧。简单就是美，网站刚刚运营，能访问就是王道：
系统在发展中不断地演化。
有一天发现用户压力越来越大，终于无法承受了，系统屡屡到达崩溃的边缘，在现有硬件和架构条件下很难支撑现有的业务，做出了这样的改变：
在这次改变中，做了这几件重要的事情：
1、引入了全页面的缓存。互联网应用缓存为王，全页面的缓存可以起到立竿见影的效果。
2、把页面展现抽象成为“主题”，和页面数据分离开来。并且，为此，引入了“聚合”的概念，它为以后的进一步发展打下了一个伏笔。
3、为了缓解数据库的瓶颈，使用了RAC方式做持久层的集群。
4、对于JS、CSS、图片等几乎一成不变的静态资源，引入反向代理，优先处理。
网站继续安安静静地发展，悄悄地演化。
终于有一天，用户访问量激增，百万级的PV达到了，WEB2.0业务也增加进来，缓存的命中率越来越低，CPU成为了瓶颈，访问异常缓慢。这一次，又要动刀了：
这一次的架构重构做了这么几件重要的事情：
1、静态资源（特别是可供下载的文件），使用CDN缓解压力。
2、把请求拆分成主请求、异步数据请求和静态资源请求，其中主请求仅仅是获取页面不变的部分（模板+静态数据），动态的数据以异步JSON的方式获取，并在浏览器端使用JavaScript聚合。这一步把某些聚合操作放置到了客户端进行，缓解了服务端压力。
3、真正将页面的聚合展现和页面的生成拆分开来，保证了用户响应是快速的。
4、引入多层次缓存（内存中对象集合使用Memcached缓存，接口层面缓存报文，页面缓存缓存文件等），同时，对于层次的划分，容易将整个系统拆分成若干个子部件独立运作，简单、独立。
5、数据库进一步拆分，读写分离。
6、页面分块。这是大型Web2.0网站共有的特点，一个页面上往往总有那么一部分是固定不变的，这些部分应当能以页面片段的形式缓存到磁盘上，每次页面生成的时候只需要更关注变化的部分即可。
继续、继续……
访问量增长了几十倍，集群的服务器也第一次达到了三位数，系统不稳定，速度重新落下，问题定位也无比困难，一切又开始扑朔迷离起来。
这一次，不可避免地又做了架构上的调整，首要的目标，是以隔离解耦的方式增加系统稳定性，同时，更便于产品化管理：
1、整体采用SOA方式布局，按照功能划分集群，并且每个功能集群定义为一个“服务”，内部采用REST风格的接口访问服务。服务驱动和编制引擎（ESB角色）定时把可以提前生成的静态数据存放到共享存储上。
2、清晰化聚合逻辑，静态的数据尽量在服务端聚合完成，减少客户端数据请求的流量。
3、引入NOSQL数据库和廉价存储，适当放弃一致性，为海量数据做妥协。
4、开发核心业务功能包部署引擎（基于OSGi），对于业务的定制，只需要按照功能包定义的格式开发，完成后可做到不重启应用增加业务功能。
最后要说的是，如你所见，性能因素是一个网站系统发展的其中一个重要推动力，再细致的思考也难以兼容那么多未知的场景，不妨多在扩展性和兼容性上下下功夫，避免网站冷清痛苦，网站大热更痛苦。
