关于jquery:云原生时代微服务的高可用架构设计

简介： 在 8 月 20 日“阿里巴巴技术品质精品课”上，来自蚂蚁的经国分享了对云原生时代微服务的高可用架构设计的全面解析，为大家介绍了利用架构演进门路、云原生时代的技术福利、高可用架构的设计准则以及经典案例的设计。

演讲嘉宾简介：
经国，蚂蚁金服资深技术专家，毕业于浙江大学。2014 年退出蚂蚁金服，先后负责过支付宝的单元化、弹性、去 ORACLE 等架构降级，负责多年支付宝双十一、双十二、新春红包大型流动等技术保障负责人，现为蚂蚁金服数字金融线负责技术危险架构师，负责高可用架构、技术危险平台、应急快反等技术底盘的建设。

** 以下内容依据演讲视频以及 PPT 整顿而成。
本次分享次要围绕以下五个方面：
• 利用架构演进门路
• 云原生时代的技术福利
• 高可用架构的设计准则
• 经典案例的设计
• 将来思考 **

微服务是当下十分热门的一种架构，阿里目前正在从 SOA 架构体系向微服务架构迁徙。同时整个软件应用研发开始进入云原生时代。在这些技术演进背景下探讨如何更好地实现稳固且高可用的架构计划，保障利用继续可用十分有必要。

一、利用架构演进门路

支付宝最开始是一个单体利用。随着业务一直倒退，支付宝拆分成了多个服务，衍生出了若干代架构。微服务是服务化后的进一步演进，服务的粒度比服务化更细，具备很好的流量管控机制，中间件和编程模型。云原生的倒退使 Serverless 也失去了倒退，FAAS 是 Serverless 的一种典型实现，可能以十分小的老本搭建小程序。另外，低代码和无代码当初也十分风行。

基础设施同样也失去了很好的倒退。最开始，单体架构是托管式的，通常将应用程序托管给电信运营商的某个机房，在物理机上运行单体利用。起初，基础设施开始向虚拟化演进，比方 VMware 等公司在物理机上构建虚拟化层和虚拟机，在虚拟机上运行操作系统。再起初，云化联合虚拟化技术和基础设施，在虚拟机上运行 Docker 过程，在 Docker 过程中运行应用程序。当初，依据云通将来的理念，包含蚂蚁在内的很多公司都在实现上云。蚂蚁的基础设施曾经齐全实现了云化，包含私有云和公有云。从架构角度来看，蚂蚁的基础设施就是在云底座上运行一层 K8S，在 Pod 里运行 APP，其下层对应着 FAAS、网格化、Service mesh、微服务等应用程序。

作为一个简单的业务利用，如何实现技术撑持对蚂蚁十分要害。蚂蚁目前正在尝试许多 FAAS 相干的技术选型，但从更大的范畴来看，微服务依然是支流的抉择。蚂蚁所应用的微服务架构自身也在一直演进，比方把和业务无关的性能下沉到 Sidecar，将数据库的一些中间件 mesh 化等。只管从利用研发的角度看，蚂蚁所应用的架构格调相比于原来产生了很大的变动，但从整体趋势来看，最次要的变动仍在于将和业务能力无关并且和基础设施相干的能力下沉。

二、云原生时代的技术红利

云原生曾经演化成了一个十分宏大的生态。这张图囊括了云原生里十分多的内容。从设计高可用且稳定性高的利用的角度来看，相干的内容包含数据库技术、云原生存储、Service mesh、可观测性、Serverless 等。

数据库技术

利用开发不仅须要关注业务逻辑，还须要关注数据，将畛域模型、业务流程、配置等数据以 Online 模式存储。近几年，数据库技术产生了很大的变动，HBase 等分布式数据库提供的强统一保障给云原生利用的设计和开发带来了许多益处。此前，利用设计须要思考读写拆散，须要连贯不同的数据源解决读写拆散的后果，并且这些性能都须要写入利用程序代码。而当初，这些性能能够间接利用数据库的程度扩大能力来实现，数据库技术的倒退极大地防止了咱们间接和数据层交互。

云原生存储

