开发者学堂课程【Nacos 开源、自研、商业化三位一体：Nacos 开源、自研、商业化三位一体】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/958/detail/14879
Nacos 开源、自研、商业化三位一体
内容介绍：
一、Nicholas 发展规划生态
二、阿里巴巴百万实地实践
三、Narcos 微服务解决方案
今天的直播主题是阿里巴巴云生三味一体战略解读，Narcos 开源自研商业化三位一体，那三位一体，是将自研技术开源项目商业产品融合形成统一的技术体系，Nacos 在阿里巴巴起源于2008年的。采石项目成长逾十年的阿里双11峰值考验一八年，以开源的形式输出了阿里十年关于服务发现和配置管理的沉淀，帮助数以万计的用户解决了微服务的扩展性和高可用问题，以推动微服务行业的发展，加速企业数字化的转型。那本次直播将重点分享以下内容。
一、Nicholas 发展规划生态
阿里云原生三位一体，战略解读，投资开源字眼商业化，三位一体。首先介绍一下云原生三位一体战略，其次介绍一下作为阿里原生核心产品的背景，在开源，阿里巴巴内部落地，还有商业化的解决方案情况，那首先在讲整个阿里与云原生三为一体的。
先介绍一下背景以及目前执行的一些情况策略，以及整个的一些优势，原生的意思就是就是说生育于长玉采用原生代表技术容器微福利，微服务服务网格 service 这种技术的，就认为是原生。
1、阿里云原生三位—体背景
什么是云原生?
云原生时代容器、微服务、Serverless 什么关系?
阿里上云后，自研、开源、商业化中间件什么关系?阿里上云后，云原生采用混合云还是共有云模式？
技术呢，那今天可以最大限度的让你享受在云计算时代的红利，比如弹性，对开箱即用，比如安全，比如稳定性，那第二个问题，就是说在音乐声时代，容器内服务所有粒子是什么一个关系呢？如左边这张图所示，容器，其实是把运维侧标准化了，通过 DUBBO 把整个预测标准化通过，然后做调度核心观念就是是通过调度提升整个资源利用率运维效率。
是不可变基础设施，那就通过不可变基础设施一个理念呢，屏蔽不同环境带来的一个差距，因为带来的一些风险，那在容器之上，那就是整个为为服务，它是一个应用架构，它是通过整个流量控制。提升整个高可用，比如说规度同机房优先，异地多活一些气流的一些机制，对包括一些限流的机制，它本质上就是控制流量或者一个高可用，核心理念是可变运营时，就是在运行时期间动态的修改流量控制的一些规则。
从而达到一个高考用的一个目的，这就是微服务的核心价值，其次就是业务本质上进行的是一个 Severless，快速的研发快速迭代快速上线，在这一层就是 service，不要感知底层的一些细节，然后进行上线，其理念就是生命是 API 声明式 API。整个写起来整个效率是非常高的，不用关心底层细节，这就是整个原生时代认为的服务微服务容器之间的一个关系，在整个原生时代到来之前，那阿里巴巴也在上元。
阿里巴巴的整个自愿的整个容器微服务的体系，这是开源商业化，到底是什么一个关系呢？
这个其实阿里巴巴在2008年的时候就已经开始做微服务的一个改造，并且在做了很多容器化的一些事情。这很多事做了内部的一些工程的一些实现，没有去做一些标准化的一些事情，当时也进行 dubbo，还有绕 KMQP 核心的一些微服务组件进行一个开源，并且在国内，取得非常大的一个分享，接着随着整个阿里巴巴上云。自然的这套体系是开源的体系，包括商业话题，他到底是什么关系呢？包括阿里巴巴，全站商品，那我们未来是采用混合云还是公有云的一个模式呢，下面就是阿里巴巴的整个三为一体的一个战略解读。
2、三位一体战略解读
策略∶用公有云支持集团上云，以开源为内核做内部扩展，以商业化为基础做内部定制;后端 BaaS 化，客户端轻量化，业务侧 Setverless 化。
Serverless (No Scrvcr，提升研发和运维效率;小程序、前端业务、长尾业务)
Function (Computc
Runtime(客户端轻量化，降低业务侵入，启动快，依赖冲突少;方便多语言集成;标准化，流量下沉-异地多活)
Alimesh
Dapr
BaaS(开箱即用，安全可靠，提供99.95%高可用，让业务更替聚焦业务开发)
微服务
消息
可观测
高可用
云原生网关
Sentinel
HSF
Metaq
F.aglccyc
Dubbo
Switch
ConfigServer
Notify
Prormcthcus
MSHA
Diamond
Kafka
Tracing
ChaosBlade
Eureka
Nacos
RocketMQ
ARMS
AHAS
首先，核心就用工业园产品支持阿里巴巴集团商品，这是一个基本的一个调子，因为只有上公有云才能更好的去享受云上的一些弹性，是红利，包括迭代速度发展效率都会快很多，其次，是以开源为内核儿做一些内部的一些扩展。阿里微服务体系，注册配置中心是基于 Linux 进行一个内部的扩展，整个 Eureks 是基于 Nacos 进行的一个扩展。
消息是以阿里的 RocketMQ 为核心，包括 Metaq,Notify,Kafka 为基础。这就是今天的基本的策略，其次是以商业化产品为底座，来进行一个内部定制，不如后端 Baas，是基于产品进行一个简单的内部定制。例如基于 dubbo，将 hsf进行一个兼容和扩展，后端 baas 化的好处是后端就可以开箱即用，享受安全可靠，让业务更加聚焦业务开发，而不用关心一些琐碎的细节。而且随着发展很多新兴公司是没有运维人员和测试人员的，即只有开发人员，在只有开发人员的情况下，能够快速通过云原生的运维技术，这就是 Baas 带来的一些核心价值。
运营是内测，通过一些漫画，这些 APP 的一些运行时，技术将整个的一些中间的逻辑下沉到车站，这样呢就会让客户端轻量化，降低整个业务的一个切入到业务启动的更快。也更方便，整个多元的一个集成，这样呢，也会让整个一个标准化往前推进把一些流量控制东西下沉，不用关心一些高可用的东西。其次，运行侧业务侧那我们提出的是service，有这个方式肯定有这个产品，那让业务呢，更关心整个业务开发，比如说。现在阿里的支付宝的一些小程序，前端的一些淘宝的一些业务包括。
3、阿里云原生三位一体优势
开源
生态/开放
商业化
自研
易用/安全
性能/高可用
4、Nacos 生态&规划
Nacos 简介
Nacos 优势
Nacos 生态.
Nacos 规划.
Nacos 社区
Doobs,secure 阿里巴巴吸纳这些开源产品，整个巩固了阿里巴巴的整个开源生态，并且包括跟周边的一些恢复的生态完成，非常好的一个整额，包括多语言的生态，都做成非常好的一个一个开放的一个状态。方便用户随意的组合基层，这样的话让社区一起去共建，推动这个标准，推动这个社区，让大家一起开源共建，推动整个中国数字化的发展进程，这是开元测的一个状态，然后通过开源呢，整个生态代码的健壮性。开放性都会非常的好，不用让用户有场锁定的这个想法儿，因为阿里巴巴的整个互联网场景非常的丰富同时也具有双11这样的一些大促的一个场景，也充分锻炼阿里的元生技术的整个性能是高可用的一些能力，尤其是在双11的这种考验下，所以在可用性和性能上是做得非常的卓越的，最后，在商业化上打造了很多解决方案，让用户能够以开箱即用的，快速的享受阿里巴巴经过十年打造的这些原生技术产品的一些能录。并且，通过开源的模式让用户拜托防止被用户厂商锁定的感觉，以上就是阿里原生三为一体的一个独特优势。
5、Nacos 简介
Nacos /nx:keus/是 Dynamic Naming and Configuration Service 的首字母简称一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台
仓库: https://github.com/alibaba/nacos
服务发现与管理
动态 DNS 服务
动态配置服务
这是一个动态的一个服务发现配置管理跟服务管理的一个平台，，由阿里巴巴的三款产品服务，发现动态DNS，动态配置服务三个产品的内核儿开源出来了一个大 boss，开元是通过阿里内部孵化的十年，双11考验的一个产品，三个产品，对内核儿进行了一个构建，一个输出，一个稳定性的可能性，那这个 https://nacos.io/是一个官网，感兴趣的小伙伴可以平时通过官网了解产品相关的动向，后边是仓库，如果说想贡献代码或者对代码感兴趣的小伙伴儿，欢迎去下载。最后也欢迎小伙伴对网站进行点赞收藏。就可以 release 到用户的邮箱中去，这就是开源的一个定位。
6、Nacos 优势
易用
稳定
实时
规模
实现了非常多的这个有非常多的一个实践，在开源的时候儿，取其精华去其糟粕，把阿里的三个产品最核心的部分的一些产品模型的一些交互模型进行了非常大大规模的一个优化，包括 API上，是非常的简单易用的，然后呢，由于是基于内部的产品，阿里巴巴内部的三个产品开源构建，产品是久经考验的一个产品，具有一个三个九的一个基本稳定性，一个底盘，这就是为什么 Nacos 开元之后，在0.2X 的版本就有像虎牙这样呢。
用户开始上生产使用啊，是因为是经过阿里内部生产使用的一个产品开展出来的。阿里内部对实时性要求非常高，因为慢了的话就会产生资本，因此系统优化上做得非常极致的一些优化。
在这些策略之中，今天在如果是1000个节点实例或者到一个数量的时候，那做到一秒之内数据变更配置变更服务变更推到，如果说是今天是1万个实力坚强，一个配置或者一个服务，那会在三秒之内就可以推到，如果是10万， 30秒之内就可以推到。
当然就是说随着规模的增大，的规模的增大，那这个不同的阶段是不一样的对，因为规模大了，如果推的快了，那反而可能会对的下一个服务产生一些影响，其实就是在规模上就哪怕是1.0，基本上就可以满足1万实力规模的一个扩展性要求， 2.0可以满足10万规模的一个要求，可以基本可以认为就是采用了 nacos2.0，基本就不用再考虑整个性能和扩展性的一些问题，因为从目前了解来看，在国内非常有非常非常少的用户可能会超过10万的的或者10万的实力的一个规模，因此 nacos2.0，在未来的三到五年都不会有遇到一些性能瓶颈，以上就是 nacos 的一些优势
7、Nacos 生态
生态仓库: https://github.com/nacos-group
目前在语言上就已经支持了几乎所有的主流语言，在 java,golang python 这三个语言上支持了 x2.0，那能充分的享受，整个 nacos2.0带来的一些极致的一些系统优化，享受一些超链接模型，服务模型带来的一些系统的一些提升，那剩下的几个语言，也在推动社区必须往前去推进，也希望对这个 Linux2.0感兴趣的小朋友。，然后还有对这个多语言，感兴趣的小伙伴一起去共建 nacos2.0的一些代码啊，其次构建了一核亲生，但就是阿里巴巴微服务的 DNS 最佳时间 D 就是 DSBBO 的首字母，s 是 sentinel 的首字母。
在这套阿里的这个微服务的 DS 最佳时间里边，基本上是 Java 最佳的一个组合，就按这个微服务的生态的时候，就基本上快就具备了阿里的大部分微服务的一个能力，那除了阿里的一个 Java 生态是做得最好的。那其次呢，就是说元生带怎么做的呢？那随着整个原生技术的推进，也出现了很多类似标准化，这些一些产品出现，比如服务改革生态位出现了，整个以外加一次性，那大公司已经跟另外一次有整个服务进行了一个打通，其次呢，再多语言包括营运是出现了一个产品的打法。
完成了一个整合，并且在阿里的一些高德的一些场景进行了一个大规模的一个录音，也欢迎对这一块感兴趣的小伙伴一起去共建，这是一个新的一个技术领域，这就是整个的一个生态，那基本上大家可以了解到，社区整个生态非常强大的。
8、Nacos 规划
哪 nacos 未来的规划是什么呢？在 nacos2.0的时候儿基本上就是说，性能稳定性高可用都基本上做到了非常高的一个水平，并且取得非常好的一个成绩，那面对未来，进入了一个维护状态，就是在1.4.0,1.4.2，那未来只做一些重大的一些bug修复，不会主动进行发展。
第二个变化就是 nacos2.0目前已经达到了一个非常稳定的状态。从1.0.x 到2.0.x 升级过渡的一个版本，在这个版本里边，目前已经从社区的反馈上来看，进入一个非常好的一个稳定状态了，因此从 X2点儿一点儿差的一个版本，将不会再去做整个。
1.0到2.0的一个兼容将去掉这些兼容的代码，让整个 nacos 代码变得更加精简，异度列入更好的一些性能表现，因此大家需要注意的就是，后边可能就是说升级是通过 nacos1.0.X 到2.0.x 一个升级过渡版本。然后升级过渡，过渡完成之后对于2.0.X 将不会进行一个个兼容的个操作，对这个事情大家可能要注意一下，会把所有的2.0的这些多语言进行一个很好的支持啊，上面也大概讲了，还有三四个语言需要支持一下。
在搭配上也做一些尝试，看能不能再整个多语言上有一个另外的一个思路，另外一个解决方案也欢迎各个小伙伴一起参加讨论，就是尝试，然后呢，另外一个在微服务领域，认为在最近几年将依旧是个趋势，所以会在2.2x2.2版本的话，对微服务有更深入的一些整合。有一些整合的技能的实现。性能表现在产品内核儿上，那会在2.3版本做很多插件化的事情，将一些诸如安全，一些商业化的一些定制的逻辑做插件化上去，让整个开源代码更加干净更加的一个建筑，那也就是说2.2X 版本做内核儿的一个版本，里面会在多语言服务网格的插件化上做出更多的一些进展的，也欢迎各位小伙伴一起共建。以上就是关于 nacos 上三个产品的主要的一些规划。
9、Nacos 社区
国内行业首选，被头部企业广泛使用!
2020进入中国开源活跃项目 TOP10 !
官网累计访问量:118w+
用户数:5000+
Star 数:1.9w+社区群:10000+
发布版本∶42（平均每月1个)
PMC : 7个
Committer : 30个Contributor: 192个
首先就是 nacos 社区，现在基本上已经有累计有官网118万的一个好一样，现在呢有5000多个用户在使用大 boss 大树呢，基本上接近3万了，也欢迎没有 Star 的小朋友赶紧的收藏，马上就突破2万 star。每个月也会会发一个版本，然后在2020年呢，也进入了整个中国开源活跃项目 top10，并且，成为了整个国内的一个首选，被整个头部的一些厂商互联网厂商广泛的使用。在这个过程中，也有大量的小伙伴给大 boss 进行提交代码贡献，感谢所有的这个给大 boss贡献代码的小伙伴和使用 Linux 的开发者的信任与支持，也希望开发者后面更多的贡献 boss 代码，一起去推动整个社区的一个发展。
二、Nacos 阿里落地实践
1、Nacos 阿里百万实例微服务架构
统一接入网关 Tengine
MSE 云原网关 Envoy
HSF Over Dubbo
HSF Over Dubbo
Envoy / Dapr
Envoy / Dapr
MSE 注册中心
MSE 配置中心
ConfigServer Over Nacos
Diamond Over Nacos
在阿里巴巴落地的实践过程中，那今天阿里的规模是非常大的，已经达到百万实力的一个规模，大家介绍一下阿里的一个百万实力的一个微服务架构，然后，再介绍一下阿里在服务发现配置管理的一个时间，就是说在阿里百万服务百万实力的一个微服务架构，拆成了注册中心，就是配置中心，为什么要进行这个拆分呢？
因为规模太大了，如果大家都在一起的话，会相互的影响，所以在超过十万，跑的超过十万就建议进行一个拆分。或者假如所在公司超过十万也建议提前进行拆分，这样就可以做到一个扩展性的能力，其次在阿里按照只能进行了一个区分，也就是在公关上进行了一个区分，上面是统一接入公关 Tengine，下面是 MSE 云原网关 Envoy。
上面进行一些抗流量，进行一些端上的 ur,包括证书加解密等，下面一层会进行一些服务的接入，例如上面接入一些泛域名，下面就可以接入一些子域名，就能共通过该网关进行快速的发布，假如只走上层效率就比较低，下层可以热生效，使得整个效率非常高，两个网关就阿里每秒超过100ybs 这个体量，建议进行一个两个网关的拆分，小公司假如不超过，建议采用 MSR 云原网关，就两者性价比相比较来说更加好一些。
今年在阿里云的落地过程中，也完成了 HSF 的一个架构眼镜，基于 DUBBO 承购了整个 hsf，也包括基于 nacos 承购了阿里内部整个 configserver，基本上是一个思想，并且在海外实验中，完成了流量，让业务获取了一个全局高可用的能力。
1、Nacos 服务发现实践
阿里这样的大公司，可能就有很多业务，比如说阿里有电商，钉钉，包括蚂蚁，包括很多的海外的一些业务，在多个业务域之间，可能安全域，网络域可能都是不一样的，因此呢，它就存在一个跨域互通的一个需求，在这跨域互通的需求呢，那阿里巴巴今就是通过一个网关进行一个跨域互通的，那在跨域互通之中，进行的就是 dubbo3.0的一个triple 协议。带来的好处是协议不需要转化，dubbos3是基于 envory。它的性能也是比较高，然后对于也是比较有好的，另外一个好处就是，通过云网关这边儿可以做一些白名单的机制，在安全上也有保证，那可以说跨域去互动，这就是在整个服务发现领域的一个实践上云的部分呢，比如像钉钉已经全部跑在云上了，那他是全部采用了阿里的，整个开源的就是商业化的一个技术栈。
是因为有一些跨云和微云的场景，能够方便的保持它的开放性，这是第三方产品的一个集成，产品就会有一个比较高的交付效率，这就是阿里巴巴的一个服务发现的实践。
2、Nacos 配置管理实践
配置管理的一个实现就说阿里巴巴今年之所以能够喝着咖啡，搞双11，效率非常高，其中的一个原因呢，就是说阿里巴巴有一个预案，系统是动态配置管理，这个系统动态配置管理就是基于这个 Linux 的配置管理，模块儿就是动态的做一些应用的一些修改，还有呢，一个就是预案平台，会定时地推送一些规则，产生一些产品的一些能力。在这个过程中 nacos 作为一个动态的基石，上面支持了微服务系统，高可用上台，前端生态，数据库生态。这是一些数据源的一些生态，包括这些开源的产品，大家可以简单的了解一下，那比如说在微服务的生态，支持了整个服务和路由的一些规则，举个例子，阿里在大促之前，会做混部上就会建立一个混部的一个环境，下完之后呢，会做一个全局的，一个机房的，一个流量的，一个切留，其实本质上就是推他们的，或者是拿出一个动态的配置，就把新的用不同。就是将一部分用户的流量切到一个新的机房，这样就进行了一些大促的准备，充分利用了一些混部机房切流的准备。
就是说在大促开始之前呢，我们为了提供整个系统的一个响应效率，那我们会把日志采用率进行降低，防止采太多的数据对整个系统的影响着湿性的影响，那高可用平台呢，为了提高整个系统的高可用，阿里其实在整个限流降级开关上做了非常多的一些事情，并且把预案里边，也有一些体检的医院，紧急情况下执行的医院做了一些穿插的一些演练，那我们会在。
会在过程中不断进行验证，保证大促的一个确定性，在动态ui可以看到前端展示的一些不同的东西。包括一些布局、氛围等都是通过动态 ui 进行调整的，也就是运用了微服务的一个可变性，可变性越强，就跟阿里一样能够享受这些能力，不需要发布就可以获得这些能力。
三、Narcos 微服务解决方案
1、微服务解决方案
微服务引擎(Micro Service Engine，简称 MSE)是一个面向业界主流开源微服务生态的一站式微服务平台
三位一体︰阿里微服务 DNS 开源最佳实践＋商业化解决方案＋阿里双十一大规模生产实践验证
MSE微服务引学
高性能
高可用
Ingrcss ( Fnvoy)
网关
竞争力
Dubho/Spring-Cloud-Alibaha/Fnvoy
服务治理
服务框架+服务网格
控制面
Nacos/Zookeeper/Eureka
高集成
安全
注册中心+配置中心
注册中心配置中心，然后服务网格儿服务框架，法官要整个控制面，这四个部分是可以用户灵活组合的，可以选择自建，也可以选择我们商业化的产品，当然，如果先择商品就以获得，相比于其他的一些厂商要开展自荐，独特的优势就是三维一体，首先在看原作。
基于 bubbo、nacos、spring 这套体系是一个开源的最佳组合只有成千上万的一个小伙伴是不断使用的，开源持续共建的，一个活跃的一个生态开放的一个生态，其次呢，在商业化上提供了非常好的解决方案，能一站式的获取阿里这十几年沉淀的一些被服务的能力，而不用说再雇佣一个庞大的团队去运维。管理这些东西就是内部生产，之前讲解过。是经过双11大规模生产严重的。是经过双十一等的验证的，所以不需要担心稳定性等的问题，在阿里打造的核心竞争力是高性能和高可用的能力，核心是安全和高集成的能力。
2、服务网格解决方案
阿里服务网格(简称 ASM )是一个统一管理微服务应用流量、兼容Istio的托管式平台
ASM 中 Istio 通过标准 MCP 协议跟 MSE 中 Nacos 打通;MSE 服务治理基于 ASM 流量治理原子 API 做服务治理
mse 跟整个 istio 个产品组合做了一个整个服务网格的一个解决方案，首先呢，在 nacos 支持 MCP 协议，把服务同都同不到 ASM 的整个艺术控制面，控制面就可以通过原子的一些流量控制的 API 进行一些3D 开的流量控制。还有一些法官的一些流量控制，接口是非常原址，语言可能比较难懂，和微服务很类似。
在整个服务治理过程中结合了 istio 的一些流量治理能力，进行了服务治理更高程度的一个抽象，更符合业务视角的一个服务的服务的能力，让用户更加快速进入云原生网关的服务时代，也解除了被厂商锁定的一个问题。
3、跨域互通方案
一些大公司公司，可能有跨域，包括多个 region 的一个部署需求，这样的话，它整个多个 VPC 用户的 VPC 之间网络不通，包括边缘节点之间部署网络不通，或者是有跨域，然后协议可能也是不一样的这边，比如 APP 里边儿的dubbo，也可能是不同的协议安全域，可能比如说不同的业务属性，安全与也不一样，还有一个为了高可用，它会做多区的一个部署，之后就会有服务打通的一个需求。
打通的过程中，mse 推出了一个云原生网关的产品，就可以完成跨域的互通，以非常低的一个成本去做。那说白了走网关的消耗是非常小，现在是非常高的，而且网关之间提供了一些白名单的一些证书的机制，保证整个通信过程中的一个一个安全性，然后大步的场景，建议都是通过运营商网关去解决，还有小部分一些场景，比如说服务调用。服务两个业务之间是吧，网络是通的，而且服跨域调用非常大大大的意思，比如说，超过每秒100万的一个 wbs。
协议不同可以通过 dubbo 到协议的一个转换，走网关可能消耗会比较大，就会考虑走 nacos-sync，缺点是一些同步以及安全是比较弱的，因此跟多清空是期望用云原生网关这种模式,管控能力比较强。
4、高可用解决方案
大促高可用体系：边压、边限、边看、边弹
在大促的时候就是以上的或者是几倍的一个流量的一个增加，假如流量准备不充分，就会把这个系统打跨，导致整个大促失败，会造成巨大的一个经济损失，但是准备太多的资源，就会产生大量的一些资源机器的浪费。因此阿里是如何进行整个全链路压测，然后提高整个这个大促的，这个利用率的，在这个整个圆产品这一侧做了一个大促的一个高可用保障体系，就是边、边限、边看、边弹，边压就是从用户的入口模拟用户，进行一些流量请求，请求达到云原生网关的时候，是流量的一个入口，在入口中跟 AHAS 中的 Sentinel 进行整个，在入口网关。流量进入之后整个业务表现为，可以集成 arms 系统，这个系统中可以看到整个业务监测的一些指标，整个资源使用类，异常码。如果发现超时异常可以通过链路码从入口到业务侧查看问题出现在哪里，假如在用户容器发现超时比较严重利用率比较高，就可以利用一些弹性的技术，将容器动态弹上去，就能够高效的进行大促，也不会有资源的一个浪费，在入口处实现资源的高可用。
5、多活解决方案
同 Region，同 AZ 优先，Region 内容灾﹔跨 Region 异地容灾，通过网关打通跨 region 服务
在阿里内部，相当于叫同城双活，跟这个异地多活两种同城双活，意思就是在同一周内这个多 easy 的一个中单，流量是通通为最优先的， nacos 是一个 APP 的协议，在两个机房中，如果说有一个机房或者网络有问题的话，另外一边，而是放弃一致性，保证整个这个数据的可用性对那么。在整个服务系统里面提供了一个同 AZ 优先的一个能力，第一是平时过程中整个业务响应比较快，第二十假如第一个机房有问题，可以快速将业务打到第二个流量.那也更快速的，就是说整个链路比较无损的快速的恢复，那只需要通过 MSHA 把这个机房的入口流量快速的切到可用的一个机房，这个机房的流量就可以快速的恢复异常了，恢复正常了，那就是说这就是我们同城的双活或者是通 AZ.I DC 如果多一个机房，可能会又多一个机房的一个成本，那对于双双机房部署可能是目前性价比比较高的一种模式。
Region1和 Region2两个服务之间可以进行一个全局的切流，或者跨 region 的一些服务调用，在整个网络正常的情况下是通过跨域进行网关，这样就可以从架构上进行管控，清楚哪些服务是可以跨的，哪些服务是不可以跨的，假如不进行管控，网络出现问题是不知道的，跨的都知道，流量也知道，就可以进行故障演练时，从流量上断开，查看对两边影响到底是什么。
这个管控能力是比较强的，所以切流的时候，假如一边有问题也就是说网关之间的调用失败，影响是明确的。出现问题的时候 MSHA 就可以将流量从一个 region 切到另一个 region，尽量增加服务的可用性。这就是一地多活的解决方案。
