牛人说11.11特辑 | 异地多活-广域分布式架构的开端

Posted 2021-04-14 京东零售技术

hello，各位小伙伴们

昨天没有等到牛人说是不是很“惊喜”？

有很多小伙伴在后台问我

为什么周一没有更新牛人说

在这里商小研要跟大家说一下

别着急，好事多磨

今天为大家请到的是来自京东基础平台的张克房

负责全链路压测ForceBot军演系统

异地多活广域分布式架构等多项技术

是架构工作变革和发展的直接参与者

奠定了京东运维现行的多项技术架构和运维模式

如此大牛的架构师

让我们来听听他怎么说吧！

牛人说——张克房 来自京东商城研发 00:00 11:04

主讲人——张克房

为什么要做异地多活?

我相信大部分企业开始考虑做异地多活时，绝大数是因为企业的发展所驱动，而不是跟风潮流，按照企业的生命周期理论，一般会经历四个阶段:创业期、成长期、成熟期和持续发展期。所有的互联网公司在最初创业期很少考虑全方位的高可用架构，创业期属于狼性发展时段，交付效率是第一。

本人2010年初加入京东,当初正是疯狂的快速成长时期，到目前为止数据中心规模已由原来的北京一个机房发展到了现在的多地区N个机房,由原来的单机房单中心、同城双活发展到现在的异地多活。做异地多活初衷除了提高灾备、高可用、用户体验等外，更重要的一部分是解决数据中心级别的可扩展性问题，支撑核心系统实现广域分布式架构，由于单个IDC机柜、带宽、电力等资源是有限的，无法支撑快速发展的扩容，必须突破商城业务系统规模不受限于单中心或单机房资源容量。

异地多活网络架构

网络是所有互联网企业发展的根基，追溯历史，国内最初只有一家运营商，为了打破垄断，引入竞争的目的，形成了现在的中国三大运营商：电信、联通、移动.但是出现了三大运营商互联互通的瓶颈问题严重，跨网和南北互通访问速度很慢. 国内的特有互联网问题经过N年的演变，虽有改善但还是存在缺陷,我们没有能力改变互联网的现状，但是可以根据现状优化提升我们自己的网络架构提高系统质量，解决用户访问京东的速度和高可用体验问题。

网络在规划和设计时除了可扩展性、冗余性外还必须遵守一个原则，那就是越简单越好，利于后期的排障和运维。网络不同于业务系统，bug可以无缝修复，如果核心网络架构的缺陷出现大面积网络瘫痪，是致命的、影响大、涉及范围广.近年伴随着Docker技术飞速发展，目前线上系统已全面Docker化，网络如果还是使用物理机时代的传统网络架构，所带来的问题将是毁灭性的，异地多活的网络架构必须考虑未来的快速发展和庞大的Dokcer化集群，把网络基石做好。

解决南北互通和三大运营商互通问题使用了常用的最简单最有效的方法：

1、把系统部署到用户最近区域

2、不跨网

互联网区域拓扑

数据中心网络规划了互联网区域，此区域可以接入三大运营商或者其他小运营商单线和BGP线路，根据公网IP配置策略路由选择不同的出口。研发系统进行域名智能解析，GSLB调度用户访问同运营商VIP解决跨网访问。

另外还有三大运营商BGP广播、代播、或直接采购二级运营商多线BGP带宽等解决方案，BGP广播和BGP带宽成本较高，大流量业务系统使用不划算，代播对于排障和failover存在很大的缺陷，这些方案在京东只适用于个别系统.比如httpdns服务较为典型。

单机房整体网络拓扑-1

数据中心内部采用leaf-spine架构全面支持Docker自动化和发展：

1、网络设备全三层BGP互联，消灭二层缺陷。

2、服务器和TOR交换机三层互联，JDOS系统自助发布Docker明细路由。

3、每200机柜左右划分一个POD，POD之间通过边界高速互联，收敛路由表项。

4、节点可支持横向扩容。

负载均衡、NAT、DNS和防攻击等网络系统和工具部署在公网边界区域，和内网网络物理隔离,为运维网络割接互不影响和平面化运维做好充分储备。

单机房整体网络拓扑-2

物理机和TOR交换机BGP三层互联，双网卡配置接入到TOR，网卡1配置静态IP，用于带外管理、系统管理和JDOS调度、发布、日志等网络传输，网卡2和TOR跑BGP协议，由JDOS系统自助发布docker IP，用于应用数据传输和对外提供服务。

