京东架构专家分享京东架构之路( 四 ) _架构

为了在复杂的系统基础之上，尽量缓解峰值带来的压力，京东峰值系统的设计主要从性能提升、流量控制、灾备降级、压测预案四个角度来进行。
性能提升
切分业务系统
我们先将整个业务体系拆分为几个相对独立的子系统如SSO、交易平台、POP平台、订单下传系统、WMS和仓储配送（图2）。每个子系统又可细分为若干部分，逐级简化，直至可操作可优化的层级。例如，交易平台包括价格、购物车、结算、支付和订单中心等；网站系统包括首页、登录、列表频道、单品和搜索等。接下来，针对每个功能模块的关键部分进行切分，有针对性地做性能优化。

文章插图

图2 业务切分方案
例如，交易的秒杀系统，原来是根植于普通交易系统之内的，缺点非常明显。当流量突然增大时，不仅会导致秒杀系统反应迟钝，而且会影响普通交易系统的正常运作。于是我们将其与其他业务系统物理分开，成为相对独立的子系统。并且针对秒杀的特性，减少对后台存储的依赖。同时优化中间层存储机制，使得相对热点分散部署。甚至支持单一SKU多点部署，从而大大提升了秒杀系统的吞吐量和可靠性。

文章插图

分布式
分布式的交易系统是电商的未来。分布式系统解决两大难题：提高用户体验和增强容错能力。由于分布式系统设计时就会留有相当的流量增长空间，所以当一处数据中心饱和时，可以将其余的流量切入其他相对宽松的数据中心去，从而达到互为备份、互相支持的目的。与此同时，由于为提供用户就近服务，所以减少了网络延时，页面反应速度加快了。举一个例子， google搜索是全球服务，欧亚美各地都有不同的IP提供服务。当其中的某一个IP出现故障时， Google能够从容地将其服务切换至最近的IP ，继续搜索服务。对于电商来说，情况更复杂一些，需要同步的数据要求更精确，数据量较大，对延时的容忍度更低，建设周期也就更长。京东正在此方面着力改进，从只读的系统入手，一步一步实现系统的分布式。
API服务化
在各个系统中，总是有很多相同的组件。前端的负载均衡自不必说，中间件的处理就是非常典型的例子。如何高效统一地管理这些组件， API服务化是我们的答案。最好由一个训练有素的团队集中管理这些组件并对外提供接口服务，将软件的使用复杂性隐藏起来，调用的是简单利索的API 。让专业人员去处理复杂逻辑，确保系统的可用性和扩展性，既能大大降低出错概率，又能实现规模效益。
Redis是我们常用的缓存组件。过去都是由各个业务实现团队进行分别维护，专业性不强，使用多有不当之处。后来我们进行了集中管理，统一定制开发新功能和升级，并通过API服务化提供给各级用户。这样不仅丰富了应用场景，还提升了性能和可靠性。
架构，代码优化
一个合理的电商系统架构是与一家公司的研发水平和技术管理水平密不可分的，这直接决定了可支撑峰值流量的多少和未来能达到的高度。选取适合自身发展的框架，既能充分发挥其效能，又可节约资源。代码优化也能提高效能，例如对于SQL语句的优化，能更好地利用索引；Java/C++逻辑的优化，减少了不必要的循环和复杂的操作；算法优化，使之更高效；功能实现逻辑的优化，变得更简洁和清晰；等等。但代码优化终究不能冲破极限，难以追求极致，适可为止为宜。
系统虚拟弹性化
当磁盘I/O不是瓶颈时，解决系统水平扩展就会变得容易许多。可以通过ZooKeeper或类ZooKeeper将软件栈有机地串联起来，并配以有效的性能监管。当事务处理成为瓶颈时，利用当今流行的虚拟化技术（如LXC或VM）可以在没有人为干预的状况下自动进行弹性扩展。