消息资讯|支付宝如何实现全分布式单元化技术架构？ RZone|架构|业务|

_原题为 支付宝如何实现全分布式单元化技术架构？

过去几年是云原生理念高速普及的黄金时期。微服务、容器、无服务器架构、服务网格等新技术的出现，在技术社区中激起了一浪又一浪的创新热潮。然而由于金融行业对性能和安全的严苛要求，云原生技术在企业实际场景中的实施落地，特别是在金融场景的实施落地，仍然面临诸多挑战。

本文整理自2020阿里云线上峰会蚂蚁集团资深技术专家尹博学的主题演讲，为大家分享蚂蚁关于金融级IT架构及分布式架构的思考和应用实践。关注“蚂蚁金服科技”公众号，蚂蚁SOFAStack白皮书即将发布，不要错过哦~~

以下为演讲整理全文：
大家好，我是蚂蚁集团的尹博学，今天和大家分享一下蚂蚁关于金融级IT架构及分布式架构的一些思考和应用案例，主要包含三个部分，分别是行业常见的分布式架构介绍、蚂蚁单元化架构的介绍以及单元化架构的应用案例。
行业常见分布式架构行业常见的分布式架构主要包含，单活架构、双活架构和冷备架构。从容灾能力角度来看，双活架构和冷备架构均能做到应用级跨机房容灾，但是数据库因为使用了异步复制的技术，无法做到机房级RPO=0的容灾。再看灰度发布的能力，冷备架构和双活架构都只能做到机房级灰度发布，无法做到更细粒度的灰度发布。

文章图片

蚂蚁单元化架构介绍在介绍完行业常见的分布式架构后，我们来看一下蚂蚁的分布式架构发展历程，和单元化架构的详细介绍。
这是蚂蚁分布式架构发展历程。蚂蚁也经历了单活、同城双活、两地三中心，三个阶段。其中两地三中心是同城双活加一个冷备。随着蚂蚁业务和业务量复杂度的越来越高，业务对于基础架构的要求也越来越高，即扩展能力、容灾能力、灰度能力要求越来越高。最终蚂蚁发展到了单元化架构，将主要业务拆分单元即分片，装入不同的逻辑单元内，每个分片的数据库实现三地五中心部署即三地五中心的单元化架构。
首先我们来看一下蚂蚁单元化架构的整体架构设计，整体架构包含RZone、GZone和CZone 。其中GZone部署的是无法拆分的数据和业务， GZone的数据和业务被RZone依赖， GZone全局只部署一份，而RZone部署的是可拆分的业务和对应的数据。每个RZone内的数据分片如图所示有五副本，实现三地五中心部署，每个分片内只有一个可写入的主副本，其余副本按照Paxos协议做数据强一致。每个RZone内实现业务单元封闭，独立完成自己的所有业务。而CZone的出现是因为GZone全局只有一份，不同城市的RZone可能依赖GZone服务和数据的时候需要远距离调用，延迟比较大，所以在每个城市部署一个CZone作为GZone的只读副本，为本城市的RZone提供服务。

文章图片

介绍完单元化架构的整体设计之后，我们从容灾、灰度发布、弹性三个方面详细看一下该架构的能力。
首先看容灾能力，容灾能力分为同城容灾和异地容灾，以图中所示为例， RZone1出现故障先看同城容灾能力，我们目标将RZone1切换至同城容灾RZone2 。先做数据库分片切换， RZone1对应的分片为分片1 ，把分片1在RZone2的副本提升为主副本，数据库副本提升完毕后将RZone1的流量切换至RZone2 ，实现同城容灾RPO=0、RTO<1min 。
再看异地容灾，同样以RZone1故障为例。目标切换至RZone3 ，先做数据库切换，分片1在RZone3的副本切换成主副本，完成后将RZone1的流量切换至RZone3 ，实现异地容灾，该过程RPO=0、RTO<1min 。

文章图片

接下来我们看弹性。弹性的背景是业务在大促、节假日等流量出现大幅上涨的过程，我们可以短期租借新的城市和新的IDC 。如图所示，我们租借城市X的IDCX作为RZoneX ，将RZone5的部分流量弹出至RZoneX ，对应流量的数据也弹出至RZoneX内。在节假日大促结束之后，将RZoneX内的流量和数据弹回至RZone5 ，然后回收RzoneX ，这样大幅节约了机房成本。

文章图片

介绍完弹性之后，我们来看灰度能力。如图所示，我们将四个RZone（RZone1、RZone2、RZone3、RZone4）的业务和应用分为A、B组，日常A组和B组各承担50%的应用流量。在应用新版本发布时，我们将A组的流量全部切换至B组，此时在A组上部署新版本，部署完毕后将B组的流量按粒度切换至A组上，切换粒度等于数据分片的粒度。在切换的过程中可以做A组和B组的服务对比，如果发现A组的服务异常，可以快速将流量切换回B组。在A组服务一段时间后无异常发生，最终可以将B组的流量全部切换至A组，把B组的版本更新为新的版本，在整个切换的过程中实现了可灰度、可回滚、可监控。