蚂蚁的大部分业务曾经实现云盘存储，也就是将日志存储到远方磁盘。此前，单体利用通常将数据存储于本机磁盘，并且不提供其它冗余备份；而云盘则默认提供数据冗余，这在基于日志不牢靠假如进行利用设计时带来了很多变动。

可观测性

应用程序存在着许多监控操作。随着 Sidecar 将很多能力下沉，包含拜访 RPC 和 DB，此前以中间件模式实现的监控操作，当初则以切面模式来实现，二者有很大的区别。

云原生时代的技术红利

云原生时代带来的最大变动在于基础设施和业务逻辑的真正解耦。此前，中间件逻辑存在于应用程序的过程中，而当初压测、限流等都能够在 Sidecar 中实现，从而解耦了基础设施和业务逻辑。然而，这种解耦是一直进行着的，即便在将来也很难做到业务齐全不须要关注基础设施。比方，业务流量应该多大，DB 节点应该设置多少个，业务流量和 DB 的设计是否符合要求。比方，同步的要害业务对应的流量链路和异步化工作可能运行在同一个节点中，那么如何实现二者流量隔离就是一个难题。再比方，如何联合基础设施和业务要求进行部署，保障内存和 CPU 正当调配。在基础设施对这些内容无感知的前提下，如何自动化地进行混布和限流。从利用研发的视角来看，此前须要写很多代码来实现业务逻辑和基础设施交互；而当初相应的代码量会缩小很多。

三、高可用架构设计的设计准则

三个架构设计准则：可观测、可灰度、可回滚

高可用设计次要有三个准则，包含可观测、可灰度、可回滚。大部分云研发场景并不需要关注可演变，但在一些非凡场景下可演变依然是一个问题。比方，蚂蚁的金融业务须要和一些机构进行信息替换，因为金融畛域的 RPC 交互经常应用标准化文件，在文件场景下如何保障可演变也是高可用设计须要关注的内容。典型的用于进步架构可用性的设计准则包含四种：解耦、冗余、异构和异步。

解耦

在数据库方面，如何解耦外围和非核心业务的 DB。在业务链路方面，因为微服务具备简单的业务场景和节点，这些业务场景和节点间如何混合，业务节点如何撑持业务链路，容量有余时哪些业务场景应优先通过，限流时应优先限流哪些业务等也是解耦须要关注的内容。总体而言，解耦准则要求将最外围的业务链路隔离进去，使其与其它业务间的耦合尽可能小。

冗余

应用程序可能有多个机房，如果多个机房间存在数据冗余，那么一个地位的谬误就可能由另一个地位的数据来补救，从而保证系统的继续可用。读写拆散也是一种冗余设计，缓存和 DB 间存在数据冗余，当缓存宕机时，能够从 DB 回源到缓存。

异构

如果多个 DB 间是同构的，那么可能存在一些状况使得中心化的内容同时挂掉；但如果 DB 是异构的，比方应用的数据库版本不同，那么这些数据库同时挂掉的状况则非常少。

异步

异步要求将业务流程的外围局部形象进去，使其不与非核心的内容耦合。从实践上看，外围局部越精炼，零碎出谬误的概率越小。比方，支付宝的领取业务背地有一百多个业务解决节点，在微服务时代，其背地可能有几百个甚至上千个业务节点，假如每个节点的可用率都是 5 个 9，把几百个甚至几千个节点的可用率乘起来就会使得整体的可用率十分小。但通过移除和外围业务无关的内容，从而减小节点数量后，零碎的可用率就会大幅增高。上图的左右两边从不同角度对微服务的高可用设计进行了剖析。右边是微服务设计应具备的能力，左边是设计高可用微服务架构时应遵循的准则。另外，有三块内容理论撑持着一个微服务零碎：代码、配置和数据。其中，代码和配置是相辅相成的，代码执行的间歇可能须要批改系统配置；业务数据也十分重要。对这三块内容进行剖析是微服务架构高可用设计的重要方面。比方，配置文件的可回滚和可灰度能力。与代码相比，配置文件的可灰度能力不够标准化，尤其是和业务或者经营相干的配置文件；数据也是如此，因为一些数据有多种起源，这些数据的可观测和可演练能力比代码差。从整体而言，代码的相干体系比配置文件和数据更齐备。

