架构师（2015年12月）

卷首语

大规模弹性平台架构设计

冯是聪 北京明略软件系统有限公司联合创始人兼CTO

在谈大规模弹性架构设计之前，先聊聊两个真实的场景:

场景一：春运火车票抢票大战。春节一直是中国最重要的传统节日，每个中国人都期盼着在这个阖家欢乐的时刻，能够相聚在一起共享天伦之乐，于是就有了中国特色的春运，外媒称之为“人类历史上规模最大的周期性迁徙”。作为春运火车票售票系统，因为峰值访问量过于庞大（2014年尖峰日PV达到144亿次），2014年以前12306系统动不动就瘫痪，12306也因此一直受到诟病，相信大多数春运期间购买过火车票的人都记忆犹新。2015年以后，尽管尖峰日PV达到令人恐怖的297亿次，但是由于系统经过了升级，系统瘫痪的情况大大减少。

场景二：双十一购物狂欢节。刚刚落幕的2015年双十一购物狂欢节，阿里巴巴集团创下了912亿的骄人成绩，支付宝支撑住了8.59万笔/秒的交易量。

上面两个案例中，如果我们为了保证系统的高可用性，按着每天访问的峰值作为标准来设计系统，绝大数情况下访问量较低时，无论是硬件资源还是网络带宽等资源都会造成巨大的浪费。那么如何从技术上解决这个问题呢？答案是大规模弹性架构设计。

大规模弹性架构的主要设计目标是系统的高可用性和高扩展性：根据系统的实际需要，系统自动弹性分配资源。在需求量大，比如峰值的时候，系统自动调配足够的资源；在访问量小，系统自动释放出部分的资源，从而实现资源的按需分配。

那么大规模弹性架构的基本工作原理是什么？其主要是利用高性能虚拟化技术，实现了计算、存储和网络资源的统一调度和弹性分配。限于篇幅，这里仅举两个具体的技术：

1. 实现动态部署。为了应对突发峰值访问量或者可能的网络攻击，需要在应用服务器内部部署一些监控程序，由主控程序判断当前整个集群的负载情况，自动增加或者减少服务节点，并且自动部署应用程序，从而从容应对突增的业务流量。
2. 实现故障自动恢复。当一台物理机损坏时，系统需要自动监测到硬件故障，并且在第一时间内，把云服务器迁移到新的宿主机上，同时硬盘数据需要保持最后一刻的状态。数据安全是第一位，因为数据始终面临误删文件、病毒破坏、程序写错、硬件损坏等种种可能的风险。在弹性计算平台上，需要利用快照功能自动完成数据的备份。

最后，简单聊聊大规模弹性平台架构设计变化的趋势。

第一，弹性平台架构平台的设计将会愈发智能。系统将会自动收集愈来愈多的用户访问数据，跟据历史访问规律，自动地预测系统峰值的变化趋势，峰值的预估将愈加精准。简单设想一下，如果系统已有的全部资源都不能满足峰值的需求，弹性设计已经没有意义了，这时候需要提前做准预估，并采取相应的措施，并假设如果超过峰值，如何应对。

第二，以容器技术为代表的轻虚拟化技术的迅猛发展，将会进一步促进大规模弹性平台架构设计的进步。

第三，弹性计算平台将需要考虑更加安全的容灾方案。目前常见的单个物理位置的系统，始终会面临诸如地震、火灾等不可抗力的威胁，所以需要有更加安全的容灾方案。比如常见的有跨机房异地容灾，目前Google的核心数据已经实现了跨越5大洲的异地备份容灾。

目录

热点｜Hot

斑马系统：微信朋友圈广告背后的利器

Spark和Hadoop，孰优孰劣？

推荐文章｜Article

通过大量测试来构建测试系统

实施微服务，我们需要哪些基础框架？

专题｜Topic

重建还是重构？

Medium开发团队谈架构设计

观点｜Opinion

被误解的MVC和被神化的MVVM

特别专栏 | Column

深入了解IAM和访问控制