混合多云第一课——多云多活为何被称为“技术皇冠上的明珠”

当今科技的发展正在推动着产业格局的演进，而产业变革的核心则是信息技术的运用。比方说物联网、5g、人工智能等等。那么信息时代的这种数据的爆炸性增长，给企业业务的连续性带来了巨大的挑战，而传统的灾备中心存在着建设成本高，切换时间长，以及灾备中心的资源不能充分利用等一些不足。所以目前多云多活的这种技术正在逐渐兴起，那么为什么多云多活被称为技术皇冠上的明珠呢？下面我想分享一下京东在这方面的一些实践，京东是如何去做这种多云多活的以及京东的一些产业实践案例，我将分为以下4个方面来讲。

第一个就是说我们多云多活的一个产业价值，第二个是讲我们技术皇冠上的打磨之旅，我们有哪些困难，以及我们京东科技是如何克服这些困难的。第三个讲的是说从技术的理念构建到产品的标准化，我们是如何把这样一个复杂的流程进行串联起来，并且作为一个标准化产品，让客户能够简单的去使用。

最后再分享一下我们在具体的一些产业实践的案例。

1.多云多活的产业价值是什么？

科技让我们生活变得更加美好，我们可以足不出户的进行购物支付，那坐在家中就可以等着我们快递送上门，但是如果说我们的系统发生故障，社会或者个人会造成一些巨大的损失。以下是我们近期全球所发生的一些影响比较重大的一些案例。

在2020年，东京证券交易所由于软件故障，导致于全日本的交易所停业了，一天影响达到数千亿日元，同年的10月，那么法国的一个IT公司也是由于勒索导致它的全球服务的中断，公司的损失到达了这种4,000万欧元，公司的CEO也引咎辞职。

有机构做过一个统计，统计了每个行业在遭受到这种IT系统中断情况下的平均损失。在金融服务和信用卡授权我们能看到都是上百万美元，那么在其他的购物视频点播等等，它的损失达到了10万美元，这是几年前美国的一个数据，在我们中国可能损失就更大了。

我们有什么办法来抵御？那么方法就是建立一个灾备系统，灾备系统能够有效的降低企业遇到一些意外故障的时候的业务中断。

我们中国的一个联盟做过一个调查报告，在建设了容灾体系的情况下，业务停机的损失降低了3.4倍，那么损失的金额从以前的102万美元降低到30万美元，数据丢失的损失降低了3.5倍，从平均的78万美元降低到了23万美元。

虽然容灾体系的建立能够有效的降低企业的损失，但是企业业务连续性的提升其实并不是一件容易的事情，IDC曾经做过一个调查，发现企业在建设提高它的业务连续性方面遇到了一些挑战，比方是说传统的的灾备中心，它的资源利用率不足，不能直接带来生产力的提升，通过灾备中心进行业务切换，那么切换的时间比较长，很难满足一些对业务连续性要求比较苛刻的这种行业的需求，比方说金融保险等等。

其次这种灾备系统建立，还有成本过高，建设困难，管理困难，使用困难等一系列的问题，所以这种企业建设这种灾备中心也不是一件容易的事情。

我们看一下这种业务连续性的演进。

最开始我们可能就是一个单体应用，业务不是在一个机器上，那么如果这个机器出现故障或者业务发生bug，挂了之后，那么整个系统就停止了，是最原始的一个应用。

随后我们把应用进行了拆分，我们把应用部署在多个机器上面，这样即使机器发生故障也不影响，同时我们应用的实例还可以部署多套，即使有一套发生故障之后也不影响整体的对外服务。同时为了进一步提升这种效率，我们还把这种机器或者应用去跨机架去部署，如果机架发生问题，也不会导致我们整个业务中断。这是后来引进的一个单机机房的SOA架构，这种架构并不能去抵御我们整个机房的一个故障，比方说整个机房的电源发生故障了，或者它的网络发生故障了等等，这个时候又衍生出一种同城双活的这种架构。

我们把应用部署在两个机房里面去，数据做主从同步，应用去写主集群，这种方式可以规避我们机房的故障，在面对一些对业务要求性更高的一些行业，比方说这种银行证券等行业，这种方式它没法去抵御自然灾害，比方说我们整个城市受到了地震或者受到了这种暴风的袭击，导致这种业务中断，所以后面我们又衍生出两地三中心架构，在异地建立第三个灾备中心，做异地的备份和业务的备份。

那么在这种情况下，灾备中心往往是不提供服务的，只是在同城业务发生困难的情况下进行切换，这种情况时间比较长，难以满足很多业务的要求。

近些年由于云计算技术的兴起，所以我们又开始这种多云多活的这种建设，把数据进行分片进行拆分，每个机房分片数据，然后业务要进行流量划分，那么当某一个机房出现故障之后，它的业务流量能够在分钟级之内切换到其他机房里面去，对于用户来说，甚至说可能感受不到这种故障的发生，就是我们最近的这种多云多活的一个架构。

好，为什么我们要做多云多活？因为我们经过通过调查发现，多云现在是全球IT的主流的趋势， Flex调查发现，全球已经有92%的企业已经采用了多云的战略。

多云战略是未来企业的主要的方向，企业要充分去利用多云所提供的这种种能力去发展它的业务，没有任何一朵云能够去满足所有业务，用户就发生了多云需求。

