二、关于大型复杂系统



图-1

2.1  系统都是从小变大的

以淘宝网为例，2003年非典前期，直接使用的就是LAMP架构（Linux, Apache, MySQL, PHP）。库表结构也非常简单，直接就是用户表，交易表，商品列表等。

开发团队也就那么几号人。

因为非典疫情的影响，淘宝网的业务开始慢慢有了发展，开发团队也开始从几个人变成了几十人。

在2004年到2008年期间，淘宝网的开发团队增长到几百号人。

在07年，淘宝开始走向服务化。

在08年，淘宝网的用户量已经到达8000多万。

从09年开始，淘宝网开始做去IOE，把用户中心、商品中心、交易中心、店铺中心都单独拆分出来，这时候就是近500人的开发团队了。这时候淘宝网的用户数量已经到达了1.6亿左右。这时候，淘宝网已经是一个非常复杂的系统了。



在2012年，淘宝网和天猫网的交易额超过了1万亿人民币，超过亚马逊公司和eBay之和。

这么大的一个系统，最理想的情况是，7*24不停的正常运行。



理想很丰满，但现实很骨感呐~~~



2.2 阻碍大型复杂系统7*24正常运行的点

图-2



2008年初，淘宝网为了解决Oracle数据库集中式架构的瓶颈问题（连接数限制、I/O性能），将系统进行了拆分，按照用户域、商品域、交易域、店铺域等业务领域进行拆分，建立了20多个业务中心，如商品中心、用户中心、交易中心等。



拆分之后，的确各个领域的职责是非常清晰了。但同时也会有另外一个问题慢慢浮现，服务与服务之间的调用关系，会演变得越来越复杂。



服务调用之间非常复杂，而整个系统，也是运行在一大堆组件上面。



而这些组件，也难以保障完成是100%是可用的。



2.3 大型复杂系统高可用的阻碍点分类

图-3



曾经做过一个统计，电商平台经常遇到的问题如图-3。

1.在这里面，故障电商平台依赖的银行支付通道，遇到的问题往往是比较多的。

2.内部的中间件，Pass相关的、IaaS相关的故障还是比较高的

3.业务变更，新需求、新代码版本，也会带来较多的故障

4.外部的因素，如人为破坏，天灾人祸的概率是比较低的。