本文整理自蚂蚁集团金融云产品技术部SOFAStack产品专家俞仁杰在2020 GIDC全球互联网数据大会的分享。详细讲解了云原生架构下的多活高可用平台和产品建设相关经验和观点。
过去几年是云原生理念高速普及的黄金时期。微服务、容器、无服务器架构、服务网格等新技术的出现，在技术社区中激起了一浪又一浪的创新热潮，很多开发者都对由此而兴起的一众技术十分追捧。
与此同时，云原生技术在企业实际场景中的实施落地，特别是在金融场景的实施落地，仍然面临诸多挑战。由于金融行业对性能和安全的严苛要求，目前不少的行业参与者对云原生技术仍然保持观望态度。
本次分享主要是关于云原生架构下的多活高可用平台建设的三部分经验和观点：
联邦集群和容灾建设：多集群场景下的应用生命周期管理。
统一流量治理和服务网格：异构多中心场景下的统一视角流量管控。
单元化架构与混合云演进：参考架构与演进路线。
SOFAStack主张PaaS层产品体系建设，不仅需要有统一管控的联邦发布和多集群管理能力，还需要解决东西南北向的接入层流量统一治理能力，通过体系化的技术风险管理机制和平台工具，使全局架构迈向异地多活单元化混合云并提供极致弹性和容灾能力。
联邦集群和容灾建设
跨机房应用发布管理
在PaaS层面，我们在K8S上建设一层联邦能力，我们希望每一个机房都有独立的K8S群，因为一个K8S集群直接进行跨机房、跨地域部署是不可行的，无法满足容灾需求。于是我们的思路是通过建设多云联邦的管控能力，在PaaS层产品层针对Kubernetes做一些扩展，定义逻辑单元，定义联邦层资源等等，最终达成多机房多地域多集群的单元化架构，最终目的是在这些复杂的场景中为业务提供统一的发布管控和容灾应急能力。
其纳管的每个集群，均为完整、标准的Kubernetes集群及相关扩展。在集群之上，通过联邦管控平面，协调各集群资源、应用和配置，以提供应用变更管控、分组发布、镜像管理、流量调拨、元数据管理、集群资源管理等功能。用户可以通过控制台、命令行或SDK以标准方式对单集群及联邦管控层进行交互。
通过一套应用PaaS平台，提供统一的应用、资源管理，发布运维视图，实现多集群管理、跨集群应用运维发布、资源管理、流量管理。具体来说可细分为以下架构演进场景：
同城双活（active-active）
在同一个地域Region，建立两个或更多可用区下的多个Kubernetes集群。
两地三中心
在同城双活的基础上，增加一个异地机房，做数据和应用备份。根据网络延时和带宽情况，可选择异地热备、温备和冷备三种方案。
在异地存在延迟的情况下、业务可接受的范围内，可以选择异地热备。正常情况下访问同城双活，在容灾期间切至异地灾备机房，提供业务访问。
异地多活（Multi-region active-active）
数据层做分片（Sharding）,不同的AZ可以划分为更多的逻辑单元（Logic Data Center）,处理不同的数据分片。尽量保证数据访问的链路从接入层到应用层再到数据层不会出现跨可用区的调用。这种架构下，可以做到任意数量地域的多活。
异构基础设施下的混合云
通过Kubernetes屏蔽掉底层IaaS的差异性，可充分利用云上的资源，将业务同时在专有云和公共云上进行部署，并进行统一运维管控。在该场景下，可以帮助金融客户达到以下目的：
减少开发、测试资源的投入：专有云部署生产应用，公共云按需部署开发测试应用。
线下快速容灾需求：应国家监管需求，需要在线下部署一套环境，以应对云上的突发情况。
弹性扩容：结合异地多活架构，使业务能够按需进行机房级的无限水平扩展。
作为分布式架构的平台管控层，还承担与各相关系统的对接能力，提供权限、资源、应用元数据、工作空间、部署单元等领域模型的管理能力；与监控分析平台对接，向用户提供完整集群资源和业务应用的可观测性；与高可用管理平台集成，提供完整应用层面的高可用风险保障管理能力。
高可用容灾解决方案
在蚂蚁SOFAStack的产品体系里，高可用管理平台是SOFAStack重要组成部分，面向用户应用的高可用管理平台，提供覆盖技术风险事件前、中、后的业务连续性全链路管理能力。在“应用上云”和“分布式架构”这两条路线中，技术升级面临各种高可用挑战。包括：应用质量挑战、问题定位能力挑战、故障应急能力挑战、监控发现能力挑战、性能容量挑战、以及单点可用性挑战。
风险事件发生前，通过流程化的日常业务巡检、故障演练、业务监控，建立风险发现的手段和体系，主动发现风险事件；当风险事件发生时，通过应急管理快速拉起应急流程，完成故障快速诊断、通过应急预案、容灾切换实现故障快速恢复；应急结束后，通过风险管理回溯、复盘等机制，加固风险事件发现和诊断能力，不断提供业务高可用水平；
故障控制：技术风险的防范从“研发”和“质量”的阶段就开始了。对于重要产品的开发，其架构的升级和技术的选型，需要依靠技术风险同学的介入来完成，通过多人评审把关，从源头杜绝潜在的风险。在质量层面，除了维护产品基础的质量标准，还有实现自动化测试率的要求。在应用发布时，通过蓝绿、灰度或者多级灰度等方式，缩小产品业务变更的影响范围，从而降低其可能带来的业务风险。
故障发现定位：蚂蚁的SRE同学通过“分析控流”、“链路分析”、“辅助定位”和“全链路监控”来完成故障的发现和定位。在日常的巡检工作中，产品潜在的风险能够及时、精准的被发现，也能够在第一时间被排查。
故障应急：发布回滚，也就是使得一些成熟的故障风险解决方案进行快速的处置和闭环，从而形成“容灾切换”、“应急预案”、“单机治愈”这样的自动化手段，能够大大提高故障恢复和处置的效率。
资金安全：在高可用管理体系中有“资金安全监控”和“资金安全应急”体系，能够最大限度避免资金安全层面存在的风险。
容量成本：通过“全链路测压”、“应用资源管理”、“弹性伸缩”，高可用管理体系可用最优方案满足业务需求、降低单比交易的成本。
能力保鲜：通过日常的“容灾演练”、“应用故障演练”、“资金安全演练”和“常态化测压”，不断测试各个系统中的高可用管理的能力，从而保证关键时刻以上五大能力的生效。
统一流量治理和服务网格
南北向七层流量接入
在 Kubernetes 体系中，抽象出了 Ingress 模型以应对七层流量管控需求，包括服务发现、服务暴露、灰度配置等，在社区和行业领域内均有多种主流技术实现。但在多地域多集群的南北向七层流量管控上，开源和行业领域尚未出现一个统一标准，想要完成一个多地域多集群的七层流量管控，需要从元数据、集群管控、多集群运维、统一视角的流量规则等多个层面建设，才能够应对全局架构下的流量治理和路由需求。
因此，配合联邦集群场景下的应用发布管控、容灾应急能力，SOFAStack 提供了可以跨地域跨 K8S 集群的统一七层流量接入能力，并提供单元化和非单元化两种模式，其中非单元化模式可以轻松的支持同城双活多活等“平行”容灾架构，单元化模式则可以基于业务语义（例如 UserID）进行定向单元推送和转发，保障业务的无限横向扩展，支持三地五中心等异地多活架构，同时还支持集群、单元维度的本地域流量收敛和权重配置，兼顾 SLA 和 RTO。
该模块基于统一接入的三重维度，主要围绕三个核心模型进行建设，分别为统一接入集群、统一接入实例和统一接入规则；统一接入集群主要负责 7 层负载均衡转发器 spanner（自研）在多地域多集群的部署、运维等整体生命周期事项，联邦视角；统一接入实例则从端口+协议两个维度进行统一接入集群的拓展，精准定义了流量入口；统一接入规则则对标 k8s ingress 模型，同时支持多种扩展语义，提供了全局视角的流量转发和治理能力。
在转发层面，我们利用了蚂蚁自研的 spanner 作为 7 层转发网关，spanner 已经经历了蚂蚁内部的大规模高并发场景，在蚂蚁的异地多活架构体系中扮演着重要角色，所有业务流量都先经过Spanner后再转发至各个业务系统，提供全局流量负载均衡功能同时，提供了更多金融场景下的多活容灾的特性，例如私有协议接入，安全防护，流量镜像，流量复制，LDC转发，蓝绿发布，容灾流量切换，终端全网广播，应用去中心化接入等能力。
东西向微服务治理
解决了南北向的接入层流量治理需求，到应用层的东西向服务管控方面，SOFAStack的实现思路是通过 Service Mesh 服务网格来实现云原生架构体系下的统一控制面与数据面通讯。
在控制面上，我们引入了 Pilot 实现配置的下发（如服务路由规则），在服务发现上保留了独立的 SOFA 服务注册中心。在数据面上，我们使用了自研的 云原生网络代理 MOSN（https://github.com/mosn）承载 ，不仅支持 SOFA 应用，同时也支持 Dubbo 和 Spring Cloud 应用。在部署模式上，我们不仅支持容器/K8s，同时也支持虚拟机场景。
我们的服务网格产品名是 SOFAStack 双模微服务平台，这里的『双模微服务』是指传统微服务和 Service Mesh 双剑合璧，即『基于 SDK 的传统微服务』可以和『基于 Sidecar 的 Service Mesh 微服务』实现下列目标：
互联互通：两个体系中的应用可以相互访问。
平滑迁移：应用可以在两个体系中迁移，对于调用该应用的其他应用，做到透明无感知。
异构演进：在互联互通和平滑迁移实现之后，我们就可以根据实际情况进行灵活的应用改造和架构演进。
Service Mesh 在蚂蚁集团经过了2年的沉淀，我们探索出了一套现阶段切实可行的方案并最终通过了双十一的考验。在这个过程中，我们也愈发体验到了 Service Mesh 带来的好处，例如 MOSN 在大促中间完成了数十次的业务无感升级，见证了 Mesh 化之后基础设施的迭代速度。
我们判断，未来 Service Mesh 会成为云原生下微服务的标准解决方案，同时在微服务体系架构下的消息中间件、数据库、缓存等中间件接入层都将在Sidecar模式下沉，所以我们也会持续加大对 Service Mesh 的投入，包括接下来蚂蚁将和阿里集团一起深度参与到 Istio 社区中去，和社区一起把 Istio 打造成 Service Mesh 的事实标准。
单元化架构与混合云演进
面向终态的异地多活参考架构
首先解释一下什么是“单元化”。大家可能比较容易理解数据库层的“分库分表”（即Sharding），它通过分片的方式解决了集中存储的计算性能问题。“单元化”的核心思想是把数据的分片提前到了入口请求的分片，在机房的网络接入层将用户请求根据某个纬度（比如用户ID）进行Sharding，这就好比把每个机房就当做了一个巨大无比的有状态的数据库分片。例如，一个 UserID 尾号为 007 的用户通过手机端或网页域名发送服务请求，接入层就能够识别出应该将该请求路由到华东地区还是华南地区，当请求转发到某个地区的机房时，大部分请求处理工作可以在机房内部完成。偶尔会有一些业务可能会发生跨机房的服务调用，比如说数据在A机房的用户给数据在B机房的用户转账，这个时候就需要在机房上去做有状态的设计。
该架构解决方案下，可以避免跨机房、跨城市访问的延迟，真正实现异地多活部署，不但消除了传统“两地三中心”架构中的单独冷备中心，并提升了灾备高可用能力，无论在成本还是在伸缩性、高可用方面，都带来了巨大的优势：
保证数据安全和业务连续性
消除了传统架构下启用灾备时可能数据受损或丢失，因而无法保障金融级的数据完整性和一致性这一致命缺点。
多机房、多地域无损容灾
真正实现异地多活部署的单元化架构，支撑更稳定、更高效、更低成本的金融级服务，并极大提升了灾备能力到异地无损容灾级别。
提升机房资源利用率
消除了传统“两地三中心”架构中诸如存在平时不提供服务的单独冷备中心等不足，极大降低了运行成本。
在云原生的趋势浪潮下，全局架构迈向单元化架构的解决思路，在PaaS基础设施层面势必需要能够有一个全局的集群应用管理和流量治理平台，以及一整套能够感知单元化异地多活架构的中间件体系，并辅以一整套完整的技术风险保障体系和工具平台。
进而，通过单元化架构带来的机房级弹性和容灾能力，结合云原生架构、Kubernetes带来的异构基础设施屏蔽和资源托管能力，已经从技术层面上为混合云架构打好了坚实基础；从行业发展来看，未来各大金融机构一定会逐步接受从开发测试云、灾备云到多云多活的混合云架构落地场景。
展望：SOFAStack金融分布式架构
我们对SOFAStack的未来使命，定位为数字金融业务的跨云操作系统。这个操作系统会有三大关键能力，其中，混合云和可信原生是我们当前正在做的，我们希望这一套PaaS层的基础设施，能够基于标准、超越标准，其中关于跨云管控、稳定性和安全保障等能力能够做到原生拥有、开箱即用，最终使在其之上运行的金融业务，能够更好地承载数字化带来的机遇和挑战。
作为一套由蚂蚁完全自研的技术栈，SOFAStack吸收了关键金融交易系统的架构实践经验，包含构建金融级云原生架构所需的各个组件，既能保证金融交易的技术安全，同时帮助业务敏捷迭代，实现异地容灾、低成本快速扩容等，支持金融业务创新。
SOFAStack已经稳定应用在支付宝、花呗、借呗、保险、财富、支付宝国际等各个业务线，并全面开放给整个金融行业，如人保健康、南京银行、浙商证券、网商银行等数十家金融机构，在金融行业分布式中间件市场份额中占据领先地位。
- END -
想要加入中生代架构群的小伙伴，请添加群合伙人大白的微信
申请备注（姓名+公司+技术方向）才能通过哦！
阿里技术精彩文章推荐
往期推荐
阿里文娱技术专家战獒: 领域驱动设计详解之What, Why, How?
蚂蚁集团沈凋墨：Kubernetes-微内核的分布式操作系统
支付宝研究员兼OceanBase总架构师杨传辉：我在数据库梦之队的十年成长路
蚂蚁资深算法专家周俊：从原理到落地，支付宝如何打造保护隐私的共享智能？
蚂蚁科技 Service Mesh 落地实践与挑战 | GIAC 实录
蚂蚁集团涵畅：再启程，Service Mesh 前路虽长，尤可期许
阿里P8架构师：淘宝技术架构从1.0到4.0的架构变迁！12页PPT详解
阿里技术专家甘盘：浅谈双十一背后的支付宝LDC架构和其CAP分析
阿里高级技术专家至简: Service Mesh 在超大规模场景下的落地挑战
END
#架构师必备#
点分享点点赞点在看
1042
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