不适度设计

架构设计的另一个重要准则是不适度设计，高可用架构设计应基于业务需要进行。这是因为高可用设计通常极为简单。比方，将链路中的一些重要业务解耦进去独自部署，无论其业务流量多大，都为这些业务调配一百个节点，从而升高单节点宕机带来的影响。从实质上来看，这些差异化配置通过付出老本和效率来换取高可用，这就存在着衡量难题。从目前来看，很少有软件系统的高可用能力可能实现 5 个 9，大部分都还停留在实践上达到 5 个 9 的状态。

四、经典案例的设计

接下来，以具体的业务场景为例剖析典型业务的高可用设计。

手机扫码场景

手机扫码场景要求在手机断网时失常显示其二维码。在这个场景里，真正的业务链路从 POS 链路开始，有的 POS 链路须要通过商户的解决零碎，有的则间接进入支付宝本身的业务零碎。在支付宝端，该链路将从一个对立的网关接入，携带着订单相干信息，比方商户 ID 等。尔后，链路进入一个收单零碎，由该零碎解决这些相干信息。再往后，链路开始进入交易系统，通过调用交易系统的外围模块实现该业务领取。此外，为了实现扫码，POS 零碎还须要和支付宝签约以建设受权关系，并且同步商户信息。这个微服务零碎所涵盖的高可用需要包含：
其一，该零碎次要面向线下场景，商家在未获取现金时不会将商品交给用户。因而，不可用问题对商家的影响很大，比方用户不能失常领取。
其二，该零碎的一些节点还须要撑持整个支付宝的业务体系，比方会员信息节点，它须要反对成千盈百个与蚂蚁森林雷同体量的业务性能，对可用性的要求十分高。
这意味着，在这个微服务零碎中，不同业务对可用性的要求不同，因而须要不同的伎俩实现该零碎的可用性需要。

灰度设计

首先，签约业务是异步的，在设计时不应被纳入零碎的外围链路。另外，签约服务须要与网关和商户服务进行信息同步，仍可能导致网关和商户服务宕机，比方批改商户的鉴权信息可能使签约不胜利。因而，签约服务须要实现灰度设计。

异构设计

其次，如果将一个十分重要的业务从链路中隔离进去，那么为了解决隔离后的节点的宕机事件，就须要一个异构设计使得当其宕机时整个零碎还能持续运行，包含数据存储方面和计算能力方面的异构。值得一提的是，当初的分布式数据库可能实现 RPO 等于 0，使得当数据出问题时不产生数据失落，其基本原理就是存储多个数据正本，并且当数据呈现故障时，能够在多个正本间切换，数据恢复速度十分快。然而，这并不意味着高可用设计只需依赖数据库，而不须要额定的容灾能力。事实上，这与零碎所要求的高可用级别相干。比方，假如零碎所要求的高可用能力级别为 5 个 9，那么即便数据库仅产生一次宕机并且数据恢复失败，那么就无奈实现所要求的 5 个 9 的高可用能力。高可用设计的一个准则是，外围业务的设计不应信赖其所依赖的基础设施。这样，为了进步零碎高可用能力，就须要实现应用层容灾。应用层的容灾可能会 FO 到一个数据库中，数据库版本不同，数据存储类型不同，那么二者同时呈现故障的概率就会变得更低。因而，应用层的容灾十分重要。

防热点、读写拆散

在 service mesh 场景下，应用层不再须要关注防热点、读写拆散等。几年前，应用层还须要对缓存热点做非凡解决以建设高可用能力，比方在一个缓存节点挂掉时对其进行预热操作。而当初，大多数分布式架构自身就提供了缓存热点能力。此外，大多数分布式数据库自身就应用了读写拆散架构，只需稍加配置就能够将数据路由到只读节点。这些都是云原生时代带来的红利之一。

近端

近端在不同场合下可能有不同的名称。比方，如果将会员信息的全副申请都发给应用层，那么其所须要的集群数量将会十分宏大。因为会员信息的查问遵循了较为固定的范式，因而能够将会员信息的查问性能前置到收单服务，从而使收单服务不须要拜访会员信息，而能够间接拜访会员信息所依赖的服务。这实质上也是通过应用层设计来减小高可用的老本。