多中心数据一致性

数据一致性话题无论是庞大的异地多活还是简单的双机热备,必然是所有研发最关心的话题之一，在项目初期京东商城-总架构师、基础平台部负责人刘海锋对我们讲，京东商城的异地多活(广域分布式架构)项目不要照搬业界方案，不能让各种研发系统大手术，要根据我们现状和业务场景，制定不同的方案，我们要走出一条不寻常之路，让研发和业务尽量透明，改动最小。实现不一样的京东商城自己的异地多活。

数据同步总览

对于持久化存储根据不同的业务系统会选择了不同的方案，但是最终采用的方案准则规范是一份数据最多存3份，要求至少垮两个中心存储原则，比如一张图片或数据库，华北存2份，华南存1份，全局最多只有3份数据，并至少分布在两个中心区域机房以上，保证异地有备份并在线可用。mysql各中心之间的复制完全依赖于京东自主研发的数据高速同步产品Tube，Tube是京东自研基于RBR实现了binary log的实时采集，并且能够以管道为单位制定复制数据关系。另高速缓存JIMDB在京东内部大量系统广泛应用，JIMDB作为高速缓存通过异步持久化实现秒级同步。数据一致性主要工作在提供基础服务的基础平台部，保证业务研发不用关心数据层的灾备和延迟问题。

多中心应用部署和调度

核心应用部署闭环服务：

1、强依赖上下游系统闭环本地部署，数据层使用JIMDB全局高速缓存和Tube系统底层解决数据延迟同步等问题。

2、三大中心承担所有流量服务，根据不同的区域覆盖的面积，部署不同规模的系统集群。

3、调度服务使用京东成熟的HTTPDNS和GSLB等调度工具，根据用户所在区域质量动态调度。

三大中心覆盖国内

发展初期数据中心集中在华北地区，调度以运营商维度进行诊断，通过GSLB智能DNS解析，联通用户解析联通的VIP、电信解析电信的VIP、移动则解析移动的VIP、小运营商访问BGP带宽的VIP，如有运营商级别故障，则跨网灾备，跨网意味着会增大网络延迟和丢包，对用户体验造成影响。现在异地多活多中心部署上线后，采用了类似CDN的就优接入原则调度用户支撑灾备+多活在线广域分布式架构方案。

多中心网络监控和灾备

多中心各种网络监控伴随着京东飞速发展至今已很成熟：

1、各中心会有到全国省份城市的网络质量速度检测数据API，提供给GSLB作为调度数据依据之一，实时调度避开拥堵网络，选择最优中心提供服务。

多中心网络监控

正常状态下，各自中心服务覆盖的用户，如果发生灾难性故障，无法快速恢复，如：断电、断网、空调制冷等故障，则要启用异地多活应急预案快速切换，由于在线中心也是有流量和对用户服务的，所以大可放心切换，不过此类切换部分系统会有损,高速缓存会确保最终数据一致性。

日常流量由华南、华北、华东三大中心服务全国，除了正常提供服务外，各中心还承担其他中心的热备状态，当某中心故障需要流量切换接管时，可按就近调度原则把用户调度到网络质量最优的中心进行提供服务，大促期间资源扩容也不再局限于往一个机房扩容导致机柜、电力、带宽等不足尴尬问题。

异地多活先锋部队-广告和搜索系统

广告系统是公司重要的之一，每次的点击曝光失败将是一笔损失，以往的痛点是南方用户体验差，网络延迟等导致曝光失败问题困扰着广告兄弟部门.搜索系统面临着南方用户由于互联网网络延迟等问题导致的体验下降和用户流失。

项目初期广告团队和搜索团队就加入到了我们项目第一批部署规划内，使用我们部门JIMDB异地多活复制技术支撑了广告和搜索广域分布式架构的实现，率先在异地多活项目中实现了就近用户调度，大大改善了用户体验,有力的支撑了广告业务和搜索系统的发展.在系统实现双机热备和多机房双活的基础上，又最先更进一步实现了广域分布式架构部署.成为了京东系统标杆。

总结

1、减少跨机房调用和数据同步原则。

2、尽量闭环服务和闭环读写原则。

3、保证数据最终一致性，不保证数据实时一致性，需要各系统有容错机制原则。

4、使用多种方案，针对不用业务去实现异地多活原则。