京东商城交易系统的演进( 四 )


容灾降级

京东商城交易系统的演进

文章插图
 
每次双11活动,我们会做很多的容灾和降级,有多中心交易、机房容灾、业务容灾等各种纬度的容灾 。大概统计了一下做过的一些容灾方案 。
京东商城交易系统的演进

文章插图
 
首先是网络容灾 。前面说到SB中间件、域名解析,我们运维自己会做了核心交换机两层专线 。这是我们运维部做的一些网络架构图,两边相互容灾的一个结构 。有LVS、HA、域名及解析,只是单服务挂了,通过交换机,我们可以从一个机房切换到另一个机房,因为会做一些域名的解析和切换 。
京东商城交易系统的演进

文章插图
 
应用系统相互调用容灾和降级:结算的容灾和降级 。应用系统大部分能够降,比如库存状态 。如果像优惠券这些不重要的服务,备注信息,可直接降级服务,不用去访问它,直接提交就行 。在提交订单时候,首先我们会保证必要服务,这些服务都会有很多的保护措施 。每个应用里面,应用级别、服务级别的容灾,比如地址服务、库存状态容灾可以直接先降级 。到提交的时候,我们直接对库存做限制 。
京东商城交易系统的演进

文章插图
 
应用内部的容灾 。库存就是结算前面的系统应用的服务,再到细一层的我们的库存服务,这是每一个服务的容灾降级 。从库存状态这边的话,从网络设备内层,有网络容灾降级 。应用内部有对于预算服务的降级,预算服务会有预算库存,原来是写MySQL数据库 。正常情况下,预算库存是写MASIC预算库,当出现问题的时候,我们会异步堆列到本地机器,装一个程序去承载这个异步MySQL数据的落地,然后再通过Work把它写到MySQL服务里面 。正常情况下,是双写MySQL、redis,当MySQL承载不住的时候,我们会把MySQL异步写到里面 。
这里面都会有开关系统去控制 。当提交订单产生变更的时候,才会把库存状态从这边推到这个库存状态这边,因为库存状态的调用量跟价格一样很大 。今年我们看到的最大调用量是一分钟2600万 。这样不可能让它直接回原到MySQL,跟直接库存的现实存储里面 。通过预算系统把这个状态从左边算好,直接在推送过到真正的存储,这样就把这个存储剥离出来,这也算一种异步异构,这样我们会提升它的容量 。
这是原来的结构,就是redis直接同步,然后直接访问 。现在把它改成是,直接让左边的预算服务去推送到状态服务里面 。
监控
京东商城交易系统的演进

文章插图
 
最后主要就是监控系统,我们运维提供了网络监控、机器监控 。
网络监控包括我们看到的SBR,以及一些专线网络监控,如交换机、柜顶交换机、核心交换机的监控 。
京东商城交易系统的演进

文章插图
 
接下来是应用的系统监控 。机器监控有CPU、磁盘、网络、IO等各方面系统的监控 。业务纬度的监控,有订单量、登陆量、注册量等的监控 。京东机房微屏专线的一个网络平台的监控,里面有很多专线,它们相互之间的流量是怎么样?图中是我们监控系统,是机器之间的监控,包括机器直接对应的交换机、前面的柜机交换机等的网络监控等 。
这是应用系统里面的方法监控,后面是业务级别的监控 。订单级别的包括注册量、库存、域站,或者区域的订单、金额、调用量的监控都会在这里体现 。真正到大促的时候,不可能经常去操作我们的系统,去修改它的配置 。正常情况下都是去查看这些监控系统 。2012年之后,监控系统一点一点积累起来 。当量越来越大,机器资源越来越多之后,这些监控都会直接影响正常服务,服务用户的质量会下降,可能20台机器宕了一台机器,不会影响全部效果 。所以,监控的精准性是一步步慢慢提高的 。
京东商城交易系统的演进

文章插图
 




推荐阅读