一、云上网络稳定性体系建设
网络的稳定性是业务稳定性的一个基石，网络稳定性面临非常多方面的挑战，比如网源的故障导致的异常，传输链路的故障导致的异常，或者网络攻击导致的异常，如何应对网络稳定性的挑战,采用责任共担的模型，责任共担的模型好比在云上搭积木，因为在云上搭建业务，做稳定性的时候，它一定是责任共担，阿里云提供的组件好比积木的基本的组件，用户在使用云的时候，要把这些组件合理的组合在一起，最终，架构才具有足够的稳定性。搭建整体的稳定性的过程当中。
网络稳定性关注两个点，第一个点是面向失败的网络架构的设计，第二点是聚焦可持续的网络运营，面向失败的网络设计要留足冗余，要考虑到每一个点如果挂了应该怎么办，第二点是持续的网络运营，如何快速发现问题然后把业务做一个逃逸。聚焦两个方面。第一个就是在架构设计的层面从容灾，容错，容量的角度做网络不同业务场景的架构的设计，第三点是阿里云目前有哪些产品化的能力能够帮助网络的可观测、故障恢复以及容灾演练。
二、面向失败的架构设计
接下来分享常见的云上网络架构设计的最佳实践。首先，一个同地域网络架构设计的最佳实践，对于同地域网络架构最佳实践使用到的一个核心的原则是多可用区的部署，它可以帮助实现一个高可用的架构，因为可用区是一个独立的故障域，对于阿里云,每一个可用区的建设都会遵循一个非常高标准的机房建设，且标准不低于B级，或者是高于T3+的标准，这个标准意味机房里面任何一个单点的故障都不会影响整体业务的运行，对于一个可用区机房，它作为独立的故障，把它作为容灾基础的组件做整体的同地域的网络设计。
接下来以一个非常经典的三层架构，从端到端看，从网络的业务入口通过公网的EIP，负载均衡的网元是一个跨可能区多活的架构，业务的ECS部署到不同的可用区的子网当中，包括后端的数据库，采用跨可用区的容灾。阿里云在做产品设计时，EIP产品的底层架构做非常充分的冗余，所有和运营商对接的线路，它都是双线带保护，而且是双机房分开的,这个部分也符合冗余的架构。
在容量方面的规划中，其核心有两点，第一个是要做好IP规划，在云网络的专场发布IPAM的能力，这个能力可以帮助做整体的IP地址的规划，核心实现的是IP地址不要有冲突，要合理的利用IP地址，否则会出现IP不够用的情况。第二个在容量方面，弹性的架构利用云上的现成的能力，在做传统网络的时候做规格，需要做资源的预留，或者做资源的容量规划，但是在云上能比较多使用一些弹性架构，比如ALB和NLB，即弹性伸缩组。更多的使用弹性架构，在面对容量问题的时候可以更加的从容。
在云上跨地域的可用性的设计中，云上跨地域相对比较简单，因为阿里云的云企业网CEN产品。云上跨地域的容灾设计核心依赖CEN产品，这款产品在做可用性本身的规划的时候，分成两个点，首先第一个点是对于单地域VPC接入到CEN的时候，建议至少要使用两个可用性的VSW ENL接入到转发路由器，在跨地域连接的时候，阿里云的基础的基础设施-骨干网是阿里云的底层网络，实际上采用多条专线配主备环网，任意的两点之间都有不低于三条路径，实际上冗余性已经留足，在冗余性之上做到快速的切换，减少对业务的影响。
阿里云有一个技术是快速重路由的技术，当任意一个链路抖动的时候，为减少业务客户业务层的感知，它会有一个主动的包的重传的机制，举一个真实的案例，阿里云最近保障非常大的国际的活动，活动使用CEN做一些跨地域的转播流的实时的传输，在这个期间主动从路由技术，监测到大概有50次的触发，有可能是一些端口的抖动，或者是一些板卡的异常，但是在客户业务上的感知是无感知，因为可以做到一秒以内切掉。
下一个部分是混合云专线的高可用设计，稳定性和成本是一个不太可调和的天平，对于混合云专线面临这样的问题，因为在专线面临的问题是对于上云这一段无法做弹性，不可能买非常大带宽的专线做冗余，遇到业务突发的时候做弹性，在这套专线混合云组网的架构里面会面临着带宽规划的问题。所以会发现在架构上出现一些不同的选择，它分别对应不同的SLA，第一种选择是当业务可以忍受一些中断的时候，实际上专线就只有一条，这个时候可能选择逃生通道，就是当专线挂掉走公网，这是选择一种逃生通道，第二种架构是选择双专线，双接入点。
这样做到全冗余，但是在这种情况下，成本相对也是最高的。中间的一种状态是一个相对特殊的状态，它指的是双专线，是同一个接入点，这个时候通常是客户业务特殊的场景，比如业务有一些极致时延的追求，无法接受双接入点带来的时延差别，一些抖动或更高的时延，这个时候会选择双专线同一个接入点，目前阿里可以做到的能力是把这两根线分散到不同的接入设备上去，做到高可用。
这部分是容错,在阿里云的切入点到机房，再到端到端，如何通过动态的BGP做容错,从接入点到阿里云的中心机房，容错如何做，目前阿里云能做到的是超大规模的城域光纤全互联，同地域接入点和可用区机房，它是光纤全互联的，而且是冗余连接，是毫秒级的切换，容量里面有成本的考量，可以考虑业务是否是一个可用性要求非常高的，就会引入基于业务优先级的QOS的设计，比如一种设计思路是建设多组专线，把不同的业务调度到不同的独立专线上，从而保证一些高优先级的业务的可用性。
另外一种思路是在同一组专线,利用产品化的能力，比如VBR的带宽的设置或阿里云专线，目前某些接入点具备QOS的能力，通过阿里云自带的QOS的能力帮助实现业务分级以及QOS的保障。
接下来展开看容错的机制，对于专线，故障切换有两种非常经典的方法，第一种方法,基于健康检测的管控层面的切换，大家经常会遇到配到对端的健康检查，中心管控发现健康检查失败，手动把路由切掉，还有一种就是基于动态路由BGP，基于动态路由BGP的快速的倒换，目前和阿里云拉专线的时候，推荐做法是采用BGP+BFD加快速倒换组三管齐下，可以做到毫秒级的故障发现和自动化的切换，对于同一个倒换组的两个VBR,任意一个路径的故障，通过BGP的快速的检测，可以在倒换组内实现毫秒级的切换。
在其他的混合云组网的架构中，就是VPN组网，VPN的组网在做整体的可用性设计时，在思路上延续公网的组网的思路，通过引入多VPN连接，通过引入VPN链路的连接实现整体架构上的冗余和架构上的可用性，VPN是一个基于底层的公网的overlay的隧道的封装，首先有一个点就是在底层的公网链路的选择上，可以选择多运营商的公网出口做underlay的高可用的容灾，有多隧道之后，如何做到多隧道的错错和快速的倒换。
在网络层面，所有的时候都不推荐健康检查和管控切换的方式，因为太慢，所以推荐通过BGP的方式，对于阿里云和VPN产品做对接的时候，通过BGP的方式实现VPN的对接，有一个点是单条VPN的链路，它的带宽是受限的,单VPN的带宽基本上不会超过一个G，对于阿里云，在官网上透出的单VPN的带宽是一个G，想要实现更大的带宽可以通过BGP的ECMP负载的方式，前面两种是相对比较传统的组网的方式，专线的组网和VPN的组网，接下来组网很自然的演进，3rd SDWAN的组网方式延续专线组网和VPN组网的基本的思路。但同时又做一些加强，端到端如何做好SDWAN的可能性。
首先第一段是上云链路，这一段做多underlay的设计，上云的拉的专线，包括多运营商链路的选择，都可以考虑进来，利用SDWAN设备，它可以纳管多underlay线路的能力，接多线就有不同的底层链路可选，在底层链路之上，SDWAN技术会做一层overlay的封装，这层overlay的封装，不同的厂商在实现上可能会有所不同，到云上之后,采用一种软件部署的方式，就是VCPE的方式实现云上的SDWAN的部署，做到云上的SDWAN双击的高可用，不同的厂商对于高可用的设计都不太一样，但是由于云上本身一些特性限制，发现它的一些HA的，健康检查的设计不太好适配，最终实践下来的最通用的方法还是BGP，这里面核心是云上部署SDWAN的VCP双击之后,和阿里云的组件转发路由器做BGP over Ipset，利用BGP的自动倒换的能力实现整个SDWAN在云上链路的高可用以及自动化切换。
容量部分，由于存在自建的这一段，意味着端到端的链路不可能具备弹性，需要利用业务分级和QOS的能力做好整个业务的规划。业务的高可用,首先对于7层业务高可用核心是阿里云的网源，就是在云上可以尽量多用云原生的网源，因为它天然的带一些多可用部署和自动化弹性，还有一些健康检查的机制。当单一可用区或者单一Region发生故障时，有一些基于公网探测做两地三中心的高可用的架构，实际上用到的是全局流量管理GTM的组件，这个组件对在不同地域部署的两地三中心的业务单元,做一个实时的健康检查的探测，基于探测,发现地域整体不可用,通过DNS方式把业务调度到其他可用的地域。
三、可观测、应急快恢和故障演练
关于阿里云的自动化产品能力,如何做到可观测、应急快恢和故障演练，核心分享两点，第一个点是阿里云-网络智能服务NIS产品，它是把底层的大量的探针和日志收集到的网络数据的能力进行呈现，比如topn流量，流量洞察的分析。今年发布所有数据提供API，可以把数据拿下来自用，另外一个部分是除了日志，还有一些自动化的能力，比如对网元的阿里云的健康检查，站在阿里云的角度，对网源做一个整体健康检查，输出一个健康检查报告，或者做一个路径，端到端的探测和分析，可能是TR的某一条路由于漏配，导致端到端不通。
关于故障演练，产品化能力核心,分享两个产品，第一个是在应用入口侧的网关产品负载均衡ALB和NLB，目前可以做到对外暴露的服务IP在DNS的手动摘除，可以模拟单可用区的故障，从而做业务入口的故障演练，另外一个是高速通道专线侧的，这个部分目前可以支持端口BGP以及阿里云上VBR组件的故障模拟，可以模拟端口，VBR和BGP的故障做故障演练。
四、客户案例
首先分享一个案例，它是一个出行服务商，客户是跨云的端到端的组网，在国内它的IDC选择多专线与阿里云上的互通，多专线采用多接入点BGP+、BFD+快速倒换的一套机制，在跨国、跨地域方面,直接使用阿里云的CEN，在跨云互通方面，采用云原生的VPN产品以及多隧道ECMP的方式，实现整体的端到端的跨国跨地域与跨云的高可用的链路的设计。
其次分享阿里巴巴稳定性容灾建设最佳实践。分为四部分介绍，主要介绍容灾话题，容灾主要是偏向于应用容灾。首先介绍当年阿里巴巴异地多活的备景以及如何做最佳的实践和相应的产品到云上帮助客户高效、低成本的快速实现同城多活和异地多活。最后是相应的效果演示，把单可用区注入ECS，相应的节点注入故障并且断网，看秒级切流的效果。
五、阿里巴巴核心电商架构演进及稳定性体系建设
每一次技术架构演进都是用于解决当时面临的问题，比如DevOps是加速整个上线迭代，微服务架构是提升整个应用开发的效率，以及提升应用的扩展性和稳定性。
部署方式的改变,例如容器化和k8s，它是极大的提升运维效率，并且提供运维的标准，把整个运维的手动的方式变成声明式的方式，变成自动化，通过k8S，rest API和YAML方式，再往后就是基础设施。云原生的技术架构的核心,第一是极致弹性，第二就是降本，第三就是提升极致的效率，它可以满足应用的敏捷开发，快速交付，降低试错成本，高速提高整个需求的响应速度。最终所有技术都是为业务服务，提供快速创新快速试错的实验田，今天对应的整个阿里巴巴的技术架构演进定义为五代架构，前面从1.0到3.0阶段定义为被动演进，从4.0到5.0阶段定义为主动看见。最早阿里是单体的java应用，但是随着业务快速发展，单体的架构满足不了业务快速上线的需求。
举个例子，2008年之前，在做五彩石架构项目之前，微服务架构改造做拆分，所有的业务，包括交易，商品，会员，所有的业务都是在一个大的java应用中，当时面临的问题是调试，研发代码很快，但每次做编译构建的时候要30分钟，所有的功能都耦合在一起，当时面临情况是写完代码做编译构建时间长,整个微服务拆分是用来解决效率问题。
第二个是稳定性问题，所有的业务都不在一个进程里面,一定会出现某一个新来的研发同学，一般后台都给新研发同学写，写了一个慢SQL,大家都用oracle，导致前台业务把数据库拖挂，导致前台业务受到影响，备PR故障，这是真实的发生在身边的故障，整个微服架构拆分的备景，看4.0的单元化时代，做异地多活，做单元化，做容灾，核心是解决容量和容灾问题。它解决业务快速创新问题。第五个,当发展到一定程度以后，很多企业面临发现资源利用率，CPU利用率是不饱和的，随着核数上升，一定会有降本的需求。
云化的时代可以极大第一提升规模，第二是降本,故障从阿里的所有实践经验来看，是无法避免的。可以通过一些手段，比如架构的持续演进、架构的持续优化以及流程机制的持续建设，尽可能的降低故障发生概率，降低故障发生以后的影响面。确定性是架构的设计原则，容错、容量、容灾尽可能确定从架构的层面降低故障发生的概率。对应点、线、面。容错是应用做强弱依赖梳理，做好隔离，做好故障转移。阿里每年在做双11之前都会做强弱依赖梳理，相应的弱依赖要配上相应的熔断和降级，对应的容量就是本次的上限容量能否支撑双11的活动。所以做全路压测来看读点 卡点、慢点解决。容灾是一个更体系化面的东西。后面两部分主要是解决降低故障发生的影响面和降低故障发生概率。
这是降低故障发生概率，每个研发人员定一个三板斧的原则，就是可回度，可回观，可回滚。这是红线。每次研发要做发布，必须要满足红线，另一个是1，5，10，它是当故障已经发生能快速去解决降低故障影响面，快速发现。
六、阿里巴巴容灾架构最佳实践
下面介绍容灾。主流容灾架构图是以下几种，首先是冷备，同城双活，两地三中心，异地多活。冷备只停留在理论中，它就相当于是车有个备胎一样，很多企业像有一些金融机构，它尝试使用冷备建设，但当出现关键问题的时候，它没办法切流。
因为冷备里面意味着有一个数据中心是冷的，不工作的。线上系统和应用的版本，还有代码是不断的变更的，无法确认流量切过去以后是否能满足预期，如果切流过去以后面临的数据丢的问题，或者带来二次灾难，决策人可能要备更大的决策的事故，甚至受到处罚。第二个核心原因冷备始终有一个机房，有一个数据中心，它是不工作的。会产生资源浪费。
在同城的容灾的方式一般都是以同城双活为主，同城双活就是应用双活，数据储备，相当于两个可用区，或者两个机房的应用是对等部署。理想情况对等部署，很多情况是做不到的。数据是都在主数据库写，读优先本IDC本可用区来读，它能够解决冷备的容量和切流问题，但是它无法解决跨省级的分活水电的灾难，相当于两地三中心和异地多活，两地三中心兼具冷备和同城双活的缺点。无法做到跨省级的流量切换，跨省级容灾。
也无法快速的去切流，恢复，最后一个是终极的形态-异地多活。异地多活很多情况在真实客户落地的时候的复杂度会非常高，因为异地多活，它不单是一个纯技术问题，它还涉及到业务研发团队进行改造，因为用异地多活，今天的技术是无法解决跨城的网络传输的延时问题。
如果是同城多活，用主备的方式，一个主库写，保证数据一致性，异地比如上海到北京，可能甚至到国外到张家口不同的地区都有机房，机房与机房之间一次核心的请求可能有四十几次的数据库调用，每一次调用都会有跨省的延时，最终加起来C端用户是否能承受,前提是要做单元化。如果想保证它的效率.当年阿里做异地多活产生的备景是两个点，第一个是双11太火，第二个是杭州太热，双11从零九年开始推出到一九年的十年的时间，交易量，并发数已经翻了上千倍。
第二个是2013年杭州的夏天是最热的一个夏天，连续差不多一个月时间都达到将近40度的高温，当时的杭州市政府要给一些用电大户做限电，阿里需要限电。阿里当时在杭州有很大的IDC，所以当时整个阿里研发和架构师，在天气燥热里度过，担心被政府限电，因为一旦机房被限电，意味着业务流量会受到损失。在这样的备景下,整个公司提出了一个目标，相当于是一年完成同城双活的POC验证两年完成上海和杭州之间的双活，三年完成最终的异地多活。这个是容灾问题。另一个异地多活的核心是解决容量问题。同城多活数据库是单点，随着业务增长，数据库一定也会出现容量问题，阿里在建设异地多活的设计初衷,理想情况是所有的业务，用户都能够做到异地多活，当出现问题可以瞬间的秒级的快速的切流，但是理想很丰满，现实很骨感。当做异地多活的时候，拆分出淘宝在2013年的整个的核心交易链路的应用拓扑图,里面是很复杂的调用关系，当时参考一些国外的厂商，像Facebook，它是最早的开始做单元化，做多活。
Facebook是比较明确的以人来维度，人是能够闭环的，所以当时是按照人的维度，UID做多活，参考同样的电商的先驱老大，电商的AWS,在中国的某个地域，买一件商品，但到美国或者其他国家，加入购物车以后，再打开发现是没有这个商品的。所以它今天没有做到全Region级别，全跨国级别，跨城市级别，它只是按区域来做的，再审视如今的业务的情况，业务的维度分为买家、卖家和商品，核心要保的是整个下单的链路，下单链路核心的参与者是买家。所以把买家的核心链路要做多活，诞生整个当时异地多活的设计原则。首先核心要保整个买家下单交易的链路，和买家相关的都放到一个单元里面做单元化，单元内的调用尽量保证封闭。和买家链路相关的共享类的数据。比如商品，它是属于全局的，无法按照买家维度，按照城市各个地域级别拆分，又提出共享单元，共享单元是在中心单元来写。每个核心单元叫阿纵，每个核心单元冗余，阿纵读共享单元。另外无法拆的要求强一致的。
这个是中心单元-g中。举个例子，商品扣减库存，扣减库存一定是要求强一致的，所以按照维度,最终拆除的整个单元,就是三个单元，核心业务单元、共享业务单元和全局业务单元。最开始所有的业务都是在强中心的单元，一点一点的按照核心业务，先把买家相关的下单交易链路，还有流水类的相关的链路都拆到核心单元，再把依赖的共享的商品的读都拆过来，按整个商品的写，库存扣减还是放在中心单元，这是整个的单元的示意图，异地多活分为两个视角，一个是业务视角，一个是技术视角。先看业务视角，业务视角是中心单元相当于主要做写，也做一部分核心没要求强一致，数据的读。同时会存全量的买家数据。全量买家数据是用来做容灾。
当某一个单元挂掉后,全量的买家的中心单元会向其他地方同步。可以在上层切流切到另一个单元。另一个就是全量卖家的数据，这个卖家数据是全局的数据，是面向所有的买家，所有商品交易的，所以整个的所有的核心的写和业务逻辑都要在放到中心单元，它的读是可以在各个单元来完成的，所以中心单元写。通过实时同步的工具。现在商业化的产品叫DTS，去向各个业务单元同步数据，业务单元去读，这里面同步数据包括缓存的数据同步和数据库的数据同步。从技术视角看异地多活，首先从接入层，再到微服务层，再到数据层，相当于做整个的流量的入口侧的流量路由和纠错，下面有一个图，从上到下看DNS层面，核心在网关入口侧的每一个单元都有一个核心的接入层的网关，接入层网关做纠错，因为DNS路由是相对随机的，防止本应该不在这个单元完成写入或者相当于闭环动作的进到单元，和相应的单元路由管理做联动。
单元路由管理是一个横向的系统，当这个请求进来后会在cookie里面打单元标，叫做Root ID，会判断单元标是否是属于本单元的，如果不属于本单元，网关会把这个请求转发到他应该属于的单元，路由走，走到RBC微服务应用调用层，应用调用层在阿里，客户有两种做法，一种是用统一的大的注册中心做微服务调用，通过逻辑隔离的方式，这个节点打标和标签路由根据Root ID决定业务属性请求应该走本单元还是应该走中心单元。
所以第一个是在整个注册中心层面发布的服务打上标，第二个在每个请求调用的时候做标签路由，发布的服务里面又会有三个标，local代表是读本地的单元，就是共享单元c栋，global是代表的全局，在全球这部分代表的是单元化，单元化就相当于是请求按照Root ID层的保证a调， b调， c调,d调，所有的微服务的调用能在本单元内闭环，但到数据库层面，按照UID的维度拆分做整个数据库的维度部署，数据库可能只负责25到49的客户群体，这个负责50到74，相互单元与单元之间的数据会形成互悖关系。
单元与单元之间通过DTS数据做数据同步，假设出现故障后，在这个地方统一切流后,从入口网观侧到整个业务应用侧的相应的中间，到整个state sharing，到数据库中间写入这部分，都会做单元的请求的流量路由方式调整，保证相当于这个单元挂了，首先把这个单元进去，然后请求会自动路由到另一个单元，这个单元会作为单元的备。相当于承接单元的所有的数据和业务,单元作为master，它的整个slave备不只是一个单元，很可能是这两个单元共同加一起作为整个的master设计，相当于各50%，这是整个的阿里的异地多活建设的业务的抽象和设计背景,最开始想解决容灾问题和容量问题，但是到后来发现带来一些业务的收获，它成为技术创新的试验田。今天阿里有任何的新的业务功能、新的技术实验，新的创新，要上线之前都会先找一个单元先实验，因为这个单元里面假设出问题，它只影响一小部分用户，当试验完没有问题，并且经历过双11验证以后,会把这个核心的功能在所有单元全推平。
七、云上应用容灾架构最佳实践
上面是阿里巴巴做的异地多活的思考。整个的技术设计方案，后面会重点讲一下云上的应用，容灾架构的最佳实践，首先讲应用同城多活，在很多客户落地时发现这个东西的实现复杂度和周期是很高的，它不单是技术问题，它需要业务团队配合，业务怎么去拆，业务是按照买家还是按照卖家,还有像T3出行，曹操出行汽车行业的企业是有地域维度的，出租车基本是在这个地域，会考虑按地域的维度去拆单元，同时做冗余。
先看应用同城多活如何实现，在同一个Region里面，两个可用区应用是对等部署的，下面的注册中心用的是一套MLC注册中心，一套MLC注册中心能够保证的点是三可用区部署，就是任何两个可用区都挂掉，核心业务不受任何影响，数据库就是主备，主备之间的双向同步出现问题以后可以切流，上面是原生API网关，原生API网关是双可用区，容灾部署，可以实现跨可用区多个业务集群间的全局负载均衡和秒级故障转移。这个能力很重要。
很多客户落同城多活采用上面一个DNS,下面每一个机房的方式，如果在云下，是机房，如果在阿里云上，就是每个可用区可能有一套自己搞的nginx，或者网关，因为nginx，网关，它是不支持多集群管理的，它切流时是依靠于DNS切流，DNS切流的问题是要手动切。第二个是它切流时DNS有缓存，切流的时效性会很慢，当切过去的时候慢，切回来的时候也慢。
通过原生网关能把两个可用区里面所有的微服务,假设微服务都是a，每个可用区微服务各有五个节点，把五个节点合到一起变成十个，从全局的维度来实现负载均衡。这个时候再针对于后面的微服务做探活，有探活后，默认是2秒，也可以调。支持TCP和HTP，它可以实现秒级的故障转移，这里就不会出现大多数情况做不到对等部署，对等做不到的情况下，是该切，还是不该切。能不能自动切。
这里面可以达到一个好的效果，当微服务一共10个，这里面是五个节点，挂了三个的时候，或者挂了四个的时候，不需要人肉参与，会自动的把90%的流量路由到这个可用区对应的微服节点。流量切过来还有问题。再往下看是网关层的切流问题解决，如果底层用的一个注册中心，微服务的服务路由在consumer端，它从这个中心拿到所有provider ip的列表，在consumer端做路由，路由默认的规则是RR的，所以它一定会随机调。一定会随机调就可能会出现跨可用区的调用。跨机房,跨可用区的调用里面有两点：
第一对延时敏感可能会接受不了。
第二是实现同城多活以后，不只解决容灾问题，还想实现一些比如灰度，或者一些业务的快速的实验，或者说可用区的集群，专业做一些升级，里面会有什么诉求.相当于同可用区闭环的诉求。所以引入微服务治理。微服务治理是通过java agent，零侵入的方式，可以快速的实现微服务调用。如果请求走到可用区a，可用区a也叫单元a，保证调b调c调d都一定能够在本单元内完成闭环。
有些客户想到，之前是南京的一个头部的做运货的客户。同城多活实现了同可用区优先。同可用区优先实现，但Fallback有没有考虑过。Fallback是什么机制是不是一定要强制保证同可用区优先实现，强制保证同可用区优先，假设每次请求走到微服务a，微服务一定要调用b吗？显然不是，跟前面逻辑一样，微服务里面有五个节点，假如这五个节点都挂了，还要让他继续调微服务b吗？或者这里面挂了四个怎么办？所以如果要实现同可用区优先，需要配一个阈值，就是当满足阈值的时候，才会同可用区优先。不满足阈值的时候会回退到交叉调用Fallback机制。在微服务治理的控制台可以很简单的快速配置阈值，阈值指的是单可用区存活节点的数，满足所有可用区加载节点数的百分之40%到50%，在整个的一个架构体系下，能够实现在网关层的自动切流，在整个微服务层面的自动切流，保证核心中心文件是高可用的，这是引入服务治理的一个效果。
引入服务治理整个控制面是都是在一个控制面统一管控，然后通过控制台可以快速配置，然后也支持ACK,K8S这种YAML方式去配置，然后整个研发和运维团队不需要引入额外的代码，不需要引入额外改动，只需要java agent的方式就可以实现了，关键技术就是网关会把所有的这个节点进行合并，然后每个节点之间会主动建立健康检测。端口维度，TCP维度，也支持LTP维度的，很多时候端口好并不一定代表业务是健康的。另一个是Nacos，简单来说就是能实现多可用区容灾，因为本身Nacos和数据中心，它的实现原理就是写是分片写，然后读每个节点都有全量数据相互同步，这样任何一个节点挂了,或者任何一个可用区的几个节点挂了。
其他可用区快速电源连接，都能拿数据，整个微服务与微服务之间的调用怎么样来解决秒级故障转移。注册中心本身跟应用的所有节点会有长链接，然后有主动的一个探活机制，当长链接断开，或者15秒内节点客户端没有上报，会主动的长链接断开，会1到3秒内剔除。如果客户端没有上报假死情况，也会把它标志为不健康。很多客户去聊实现多活，理想情况要求两个可用区都能承接百分之百的流量，这是理想情况，但现实情况，考虑成本的因素。
觉得成本太贵，所以没办法做到每个可用区都百分百的资源准备。一般都是70%左右的资源。当出现问题以后，秒级故障切流转移到另一个可用区，另一个机房的时候。能做到两件事，第一个是快速去弹，快速去扩容，第二个是在还没有弹，没有扩容出来之前，剩下的节点能不能承受住已经过来的流量。所以这里就通过流量防护的能力来解决，流量防护只是一个简单的一部分，在整个容错体系流量防护有漏斗模型，分为两个维度，一个是防止上游不打挂，一个是防止下游出现问题，不被下游拖挂。另一个是弹性，怎样去解决快速弹性的问题。对应核心的底层技术架构，现在整个云的核心专业产品底层在用Serverless，通过Serverless产品，对外售卖产品叫ICE应用引擎，它有多种弹性指标，支持定时和CPU内存。还有业务请求维度，RT维度混合弹性，比K8s， ACK的弹性更容易上手，更容易理解，并且更多贴合业务实际维度，满足需求业务维度弹性指标，另一个实际的问题是弹出来就可以了吗？java应用或者微服务应用刚启动的时候，会有CPU的编译，它有一些懒加载，刚启动就有大量的流量打过来，会出现一个问题，应用刚起来以后就雪崩，这是之前在蚂蚁做架构师的时候遇到的问题，在蚂蚁做架构师的时候负责支付宝钱包里的核心的缴费，还款，充值业务。当时有几十台机器出现问题，快速重启以后，没有做预热，大量流量打过来，把重启的机器，又不断打挂。
所以通过5等上线来解决应用启动的预热问题，它可以让整个应用启动以后流量是逐步成阶梯上升的，然后整个的启动的打流量时间，是可以跟微服务注册到注册中心的时间，和微服务在K8s暴露时间拉齐的，并且可以设置它的预热时间，这是相当于基于MSHA跟MSE可以实现一个异地多活的能力。首先MSHA在最上层，它类似于GTM，实现全局多Region之间的切流，然后再到各个应用层面。能够实现单元闭环，再到数据层面，实现进写，还有一系列的相应的服务同步。
八、秒级故障转移效果演示
快速演示秒级故障转移效果。在演示之前先介绍一下demo，demo是在杭州Region的两个可用区的两个ACK集群里面，每个ACK集群里部署两个应用。Consumer和provider。两个应用是微服务应用，都注册到MSE注册中心，并且这两个微服务应用在两个集群中是对等部署，然后通过云原生网关全局来控制流量，这里面在入口侧发起-hello多活的请求，各50%的流量到两个集群中。
然后开启微服务治理的同可用区优先。当请求到集群A的consumer，就是网关的第一调，通过微服务调用provider的时候，一定是调到本集群内的provider，同样当请求进到B，进的一定是provider。接下来开始演示实际效果，演示之前先启动一个PTS压测，来测DiNA场景下看秒级故障转移的情况，这是两个集群a和b，然后对应的两个应用，这两个应用都注册到注册中心中，在注册中心随便找应用点进去，可以看到meda date里面会打可用区的标，这个是I的可区，这个是j的可用区。
两个应用接网关，并且接治理，接治理后里面provide consumer，开启同可用区优先，同可用区优先域值配的是40%，网关配两个容器，两个来源对应，然后里面配同样的一个服务，网关会把两个容器的两个集群的服务合并，因为支持多集群管理服务，两个加起来十个，然后从全局维度来实现全局的负载均衡，这里面有健康检查配置，这里配的默认是2，使用默认就好，配相应的路由，接下来发起应用的请求来看效果。
这是网关的入口地址。在应用请求里面会发一个入口地址。这个是请求网关循环脚本，然后接下来启动脚本。整体就是跟刚才说的一样，集群a和集群b，差不多各50%的一个流量。无论集群a还是集群b，只要consumer打的是a，那provider一定也是a，这是通过复制，保证可用区优先。在可用区内闭环掉。接下来再看一个不闭环的场景，把对应的集群a的provider缩容到1，缩到1后，它不满足服务治理配的40%的阈值，它应该会自动fall back，调到集群a的consumer，会自动Fallback到集群b。
虽然consumer是class a，但调provide又调到了b，接下来把它弹回来，演示网关的全局负载均衡的一个效果。网关相当于把集群a的五个节点缩到1，看网关侧会不会把90%的流量都负载到另一个集群，看下面的请求，三个都是b，就相当于大部分请求都会走到b，只有很少走到a，走到a的这部分因为服务治理，扩容还没扩回来，所以它又会Fallback到b，叫provider，接下来演示灾难场景，灾难场景是强制模拟器放断电，这三个服务器对应的是容器里面的三个节点，三个节点，强制断电看一个反应效果。启动PTS，看当前的整个的总请求数是100多万，然后成功率接近百分之百的一个情况，看断电的成功，看错误请求数没有。
接下来要做一个效果，就是在这里面强制的停止，模拟断电，a机房断电就是a集群，等断电看网关的秒级故障转移效果，然后观察PTS反应，现在是130多万总请求数。大概它的错误占比有多少，失败率有多少。现在208个错误，相当于断电的一瞬间。成功率下来，差不多是一秒。对应的这一秒整个的耗时。P9差不多是五秒。一瞬间下来以后，成功率又拉回去。总共错误请求数是400多，同宽在整体的占比里面不到1%。可以看到相应的错误请求数，是一个秒级故障转移的效果。应用侧把流量自动的切到b，这是一个多活的秒级故障转移。通过解决方案还有产品来实现的，在同城多活场景下，如果单可用区域，或者单机房出现灾难，断网，火灾等一些问题实现的秒级故障转移效果，秒级自动切流。