总的来说，对于一个给定的业务场景，高可用设计须要剖析它的业务特点，可用性的要求，从而设计对应高可用设计的节点。比方，如何设计以查问性能为主的节点，特地是当其所依赖的数据库不被信赖时。在微服务架构中进行高可用设计时，应该针对每个节点的特色进行有针对的设计。另外，即便在云原生场景下，也须要通过应用层设计实现防抖、业务隔离、配置灰度设计和应用层容灾。比方，应用 FASS 可能很容易地实现零碎性能，但当零碎的可用性要求、业务体量增大时，任何一个抖动都可能影响到整个软件系统的可用能力。高可用设计并不存在标准配置。实际上，高可用设计须要依据业务重要性、能力和效率的分层等进行分档次的设计，最外围业务须要通过一些高复杂度的设计来进步它们的可用性。

业务隔离

线下业务和淘宝业务实际上应用同一个版本进行利用开发和公布，它们的隔离仅仅体现在流量和部署层面。比方，它们所应用的交易服务在开发层面就是完全相同的，仅仅在部署层面将它们的流量拆散到不同的服务中。这样，在以业务维度做跨节点的流量绑定时，就须要将几个服务及其节点圈进去进行分流。
首先，须要辨认某流量是否与该业务相干；其次，须要将该流量接入到某个特定区域中；而后，该区域还须要将所有与实现该业务相干的节点都蕴含进来。这种设计须要肯定的先验常识，因而须要定义一些元信息，比方流量入口。在确定流量入口后所有和其相干的后续解决节点都应被打标或者以其它形式圈定起来。门面零碎后对应着外部零碎，包含一系列 Http 组。在定义好这些后，某个组件会在流量接入后辨认门面零碎，进而找到该门面零碎对应的圈定区域，也就是外部零碎，从而实现一个整体上的流量绑定过程。

值得一提的是，这并不是微服务体系下流量绑定的标准配置，而是阿里的利用开发人员和中间件人员提出的业务隔离设计。随着上云等措施，这种设计逐步内置到基础设施中，成为一个典型的业务隔离设计。

防抖设计

图中的业务场景对应着买家向卖家领取。因为理论领取时，领取操作后置一段时间并不会引发大问题，因而大部分零碎在理论运行时，买家向卖家领取的钱都不会即时到账，而须要通过一段时间的累积后再批量到账。实质上，这是一种信息流和业务流的解耦。从业务角度看，钱须要即时从买家流动到卖家，两头还可能有聚合领取等操作。而在理论运行时，零碎无需关注具体的领取细节，而只须要告诉买家领取胜利，告诉卖家钱已到账。在不同解决模式下，资金流和信息流的解决流程可能有很大的不同。

防抖设计架构形象

在具体设计时，一个逻辑领取处理单元实际上被拆分成信息处理单元和资金处理单元。两头的 T + x 示意，信息处理单元和资金处理单元间能够存在一个较大的时间差。在信息受理时，即便不须要进行理论的资金流解决，也须要明确买家和卖家信息，而这些信息来自会员零碎和商家零碎。那么，当会员零碎宕机时，为了使防抖设计机制可用，就须要异构的设计。理论资金流解决所依赖的数据须要异构出一份以供信息流解决，而不是间接用原来的数据。异构设计使得一份数据宕机不影响整个零碎性能的失常运行。除了数据须要进行异构解决外，一些计算规定也须要迁徙到信息流解决中，比方商家的店铺信息处理等。数据和计算规定的异构使咱们可能实现解耦，这种设计对应着一个标准化的范式。简直在所有的业务场景都能看到这种设计。

总的来说，将业务最顶端跟信息流相干的逻辑形象进去，并且将这部分逻辑所依赖的数据异构一部分进去，这就可能使所有的业务实现不依赖于理论的解决逻辑，从而保障底层的任意一个节点产生宕机时整个零碎的可用性。

防抖设计架构延展

实践上，这种架构设计是能够扩大的。信息流解决和业务流解决被解耦后就能够被部署在不同的节点中。比方，在国内领取时能够将信息流解决逻辑部署在支付方所在的区域中，这就使得领取操作不须要依赖原来的解决逻辑所部署的机房。须要留神的是，在将数据部署在其它机房时，通常须要一些额定的解决，比方信息安全等内容。

