京东到家应用架构设计分享

前言

商品系统是电商系统最基础、最核心的系统之一。商品数据遍布所有业务，首页、门店页、购物车、订单、结算、售后、库存、价格等，都离不开商品。商品信息要稳定提供至到家供应链的每个节点，所以必须要有一套稳定的、高性能的商品服务体系支撑。

随着京东到家商品业务的快速发展，业务从单一转变为多元化，系统功能设计上也从最初的大而全的功能支持，向微功能、领域化演变。

商品系统也在高可用、高并发的持续冲击下，经历了多个架构版本的演进。最初1.0版本，采用合适简单的设计思路，满足了业务快速迭代上线；随着业务量级的快速增长，针对高可用、高性能的提升，演进出了2.0版本。随后业务复杂度的提升，导致了系统复杂度的提升，为了解决系统复杂度带来的问题，孕育出了3.0商品体系领域建设。

到家商品架构初始模型1.0 合适、简单原则设计思想

商品系统雏形

到家商品系统创建之初，为了贴合业务的快速发展，设计并且上线了到家商品1.0系统。商品系统服务本着大而全的思想，用一套服务提供给上游业务方聚合的商品数据，无论是B端业务还是C端业务均耦合在一起，在应对业务快速迭代上线、节省开发成本上 充分体现出了简单的优势。

随着业务量级的增加，最初设计的劣势也突显了出来，主要体现在以下几点：

·线上B/C端业务耦合在一起，导致线上读/写业务相互影响，特别是大促期间 大量修改商品导致 C端服务不稳定，只能通过不断横向扩容来提高稳定性，继而导致了严重的资源浪费；

·服务端性能波动较大；

·简易的缓存架构，在高并发下Redis缓存击穿问题；

·监控不全面，无法及时预警；

针对上述问题，商品系统从高可用、高性能的出发点进行了架构2.0演进；

到家商品架构-2.0 高可用、高性能架构模式演进

商品系统经历了1.0快速迭代的阶段后，线上流量也随着业务的增长翻倍，B/C端服务的高耦合导致了商品服务的波动大，而且监控的不全面也导致了不能及时发现系统异常。

为了提高商品系统服务的高可用，商品系统制定了以下迭代方案。

·AP原则 + 最终一致性思路

·B/C服务分离

·异地多活、双机架构

·Sentinel限流

·监控平台

高可用演进

（1）AP原则 + 最终一致性思路

为了提高商品C端读服务的高可用，采用了AP原则 + 最终一致性的设计思路,引入了分布式缓存Redis集群提高读服务可用性,并通过异步消息保证数据的最终一致性。

AP原则贴合商品系统C端服务的业务场景，比如：因为网络延迟等问题,数据库没有及时同步数据至Redis缓存,导致当前读取的商品数据和数据库的数据不一致,这种短暂的不一致,在业务上是可以接受的。

引入分布式Redis集群后，商品C端读服务能力不仅提高了可用性，而且在性能上表现也非常出色。

（2）B/C服务分离

商家会通过对接开放平台接口，定期修改商品的信息、图片等属性。例如：我们在一次大促中遇到商家集中修改商品信息，结果写服务占用了大量的系统资源，导致了读服务可用受损。

为了提高商品服务B/C端各自的可用性，独立部署了B/C端服务，分别对外提供服务。B/C服务拆分后，商品系统在后续的各种大促中，B/C服务各自表现平稳，极大提升了商品服务的可用性。商家后续写操作，商品系统再也没有出现过读服务受损的情况。

（3）异地多活、双机架构

异地多活-到家商品服务docker所在的物理机机房，采用了异地多活的方式进行部署，机房分布在多个不同地区，遵循“鸡蛋不要放在一个篮子里”原则。在一个机房出现问题的时候，还有另外两个机房提供服务，极大提高了商品系统应对黑天鹅事件的处理的可伸缩性。

双机架构-作为商品核心读服务的支撑中间件Redis集群，使用了主-从模式， 并且主分片和从分片分属不同的机房，在主分片异常的时候主从自动切换。

Mongodb采用了1主2备的方式进行数据备份，主库异常可通过域名快速切换主备节点，整个切换过程平滑无感知。

（4）Sentinel限流

商品读服务引入了Sentinel流控组件，可以通过Zookeeper根据调用源实时配置不同的流控策略，在极端流量出现后，可以对非核心的调用源进行限流、熔断，为线上扩容争取足够的时间，避免了突如其来的异常流量导致商品整体服务不可用，提升了商品读服务的可用性。