IDC调查也同样表明了，未来的用户的业务会急剧的上升，它建议用户关注跨云或者边缘的连接，以及集成。工信部下面的信通院的调查也表明，无论是用户还是企业，都希望能够有融合多个云厂商提供多云服务的一个产品出现，帮助用户进行多云的部署和数字化战略。

我们能够看到：多云不仅是全球的一个趋势，多云在国内已经逐渐的兴起了，从大型企业到很多政务云，他们都已经采用这种多云的架构，对于单一的云厂商来说，采用多云的战略，它的收益会更加明显。

我们看一下企业的用云现状。

那么最左边是一个单云，用户的所有的业务都跑在一朵云上，这种情况下用户就跟这种云强绑定，往往丧失了议价权，成本会比较高昂，同时也受到这种单云故障的风险，如果云发生故障，那么它整个业务就是一个停滞状态，所以这种情况下用户的风险性比较高。

很多企业认识到了单云的风险，又采用多个云的这种方式，把他们的多种业务分布在多个云上，但是每个业务只在一朵云上，这种情况下他们业务还是会承受到一定的威胁，比方说我们某个核心业务在某个云上，如果说这朵云发生故障，那么这一部分业务同样会陷于停滞状态，这种情况下，用户的议价权和成本也受到一定程度的绑定，所以各个业务形成一种烟囱状，不能协同作战。

那么第三种我们称之为真多云，这种方式下多个云做了一个抽象，提供统一的运行的资源，用户会在上面建立统一PaaS组件和使用入口，各个业务可以根据它的业务的选择或需要分布在多个云上，任何一朵云发生故障的话都不影响整体服务，这个我们称之为多云，这也是最理想的一种方式，但这种方式存在着成本投入大，技术门槛高这样一个问题。

我们曾经做过一个调查，采用这种多个云的企业这种方式，他们其实也认为他们在云的使用方面也不是特别满意。

比方说在价格维度，他们议价权会比较弱，云厂商往往会跟他们绑定这种资源的用量，

其次在政策维度可能受到监管合规、反垄断或者、安全的因素，在技术维度如果你跟一个营销商绑定的越久，那么技术栈的深度绑定其实不利于它的创新和发展，同样业务维度的丰富度和质量也比较受限，对于一些中小客户来说，在它的受重视的程度会比较低，它在运维方面响应的速度会比较慢，同样也会降低用户本身的一个业务连续性。

从出海维度，业务覆盖与开通方面也受到一定限制，那么绑定的越久，那么技术与企业的这种风险的在不断加剧，这是采用多个云的企业的一些观点和痛点。

我们看一下我们京东认为的多云应该是什么样的一种方式，我们认为真正多云应该是在以下5个层面进行打通。

第一个我们称之为机房通，机房通不仅仅是指机房之间，还有网络互通，而且还要指我们如果在机房之间部署各种监控去监控你这种网络的质量，你的延迟你的带宽等等，并且可以在这种机房的基础之上和多云基础之上，去划分我们的各种AZ可用区和Region进行进一步的这种抽象。

其次是网络通，网络通常指的是我们不但要Underlay的网络，Overlay的网络，包括我们的容器网络，也要彼此打通，方便我们的应用进行各种层次的访问。

第三个是指数据通，通指的是我们的数据在云上能够去自由的去漂移，自由的去移动，我们的数据能够从一朵云同步到另外一朵云去，而不受限制，这个数据通其实也是我们跨云应用多活的一个基础。

那么第四个是**应用通，**指的是我的应用能够去跨云的去发布、去部署，我们的应用多活也是处于这种应用通这样一个层次，可以把握应用部署在多个云上并行的去进行管理。

第五个是指的是管理通，管理通指的是说我们的资源从资源层面的管理，从我们的运维层面、运营层面以及安全层面都有一个统一的管控措施。

所以我们认为只有实现了在机房通、网络通、数据通、应用通和管理通这5通，才能是一个真正的多云的架构。