配置灰度设计

某节点的配置数据产生变更可能影响其它与之相干的节点，因而这就须要对这些节点做灰度设计，带来了一个链路级的配置灰度设计问题。

分布式事务中通常有一个发起者和多个参与者。发起者发动一个预提交，在所有参与者确认后，该工作才被执行。这对应着一个二阶段确认过程，即先发动、再确认、后执行。配置灰度设计和分布式事务处理十分相似。首先，签约节点发动一个灰度设计，尔后和签约节点相干的节点须要参加进来，一起实现灰度。假如灰度的内容是某仓库信息，此时所有参加节点都须要对本节点下的相干数据进行灰度。在理论进行灰度时，每个节点实现灰度的形式可能不同。比方，商家须要批改 DB 数据，而会员节点除了须要批改 DB 数据外，还须要批改对应节点中的缓存。须要留神的是，无论每个节点如何进行具体的灰度操作，各个节点间须要实现灰度的同进同退。

值得注意的是，这是一个最简单的配置灰度设计，实际上的灰度设计比这个场景要简略地多。

容灾设计

状态型数据和流水型数据

蚂蚁通常依照个性将数据分为状态型数据和流水型数据。所谓流水型数据，即每呈现一条数据都将其存入数据库中。比方，订单数据就是一种流水型数据，每呈现一条新订单都被存入数据库。流水型数据的大部分业务类型是将数据插入到数据库。另一种数据是状态型数据，通常能够被批改，并且具备生命周期特色，比方会员信息。

状态型数据的容灾设计
这两种数据在进行应用层容灾设计时须要不同的解决形式，状态型数据的容灾设计通常比拟艰难。比方，会员信息在呈现谬误时通常不能再写该数据，也不能让该用户从新注册一次支付宝。状态型数据的容灾设计须要以数据库不牢靠为前提。数据库通常存在主备库，这两个库通常应用异步复制的形式来保障两个库之间的同步。然而，这种同步通常具备时延特色。当主库宕机时，如果 FO 库的版本比拟旧，就不能间接将 FO 库作为主库，因为原来的主库上曾经有用户批改的内容。如果此时将 FO 库作为主库持续进行批改，那么最终失去的数据必然不是用户所预期的。一个解决形式是将继续往黑名单库里写差别。当主库宕机时，首先将 FO 库拉起来，此时，这些差别可能使得 FO 库中某一部分数据是禁写的。对用户信息这样的业务而言，每天只有很少的数据会产生更改，并且用户信息产生宕机的概率很低，因而这种解决带来的禁写对业务的影响十分小。通过这种形式强统一地写黑名单库，可能近似地实现无损的容灾设计。回切数据库时也是如此。因为 FO 库曾经有很多新的数据内容，因而在回切数据库时须要将这部分数据 merge 回主库中。

即便在云原生时代，一个业务场景的高可用架构设计也依然须要许多操作来独特实现。将来，这些与业务无关的设计可能被组件化地积淀下来，成为基础设施。

五、将来思考

依据业务场景实现个性化高可用设计

高可用设计通常是动态的，它可能被内嵌到架构设计中，被内嵌到基础设施或者中间件中。高可用设计应依据业务场景实现个性化设计。这要求咱们不仅须要关注零碎当下的业务特点，还须要预测其将来的业务特点，通过各种个性来刻画该业务对用户的可用性影响。这就须要联合各种原子伎俩以实现业务在以后阶段所须要的高可用能力。将来，可能存在十分智能的零碎，可能应用最低老本刻画业务的以后特色，而后自动化地组合一些原子高可用能力最大化零碎高可用能力。

5 个 9 的高可用设计

将来还可能实现 5 个 9 的高可用。首先，假如存在一个和蚂蚁十分相似但又异构的环境，它们之间齐全是去中心化的；其次，这两个环境下的数据规定同步应该是可舍弃的，可能实现 FO 以及全自动的切换；另外，还须要实现监控，监控也应该是异构的，须要有一个内部零碎来观测本零碎的行为。

原文链接
本文为阿里云原创内容，未经容许不得转载。