分布式系统架构设计

一个完整的电商系统，分为前台交易系统与后台作业系统，前后台共库是传统企业在设计电商项目时的一个常见做法。但这个做法引发了上线后的诸多麻烦。在前台交易系统处于峰值情况下，数据库本身已存在很大的压力，此时如果后台作业系统产生大规模的查询或写入请求，则很容易造成数据库无法响应。我们在很多客户案例中发现，如果前后台共库，正常非峰值情况下，每日订单数只要超过2000单，就会不同程度地出现前后台互相干扰，数据库成为主要瓶颈。此时，客户不得不在系统高峰时停止在后台作业系统上的操作，这给业务造成了很大伤害，发货延时、客服水平下降、统计不准确等情况成了家常便饭。实际上，从架构上来说，前台交易系统与后台作业系统服务的用户对象不同，前者是消费者，后者是企业内部员工，完全可以进行系统分离，两者之间采用消息队列进行异步订单传输，以隔离互相之间的影响。

当然，对于交易系统，我们也要根据业务特征进行分布式设计，提升业务扩展性、应对高负载。例如对商品货架系统、会员系统、核心交易系统、资金系统、日志系统等以高内聚、低耦合的原则进行分离，以分别根据不同的访问特征进行优化。

根据分布式架构的CAP理论，Consistency（一致性）、 Availability（可用性）和Partition tolerance（分区容忍性）最多只能同时满足两点。对于一个峰值系统而言，分布式（分区）设计是必然的，可用性也是基础要求，因此，我们只能放弃一致性要求，只达到最终一致性。不过，在一个电商系统的架构设计中，最容易出现的问题是滥用CAP原则。例如在交易过程中，后台的供应能力（库存）是至关重要的，在交易生成过程必须要保证严格一致性，而不是最终一致性，这就要求我们以事务的方式来解决。否则，虽然在架构实践中很容易达到从容应对峰值访问的目的，但超卖等伤害业务的现象必然会出现。

在分布式系统设计中，必然要求我们采用面向服务的体系结构（SOA）。但需要在设计中注意几点。第一，在峰值系统中，每一个多余字节的传输都意味着对系统的极大开销，以每日1000万PV为例，假设这是每个请求都需要调用的服务，每新增一个字节，就意味着会新增10MB的流量。第二，千万不要直接使用自己企业内部IT原来部署的服务。这是因为企业内部原有的SOA服务不是为互联网峰值系统所设计的。我们曾经有一个客户，在电商网站上使用了企业内部IT提供的客户验证服务，看上去只是一个简单查询，结果甫一上线，直接导致该服务崩溃，进而引发整个内部IT SOA体系的下线，对内部系统造成的影响用了好几天才得以消除，更不用说对线上系统的影响了，严重伤害了企业的形象。第三，幂等原则。假设所有的服务调用都是不可靠的，所以重试是常态，因此对于重复的API写入操作应进行判重处理。