我们再看一下多云多活的价值。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ESXeiTKf-1679301882114)(https://oscimg.oschina.net/oscnet/up-2e2f94b8cce3bd4f5750c1218d8628774c5.png)]

首先来说多云多活对于用户来说，它能够使用户的业务连续性有保障，还能够控制用户的故障半径，减少因为单一机房或者单一云厂商发生故障，而给业务带来业务中断的风险。

第二个是多云多活，可以做我们多云战略的一个很好的支撑，当你的业务分散在不同云上，那么就可以根据各种不同云的技术和技术栈，它的优势采用不同的方式，可以很好的去支撑多云战略，业务就更加灵活。你不会被云厂商进行某个方面的绑定，同时你还可以去避免它的定价束缚、技术的绑定等等。

第三个是可以帮助用户进行有效成本的控制。那么传统的灾备中心，灾备只是提供这种冷备的方式，通常不提供生产力，或者说只用于一些这种只读的方式。多云多活，它的多个数据中心可以同时对外提供服务，能够让我们这种资源利用率得到最大程度的提升。其次它还可以根据不同厂商的价格和策略，动态的在多个云里面去调整它的流量，而且这种调整代价极低，所以我们可以根据各个流量价格去动态去分配我们流量，充分去实现我们成本的一个最优化。

第四个还可以很方便的进行业务的弹性伸缩，那么各个数据中心那么都是可以读写的，都是可以随时进行扩容的，而且流量的这种调整支持各种的分流策略，可以很灵活的根据业务的需求进行调整。

2.要实现“多云多活”，需要解决哪些核心难题？

那么第二点我们看一下，为什么说我们是技术皇冠上的明珠？

多云多活的打磨之旅是怎么样的？

多云多活虽然有上面我们所提及的种种优点，但是多云多活的建设其实也面临着很大的困难。

第一个就是说异构多云的资源，我们怎么去统一的去纳管？每朵云对外接口、API、产品形态都是不一样的，如果要去适配的话难度会比较大。

其次是说多云多地域，它的之间的数据实际性如何进行漂移的，数据时效性怎么保证，一致性怎么去保证，这是第二个问题。

第三个就是说多云之间我们能够做流量去怎么去进行调度，有些什么样的纠错和保护措施。

第四个是说我们现在是很多企业采用这种微服务的方式，我们的微服务框架是怎么去支持多云方面等等。这4个问题是我们在多云多活建设所面临的4个主要问题。

先看一下多云的统一管控问题，对于多云的管控，我们进行了一个把整个多云管控抽象出一个我们称之为Open Cloud的这样一个抽象层，由抽象层负责去对接下面底层的各个云厂商，而Open Cloud对上提供统一的接口和API对接各种应用，包括我们这种企业的应用，包括我们这种多云多活，都是在Open Cloud上进行统一的接口对接的。

这样的好处就是说用户不用再去逐一的去适配每个云厂商的千差万别的接口了，而只需关注业务的自身发展就可以了。除此之外，我们的Open Cloud也帮助用户可以重新替换规划能力，。当然从管控层面进行统一抽象之后，对于用户来说就管理管控更加容易了，也降低了用户的这种运维成本。

看一下具体的一个图。

用户有两个自建的IT机房，然后业务分布在两个不同的云上，这种情况下我们就可以把这4个机房做1个抽象，比方说我们既可以把机房123把它抽象成1个VPC，也可以把第一个机房作为1个VPC，23机房和A云统一成为一个VPC，通过这种方式向上去做它这种资源的整合，在上面再去搭建我们统一的这种PaaS组件，进行这种跨云的多活发布等等。

通过Open Cloud这个层次屏蔽底层各多元的复杂度，构建一个物理分离，逻辑统一的这样一个层次去满足用户的运行时环境。

那么用户的业务在使用的时候，就不用感知多云的技术差异了，对于它来说像是一个单一的云一样去部署发布和运维，同时这种方式用户也可以把公有云作为一个弹性池，如果说当某个业务这种峰值到来的时候，我本地的机房不能满足负荷，那么它就可以很容易的把这种需要的资源弹到公有云上去，由公有云来承接一部分流量，从而满足整个业务的一个峰值。

通过这种方式，我们用户这种业务规划也能够更灵活，那么成本也能够得到降低，因为你不用去维护很多这种机房，而随时可以去往公有云上去弹资源。

目前我们Open Cloud支持这种公有云、私有云以及虚拟化等各个平台以及各种云服务商的接入了，目前已经支持了10多个云服务商的接入，而且也支持VMWare这种方式，这种方式之下，用户可以去这种统一的 Open cloud上去构建自己的VPC实现网络的隔离，去划分自己的子网。

同时我们还提供虚机和物理导入能力，也可以把自己目前在机房或者在云上的主机通过导入的方式放到我们的平台里面去，而且还提供统一的接口和界面在各个云上去创建我们的虚机。通过open cloud我们可以实现对我们的运维和使用带来极大的便利。

第二个就是数据在多个云之间是如何做漂移的，数据的一致性和安全性怎么来解决？

那么数据复制其实是多云中的一个很大难点，那么我们京东为了解决在数据在不同地域不同机房里的这种复制问题，我们专门做了一套我们称之为数据复制中心DRC这样一个平台，来进行我们的数据复制。它可以支持多种同构或者异构的数据库的单向或双向同步，同时它能够支持缓存以及消息队列的同步订阅。DRC其实目前已经成为我们京东零售和京东科技进行单元化应用多维的一个基石。

DRC有一个三高一低的特点，三高，它具有高可用、高可靠、高性能以及低延迟这个特点，可以看它这个架构图，而这个图里 DRC它其实会分为生产者和消费者两个方式，生产者负责从源数据库抽取了全量、增量数据，进行数据过滤一些这种策略，这些数据通过GRPC的方式发送给消费者，然后消费者会对数据进行一些优化处理，比方说执行一些并行策略，进行SQL合并等等，把这个数据写到目标库里面去。通过生产者与消费者的这种方式，我们就能够在源端和目标端分别进行各自的优化，通过这种方式我们能实现很高的性能和可靠性。

好，下面我们看一下DRC的几个核心特性，就是刚才我们说的三高一低。

第一个是数据高可靠，我们可以支持全量校验，数据抽取的时候可以做数据进行一一校验，同时还具备一定的修复功能。第二个也可以对在增量同步的时候，增量实时的进行数据的一个比对。第三个也是特有的它提供一个数据轨迹的功能，针对一些重要业务的数据，它可以开启这种数据轨迹，这个数据是从哪同步到哪来的，同步的情况怎么样？

第四个它还具有比较完善的这种数据冲突检测的手段，如果说数据发生冲突之后，还可以我们去制定以什么样的这种策略来解决这种冲突。

第二个是说的是链路高可用。你整个DRC它实际上是一个集群的模式，它任意一个节点的故障之后，都可以把上面的任务快速的切换到工作任务正常节点去，同时我们还支持断点续传，把整个任务切换之后能够迅速的去自动去继续有上次的这种任务，而不需要去重新执行。

第三个是高性能。在云端和目的端都采用了种种方式来进行这种性能这种提升。比方说我们采用了SQL合并，而且这种并行技术复制效率比通常的这种方式会高很多，同时它还能够根据我们的任务的不同特点，在线扩缩容，而且扩容期间是不影响整个数据传输的。

那么第四个是一个低延迟，那么整个DRC能够做到一个很低的数据延迟， 延迟能够小于50毫秒。在我们京东内部的一个实际环境下，比如说我们从北京到宿迁两个机房，那么TP99只有20毫秒这样一个延迟。

我们下面看一下主要架构。

主要分为前面的控制台，调度引擎以及双活管道三个部分构成。前面的控制台我们提供数据源的配置，我们的agent这些管理，并且提供种种监控，我们的字段对比等等，同时还可以去进行一些操作记录，异常记录等等。

好，第二部分就是我们的引擎，我们可以分为消费者与生产者，那么消费者生产者是通过这种链路进行同步，另外我们的采集模块还会对任务的进度进行监控，去看看这种任务的执行情况怎么样，你的任务是什么样的，如果发生异常之后还会产生告警，通知我们的管理员进行处理。

下面是它的数据管道，数据管道它专门针对多活提供了特殊的配置，有专门的多活管道，还有这种处于日常的迁移同步的数据管道，以及给大数据用的ETL管道，它会针对每一种管道的特性做一定程度的优化，去满足不同管道的场景的特征。

那么我们底层目前也支持很多这种数据库，包括常见的My SQL，MongoDB、Clickhouse等等，包括Oracle都可以支持，包括还可以支持我们的缓存，以及Kafka这种中间件都可以步，功能非常强大，是我们目前京东零售和京东科技做应用的异地多活的一个基石。

我们具体看一下DRC-MySQL为例，看一下具体怎么去做的。

首先来说他会去做一个源端的数据抽取，由consumer做目标端的数据插入，那么在抽取的时候它可以有多种方式，可以进行这种全量的抽取，全量加增量顺序抽取，还有一种特有的全量加增量这种交替的方式，为什么会有这种方式？因为在我们的源端的这种数据库里面，可能由于数据过多，bin-log比较大，所以bin-log我们会及时的通过一种交替的方式把bin-log及时的抽取过来，然后存到本地进行缓冲。

那么当全量这种数据抽取完成之后，我们再把它的整个数据发送给consumer，这样就避免了我们历史数据过大，抽取时间很长，导致bin-log被覆盖的问题，同时在这种consumer端，我们也采用了这种多种方式进行这种性能的提升，比方说我们针对多个表，我们可以以表的维度进行这种并发的去进行写入。这种方式就能够极大的提升效率，但这种方式适用于表之间的业务关联性不强，它可以满足这种最终一致性。对于数据一致性要求比较高，我们还可以进行事务之间的并行。

那么第二种可以去根据你的事务的运行特点，去找出可以去并发执行的事务。比如说我们下面看这个例子，12345这5个事务分别去执行，我们通过分析这个事务就发现，那么1和23和45这两个事物是可持续并行执行的，我们再去进行这种写入的时候，这两个事务就会并行写入，通过种种的一系列并行策略，我们就能够达到一个很高的吞吐量，同时一个很低的延迟去满足我们在多云多活或异地多活这样一个对数据同步的高吞吐量低延迟这样一个场景。

在很多场景里面，其实就是在一些金融场景里面对事务的一致性要求比较高，所以我们这边还提供分布式事务。

它可以去支持这种XA、TCC和TAC这几种模式，去满足在微服务调用下，跨单元或者跨异地调用的一致性，同样它也具有很高的可靠性，它也是一个分布式的这种集群。

比如说事故发生故障之后，它可以去自动的就去回滚，并且去进行超时的检测，同时它具有很高的观测性，提供事务、各种管理后台、监控指标以及日志等等。

好，我们看一下第三个挑战，流量是如何进行这种切分和调度的，以及在这种过程当中，我们有些什么样的保护措施等等。

流量的切分我们是通过我们称之为一个流量网关这样一个组件来实现的，那么用户的流量从最上面我们可以看到到达流量网关，那么流量网关之后，流量网关会根据我们的配置或者策略，将流量根据指定的算法分分到不同的单元里面去，同时它的管理模块还可以去进行日志的采集，监控、告警以及运维管理等等。

除此之外，我们流量网关还具有流量这种纠错功能。如果它发现流量发错了，它会自动的把流量根据我们策略转发到正确的单元里面去，同时流量网关我们还可以支持限速熔断以及支持应用的各种发布模式，比方说蓝绿发布、灰度、权重等等，它提供这种Prometheus这种监控指标，比如说单元维度，host维度的纠错统计等等，这些数据治理的一些能力它都能够提供。

这边是它的一个功能全景图

最右边我们可以看到其他主要功能还是在这种流量的路由方面，比方说它在HTTP路由，就提供URL重写、重定向等等功能，左边是那些管理功能，包括还能提供一些我们日志管理监控管理，能够对业务进行一些分组，所以流量网关是我们进行整个流量划分，流量这种纠错，流量管理的一个核心的组件。

那么第二个我们称之为应用网关Phevos。

应用网关本质上是一个API网关，它负责把前端发过来的http的这种请求转发成对应的API调用，然后发给后面的微服务，它分为三层，有前端的font，后端的 server负责各种处理，以及的规则中心进行各种规则的这种管理和调度。

我们讲的是应用网关的一个功能全景图.

我们可以看到在前端它可以负责这种节点的伸缩，API的分发、流量控制、负载控制等等,在后端的它主要就进行流量的控制，比方说能进行协议的转换，参数的转换，报文的映射，同样它有熔断、降级的这种功能。

第三个是它的控制台，它既然是个API网关，那么在控制台上就提供整个API全生命周期的管理，比如说API的一些配置，API的部署授权等等，同样它还提供运维管理功能，比方说叫权限管理，配置管理的这种集群管理等等，都会通过我们的后置台进行很方便进行配置，这是我们的应用和应用网关。

好，第四个就是微服务的单元化支持，就是我们如果在多云的环境下，并如何进行满足我们的微服务的这样一个调用。

微服务我们称之为JMSF它当时采用了双模技术，同时支持我们的微服务和网格，为用户提供统一的一个微服务的能力，它是将服务的注册与发现，服务的负载均衡，服务的治理、服务的路由、服务的鉴权等等统一的进行平台化，提供给用户一个统一的服务治理能力。

我们在微服务平台支持这种常用的istio，spring cloud、dubbo这些常用的组件，并且还可以去对接 Nacos、SGM这些组件。

我们看一下微服务是怎么支持多云的。

首先在部署方面，我们可以采用一种多集群的部署方式，那么用户的流量从我们DNS或者CDN分发到各个不同的机房里面去，由LB和我们前面说的流量网关转发到后端上面去。那么云的这种lb这种流量转发的功能，它会把这种流量转发到后面的这种应用网关以及这种微服务里面去。那么JMSF也同样的具备这种流量控制能力，跨云同步和跨云访问的能力。

其次我们的这种多云服务，它具备多云的注册的能力，每一个这种云服务中心都可以有一个独立的这种注册中心，同样每个注册中心它也可以去聚合多云区的各个服务，并且把它相应的自动标识所属的云区域，那么服务实例也可以去拉取我们云上的这种调用，进行相关这种策略的配置及调用等等。

在多云的服务调用方面，我们有三种不同的策略进行这种配置，比方说默认的就是说我们不分区域提供一个全局的调用服务。第二个是说进行只是进行本地调用，只调用处于同一个云地域或者机房里的这种服务。第三个我们还可以配置首先是本地优先，那么服务优先选择本地域或者本地的服务，如果说本机房或本机房的机器没有或者发生故障之后，再去其他地域去寻找，通过这种方式我们就能够去满足我们多云的调用服务，在多云和性能之间做一个很好的平衡。

我们看一下我们JMSF的主要特性。

第一个是说它可以兼容我们的主流的开源的服务框架，包括Istio、Sprintcloud、Dubbo等等，都可以去支持

第二个它可以去支持已有的微服务进行这种迁移的方式。第一个，那么你的新应用是通过Sidecar模式，实现无侵入迁移，那么进行这种方式，无需做更多的工作。再一个是你的微服务，可以通过我们的服务同步机制参与到这种新架构里面去。

第三个就是说我们还可以支持复杂的业务场景，我们可以支持支持网格与注册中心相互同步、调用，支持同一服务下混合架构部署，支持Sidecar和SDK的虚机，容器混合场景，支持多集群服务网格，支持星链容器网络模式，支持容器Host网络模式，支持多控制面网格服务。我们的这种微服务可以进入各种服务框架，支持这种已有的应用服务的简便的接入，支持各种复杂应用场景。

好，我们下面看一下我们是如何把那些技术理念这种碎片化的东西是如何进行标准化，形成一个产品化的。我们介绍一下京东单元化的这样一个实践。

3.从技术理念构想到标准产品化，京东是如何做的？

这是京东单元化和应用多活的一个简版，实际比较复杂。

我们京东大概是会有大概三个这样一个数据中心，分别是北京中心，北京我们称之为中心单元另外还有两个是宿迁和广州，我们称之为普通单元。

那么中心单元是有全量的数据，所有数据都在北京中心单元，而普通单元分别是有部分的一些买家，我们说用户的一些数据，用户数据会从这种普通单元往中心单元里面去同步，而商家数据只是从中心单元往普通单元里面去同步，这样的话我们每个单元里面都有了这种相应的商家和用户的数据，所以说能够做到一个请求，能够在每个单元里面进行闭环的调用，避免跨单元调用，变成性能的延迟。

当然有一些特定的数据，比方说我们的库存等等。库存这个意思是说全局的统一的管控，那么对于一些这种库存，那么所有的这种数据我们还是要路由到中心单元去进行统一管控的，那么对于中心单元来说它是一个核心，所以中心单元我们做双机房的一个热备，通过这种方式我们实现了这种应用的跨地域的多活，无论是宿迁单元还是广东单元发生故障之后，它的流量能够在分钟之内往中心单元或者说往其他单元去切换，中心单元有额外的核心的机房的热备。

好，我们再看一下我们的多云多活系统。

多云应用多活系统，它是以用户的应用为中心，以混合云的云舰为底座的一个产品，它能够帮助用户在同城或者异地建立一套与本地的这种生产系统完全相对应的一个多活系统，分布在多个云端的多个机房，能同时对外提供服务。

当故障发生的时候，那么多活系统可以在几分钟之内实现业务流量的切换，最大程度的降低故障的影响，那么用户在几分钟时间之内，甚至可能感受不到业务发生故障了，那么这个系统有什么样特点？这个一是我们实现了这种跨云的多活模块，不仅仅是分布在我们一朵云里面，而且可以划分在不同的云平台里面，那么业务流量我们可以按需的进行泳道式的路由。

第二个我们可以实现这种跨云的发布，可以通过我们统一的管控平台进行这种多云之间的统一的发布和部署。

三这种请求，我们通过一定的合适的配置，我们能够实现各个组件和服务，能够在一个单元之内请求闭环，减少跨机房当中单元调度，从而避免性能的损失。

第四个是数据一致性，通过DRC实现数据的毫秒级同步，有完备的数据路由、异常检测机制，在数据路由的每个层次，我们都具有这种写保护措施，防止我们数据的异常

这是我们通过了一个信通院的最高机制的认证，叫做“先进级”，也是说国内第一个能提供这种多云多活力的一个厂商。

其他厂商可能通过这种资质，它只是在自己的单一的公有云上通过这种资质，而我们是能够在多云这个环境里面下提供这种多活能力，那么这个是目前国内是唯一的一个。

我们看一下我们整个多活的一个架构，我们整个多活目前是支持单元多活，我们称之为异地多活和同城多活两种方式，这种方式下你的RTO就是你的系统切换时间能小于两分钟，那么RPO根据我们的网络情况和部署的架构不同，最高能够做到0，整个架构就是最左边的，我们称之为一个多活的管控层，最上面是云舰这样一个平台构成的，那么云上我们有了这种流量网关进行流量的分发配置，还有应用网关把流量转化成这种API，然后是后面的微服务，下面还有数据库和中间件等等，那么整个平台它具有这种流量保护的功能，那么就是说每一次的服务请求之后，它都会根据最新的路由规则进行计算，如果是这种非法流量就拒绝处理。

其次它这种流量纠错的功能，在流量网关应用网关及微服务过程都可以进行流量冲突检测。如果发现流量打到错误单元，那么它重新会将流量路由到正确单元里面去。第二个时候它可以有本地优先的这种调用策略，优先调用本单元的服务，从而减少这跨单元调用给我们带来的新性能损失。

同时它也进行链路透传，把一些关键的路由信息透传下去，这个主要是给我们后面SGM监控提供支持的。

刚才我们说了我们整个应用多活，实际上是基于京东云云舰这样一个混合多云操作系统之上的。

我们为什么要基于混合多云操作系统？因为云舰它有几个特点，第一个是说它向下会融合一个多云的环境，它能够屏蔽下面多种云的差异，向上提供一个统一的接口，那么实现多云一体应用一致的运行，就极大的去降低了我们应用多云多活需要分别适配每朵云这样一种特性，那么这种适配工作交给云舰去做了。

第二，云舰能够向上去提供业务的所需的能力，它提供这种常见的 PaaS组件，包括数据库、中间件、微服务，同时还包括各种链路追踪监控，运维管理等等各种措施，帮助应用多活把整个组件串成一块，提供一个整体的生态能力。

云舰的用户使用跨云多活像使用一朵云一样，用户不需要去面对各种不同的云，它有相同的这种界面，同样的操作同样接口去管理，那么云舰目前已经在我们京东内部已经是使用了多年的，包括我们在双11、618、春晚里面，都是通过这种云舰进行跨云的这种跨机房这种多活以及这种管控的。

我们看一下我们这个称之为单元多活动异地多活单元的一个架构。

用户的流量从最上面来到我们GDNS里面去，我们GDNS会随机的根据它的策略，把流量分流到不同的单元里面去，那么流量再到我们的流量网关之后，流量网关会根据我们的配置或者路由规则进行计算，如果说它发现当前打过来的流量不属于本单元，那么它会把流量会转发到对应的单元里面去，进行一个单元的纠错，把正确流量然后向后转发给应用网关Phevos，Phevos同样它也会去进行一个单元的这种流量的这样一个判断。

如果他同样也发现有些逃逸流量不属于本单元，那么同样他也会进行一个流量纠错，把这种流量转发到对应单元里面去。

那么流量网关现在是一个HTTP层的纠错，那么应用网关是RPC这样的纠错，当流量到达到后面的这种微服务之后，那么微服务各个单元微服务的注册中心会形成一个双向的同步，保证我们每个微服务的配置都是一致的，那么用户的应用在微服务里面去访问本单元内部的，包括像数据库缓存消息队列这样的服务，做到整个链路在本单元这类型闭环，我们把这种数据层包括这种数据库缓存或消息，通过我们DRC进行一个双向同步。好，这是这个异地单元的一个多活架构。

那么下面管控层它会部署在一个三机房高可用的管控层里面，底下是我们的一个云舰。

这个是一个同城多活的架构。

总体架构跟单元都非常类似，它的差别就是说首先我们的流量它不是根据规则，是一个比例按比例进行划分的，因此不需要一个纠错功能。

其次它的这种主备单元里的这种业务是写主单元里面的数据库、消息和缓存，这个数据再同步到我们的备单元里面去，备单元里面的数据通常情况下不对外提供服务，或者说只提供只读的服务，这是同城多活和异地多活的一个最重要的区别。

我的这种被占面积的这种服务是写主站里面的数据。（这句话不明白，如有的话，删除掉吧）

好，为了满足我们这种同城、异地多活这种场景，同时为了满足各种云里面千差万别的设施，我们把整个应用多活抽象和提炼出一套单元化的模型，来支持业务的灵活的配置。

比如说我们有多活空间，分为这种同城多活和单元化异地多活两种空间，每个空间我们还有单元的这种模型，有路由变量的模型，有单元规则的模型，有域名的模型，每个模型里面还有具体的一些属性，通过这一整套的模型的完整定义，就能通过应用多活去适配用户的各种复杂场景，以及多云环境下的一个差异。

好，我们定义了模型之后，然后我们的这种管控端会根据我们的模型去实时监控我们的模型配置，如果说发现我们的配置发生了变化，那么这个时候它会把我们当前的最新的配置或者模型推送到我们的各个组件里面去，发送给流量网关、应用网关、微服务，或数据的这种访问代理里面去，组件根据最新的流量规则进行应用或者禁流等等。

整个组件为了去满足用户的各种环境里的复杂的场景的，我们提供可插拔能力，定制的一些标准的接口。那么在各个不同的这种环境下，我们只要按这种标准的接口去对接相应的组件就可以了。

那么当如果我们某个单元发生故障或者说我们需要做流量调整的时候，我们提供单元流量快速这种切换能力。

它可以在我们的这种工作台上通过web界面进行控制，也可以调动API进行控制。那么在切换任务的时候会自动生成一个工单，只要通过流程审批之后，把工单自动的转成切换任务，进行这种切换。

那么切换任务我们主要分成这4个阶段。

第一个就是准备阶段，第二个是禁流阶段，第三个是同步阶段，第四个是切换阶段。那么准备阶段我们会去做一些校验的措施，包括这种组件是否可用，它的健康度怎么样，包括这种用户的流量是否发生了这种迁移或者变化，进行前置性的这种判断和处理。

第二个是禁流，如果说用户的流量在这种切换过程当中，用户的流量发生了变化，那么它会有这种禁流规则，防止在切换过程当中，由于数据打到不同单元，把数据写乱这种情况，禁流不仅是上层的流量网关禁流，在流量网关、应用网关、微服务等等各个层面，它都会进行一个禁流处理。

那么第三个是一个同步阶段，那么他会去检测每个单元的数据的一个同步情况，如果说发现数据有积压，会根据我们的配置进行切换，或者说等待的这种数据同步完成之后再进行切换，这个是可以根据我们的业务场景进行配置的。

然后第四个就是切换阶段，它会根据我们的新的规则发布出去，去调整用户的流量，最后完成一个切换的过程。

好，刚才说的大致阶段，这就是一个多活发布的一个详细流程了。比如我们看最开始的前置，他会去进行一一的校验，然后对组件进行一个禁流，这样每个操作都是可以对它超时时间、等待时间、并行度等等都是可以去配置的。同时我们也提供这种默认的策略，默认策略可以去适合绝大多数的切换场景，那么对于一些特殊场景，我们可以进行各种各样的调整和配置。

如果说我们流量要发生变化怎么样？比方说我今天发现其中一朵云就发生降价了，有优惠了，我想把它流量更多的去切换到这个云上，这时候我们怎么做？这是我们现在的这种变更方案。

分流流量这种变化很简单，我们只需要在我们管控层面设置一个新的这种单元规则，比如说我们可以指定，打个比方说把单元4的流量调整成50%，那么其他的单个单元并分50%，这种单元规则配置完成之后，发布一个新的规则就可以了。

如果说我们扩容，要去扩充一个新的单元，或者一个类似于说新的机房的这个时候，我们首先要做到准备好一个新单元，在新单元里面部署好应用，然后把这个数据从其他单元里面同步到我们新单元里面去，等数据同步完成之后，我们再配置一个新的单元规则，在那单元新的单元规则发布出去，就完成了一个新的单元的接入了。

那么下线单元就比较简单的，我们只需要把要下线单元的流量切成0，然后再发布一个新的规则，就可以把这个单元比较容易的进行下线。那么无论是这种分流策略的变化，还是做这种新增单元的策略的发布，你都是可以在分钟级甚至秒级直接实现。

整个这种操作无论是这种发布还是说这种切换，其实对用户来说其实都是比较很复杂的一个操作，所以我们专门提供可视化界面，帮助用户去管理。

那么我们可以定义我们的各个空间以及单元，是可以去定义各种单元流量的划分方式，划分比例，可以去在微服务里面去定义我们单元化的路由策略，转发策略等等，可以去在数据同步里面配置保护策略。

第二是DRC里面去配置我们的数据同步的策略、链路以及查看我们数据同步的状态。这是一个怎么去发布配置，我们是通过一个这种yaml文件进行发布的，这是切换。

然后这是一个例子，我们可以看到最开始两个单元都是同时有流量的，然后某一个点由于某种故障，我们就把黄色的流量把它切走了，切到这种蓝色流量里面去，我们看到在某个时间点里面黄色流量变为0的。

那么过一段时间我们把故障处理完成之后，去把流量切回来，你就看到流量就重新的恢复到原先的这种正常情况。就通过这种监控我们可以很容易的去观察我们整个流量的一个变化措施。

好，下面我们来看一下全链路监控。

全链路监控我们称之为SGM，它支持从移动端、前端、服务端一个整体的全链路监控，并且能够把三种链路的监控做一个串联的分析，帮助用户定位问题，让用户整个链路上的各种运行情况的一目了然、非常清楚。

那么除了它能提供这种整个链路的一个监控之外，它还可以去让用户从一个开发者的角度，通过一些配置完成一些业务层面的监控。

比方说你不需要通过去做一些埋点，就能完成类似于比如说像渠道转换这样一个监控，类似一种BPM监控的功能。整个前端的监控，它对用户的监控是一个无代码无侵入的，用户不需要修改代码，只需要进行一些配置，就能够进行这种整个链路的监控了。SGM的监控也是在我们京东内部大规模使用。

SGM监控在应用多活方面，我们可以提供进行监控的流量的指标，比如说TPS耗时，接口成功率等等，同时它还可以进行一些调用链的分析，分析每一笔这种调用的耗时状态等等，还可以进行一些这种调用链的拓扑图的划分，提供不同时期的这样图表的对比能力，帮助我们去发现某一个点的一些异常的原因，并且还可以自从这种告警日志和告警的能力。

4.多云多活的产业实践

下面讲一下我们多云多活的产业案例的一个分享。

第一个是达达集团的一个分享。

好，我们第一个案例是达集团的一个跨云多活的一个案例，达达以前是把业务分布在某个公有云和他自己的IDC机房里面的，达达跟到家合并之后，它需要跟到家的业务做一个上下端打通。同时以前由于达达使用这种单云的时候，大概是在2017年到2018年的时候，网络发生过好几次故障，给到他的业务造成一些困惑，所以达达到后来决定采用这种跨云多活的这种方式。

首先达达把他原先在机房里面自建的一些PaaS迁到我们京东云上，改用京东云的PaaS组件，同时完成一些云原生的改造。

第二个它把微服务的注册中心迁移到云上，去实现了一个跨云的多云的部署，它的业务可以去在多云里面去就近的部署和调度。

第三步是进一步去实现数据的一个双向的同步，进行业务的拆分，完成它的单元化的改造。

最后，它完成了流量的调度策略和分发特性的升级，完成流量调度方案的优化和各种措施。

那么在他完成这种跨云双活的改造，到当年它的双11就成功的支撑了每日1,000万订单这样一个处理。

同时在这个过程当中达达的业务和到家以及这物流进行了一个无缝的整合和打通，整个链路都非常顺畅，同时在到从它原先的这种架构到跨云多活架构的这种整个过程当中，它还实现了传统的架构到云原生架构的一个升级，实现了技术的升级换代。

同时在云上它还能够更好的去执行资源层面的一个弹性伸缩的管理。达达在2020年的时候就实现了，除了大数据之外就实现成本节约这种上千万元。

达达集团的部门负责人也说，通过这种跨云双活的能力，他把这种算力和资源都迁移到了云上，在整个计算资源层的弹性方面，成本压缩以及业务稳定性方面都得到了提升。同时在过程当中也实现了技术架构的梳理与升级，并且实现全链路业务的打通，取得非常好的收益。这是达达的一个案例。

下面我们再看一下这种爱回收的一个多云建设。

爱回收它原来是在一朵单云上，那么后来他由于种种原因，他决定需要去建立一个跨云多活的这种方式。

那么爱回收的这种跨云多活，它分为几个批次来进行的，第一首先说它把应用进行了一个分类，它把应用分为普通的这种应用，以及需要高频次去调动的基础应用，把应用梳理完进行分类之后，再根据各个应用的这种调用关系和依赖关系进行一个批次的划分，按批次进行迁移。

那么在每个批次进行迁移的时候，它首先进行这种数据库的改造，把数据库完成一个跨云的部署，然后两边的数据做一个单向的同步。那么完成了数据库的部署之后，还得把它的应用做一个双云的跨云的部署。首先让数据写原先的主集群，那么然后备集群就是只读。那么完成了这种基础应用的双活之后，还再进一步的做应用的跨云的多活。通过这种分批制的跨云和迁移的这种实现方式，爱回收很好的完成了这种同城多活场景下的一个双活的场景。

那么通过这种同城双活，它很好的实现了它的业务的一个弹性，同时它整体成本跟原先相比整体下降了20%。

同时在这种过程当中，他也完成了这种对于整个它的业务的一个梳理，实现了业务的架构解耦。它原来的一些可能就要去循环调动的一些这种方式改成了单次调用，整个业务更加轻便和灵活。

通过应用多活进行同城双活的案例。我们可以看到无论是达达还是爱回收，通过实施多云多活，取得业务连续性的提升和一个成本的整体下降。多云多活，之所以被称为技术皇冠上的明珠，除了是说它具有巨大的价值，能够极大的去提高用户的业务连续性之外，还因为它具有巨大的实现难度。我们京东根据多年内部实践和打磨的这种技术，把它整理抽象出来，进行了一个产品化，像我们应用多活产品能够帮助用户在较短的时间之内去搭建一个跨多云多活的系统，帮助用户在业绩连续性方面得到有效的提升，谢谢大家。