深度观察2024中国系统架构师大会（SACC）

今年的中国系统架构师大会（SACC）在我所在的城市广州举办，很荣幸受邀参加。这次能接触到国内最优秀的架构师，学习他们的架构思想和行业经验。对我而言非常有意义。

大会分为上下午共4场，我参加了上午的多云多活架构设计专场和下午的AIGC专场。

本篇文章就多云多活架构设计专场，我选取几位老师的观点进行分享。（我并不是架构师，只是对架构感兴趣，如有错误，还请指正）

张晓辉 Flomesh 高级云原生架构师

张老师分享了混合多云架构的技术方案，这里可以体现一个企业在技术层面发展到什么样的程度，根据这张图可以看看企业架构的复杂程度。可能大部分企业还在容器化，分布式架构和单一集群的复杂程度。

在资源抽象层面，利用统一的K8s Api，可以实现不同云厂商的资源抽象，实现资源的复用。K8s多集群可以作为防腐层，屏蔽基础设施层差异，避免厂商锁定

李中原 （平安银行股份有限公司 国产数据库技术负责人 ）

银行系统的技术架构需要满足高吞吐、低延迟要求，业务可靠性的要求，以及数据安全性的要求，同时，基于监管和法规的要求，技术架构需要自主可控。

李老师分享了银行架构的“去IOE化”的变迁。

对于可靠性要求，从传统的不能容许服务中断，逐渐过渡到允许服务中断但必须迅速恢复。

黄奕青 （腾讯云 技术专家）

黄老师对两位讲师做了补充，着重对异地多活架构中的问题，以及解决方案和设计要点等“三阶六要点”进行了分享。

技术架构的三个阶段：

第一阶段是对业务需求的解读：一个是传统的需求分析，一个是企业聘请领域专家对需求建模
第二阶段是确立架构，目前较为合理的架构是标准的微服务架构，已经被广泛应用（两地三中心架构）。
第三阶段是在微服务架构之上构建单元化，该阶段需要解决如下异地多活架构中的挑战。

异地多活架构的挑战：

因为网络基础设施的物理局限性，需要考虑异地资源使用时的延迟问题。
数据访问效率问题：跨地域的数据访问速度慢会导致核心交易延迟，需要考虑数据切分和流量闭环治理。
分布式事务成本问题：跨地域的分布式事务会带来高成本和复杂性。
中间件的单元化考虑：在异地架构中，需要考虑中间件的单元化和调度。

六大设计要点：

数据切分：设计大型分布式系统时首先要考虑数据如何切分。 数据按什么维度切分最合适，(如按客户号，还是哈希，按range范围？)
流量闭环与单元化架构：黄老师强调了流量闭环的重要性，特别是在单元化架构中。这意味着流量需要在特定的单元内部循环，而不是跨单元流动，以减少无效的横向流量。为了实现这一目标，网关需要具有状态感知能力，能够识别客户信息并将流量路由到正确的单元。此外，单元和上层计算资源之间的逻辑绑定也是关键。
中间件单元化：在单元化架构中，中间件（如MQ、Redis等）的链路也需要考虑单元化。特别是在跨单元的场景下，如客户之间的转账，会涉及到分布式事务的问题。这种分布式事务的调度和管理在异地多活架构下会被放大，成为实现的难点。
数据切分与聚合查询：数据被切分到多个库后，聚合查询变得困难。黄老师提到了从前在一个库下可以轻松进行多表的聚合查询，但现在需要访问多个库进行查询。这需要对现有的查询策略和技术进行重新的设计和优化。
业务连续性保障：单元之间的互备和业务连续性保障是必要的。
分布式运维：针对大型核心系统的分布式运维需要特别关注。

戴骏贤 （网易游戏资深数据库系统工程师 ）

网易游戏对于RPO的要求相对苛刻（数据要求无损）。但更多是以成本最小化为考量实现双活高可用架构。因此目前仅采用同城双副本。

李运华 互联网大厂 资深技术专家

企业是否需要上云取决于成本和技术实力两个主要因素。

成本考量：

企业规模：一般来说，如果企业的服务器规模在一千台以下，上云通常是成本效益较高的选择。对于规模在一千到五千台之间的企业，上云可能并不一定省成本，而取决于其在云平台上的使用程度。然而，如果服务器规模超过五千台，可能会发现下云（即从云平台迁移到自建环境）会更经济合算，尤其是对于大型企业。这是因为大型企业可能会拥有足够的资源和资金来自建云或自建机房，并且会节省大量成本。
全面成本考量：除了物理服务器成本之外，还需要考虑人员成本、维护成本等方面的费用。这些费用在决定是否上云时也至关重要。

技术实力：

企业规模与技术实力：大型企业通常拥有更多的人力资源和技术实力，因此更有能力独立管理和运维自己的服务器环境。相比之下，中小型企业可能缺乏专业技能和资源，难以应对复杂的技术挑战，因此更倾向于使用云服务提供商提供的解决方案。
云产品的功能和强大程度：云服务提供商提供了丰富的云产品和服务，包括分布式一致性数据库等高级功能。然而，自行实现这些功能需要大量的时间、资源和技术实力。对于中小型企业而言，使用云平台提供的功能可能更为经济实惠和可行。（ocean base一个几百上千人的团队，从2013年开始，搞了12年）

同城双活和异地多活有哪些方案？

同城双活方案：

由于同城机房之间的网络延迟可以做到非常低，通常可以在几毫秒以内，因此同城双核在逻辑上可以看作是一个统一的机房。可以直接按照集群的方式运作，成本和复杂度会低。

近邻的异地多活：
这种方案通常是指在相邻的两个城市之间进行异地多活部署。例如，广州与深圳、杭州与上海等相邻城市之间的部署。由于网络延迟相对较低，大约在十毫秒左右，因此可以接受。近邻的异地多活方案通常可以通过分布式一致性算法来实现投票和选举，确保系统的可用性。

远端的异地多活：
在距离较远的城市之间进行异地多活部署，如广州与北京之间的部署。网络延迟可能较高（30ms以上），本质上没有办法实现这种集群的运作。

马洪喜（深圳行云创新科技有限公司 CEO）

马老师分享了三个不同企业的案例：

区域性银行的高可用解决方案：

该银行实施了同城双活的云原生高可用解决方案，这是一个强需求，因为银行业务对高可用性有极高的要求。
他们的方案是基于一个调度器实现的，使得业务在发生故障时可以切换到单机群模式。

某超大型电器公司的混合云方案：

该公司实施了混合云，将国内业务部署在私有云上，将海外业务部署在AWS上。
这是出于业务需求的考虑，例如海外业务需要在AWS上就近访问。

某锂电制造企业的工业场景需求：

该企业有着复杂的IT/OT融合场景，需要在制造业中实现微服务和AI的应用。
他们的需求包括在本地数据中心或厂区内的小型数据中心处理数据，而不是将数据从生产线传送回总部或云平台。
制造业趋向于建立一个多级算力体系，包括本地数据中心、云平台和边缘计算，而不仅仅是简单的双活或多活部署。

另外在与公有云对接的过程中，确实会遇到一些挑战和坑：比如公有云平台通常会限制用户在容器服务中运行某些特定类型的应用程序或容器镜像。以及路由设置、网络安全限制等。此外，有些云服务商在网络层面可能会实施一些特殊的技术手段，如MAC地址劫持等，导致一些不必要的麻烦和延迟。

顺炽国 （某制造集团 云平台基础服务负责人 ）

常见的一些互联网应用很多只关注C端的，也就是只需要考虑北线（用户入口）入口流量一个分流跟分发或者流量管控。但是在物联网行业还需要考虑南线（设备入网）的流量管理，这两部分只有配网绑定的阶段需要打通南北两线的数据。

成本压力：集团的服务器规模正好在一千到五千个主机之间，导致了巨大的成本和运维压力。解决这个问题正在考虑下云。

业务复杂性：智能家电行业有独特的业务特点，需要同时关注北线（用户入口）和南线（设备入网）的流量管理，确保设备与用户之间的关联和通信畅通。

多云节点部署：需要根据业务需求，在各个区域部署多云节点，以提供更快的服务响应时间，降低用户体验的糟糕程度。

单元化思路：采用单元化的思路，尽量减少数据同步带来的问题，通过北线和南线的网关，将业务闭环在单元内，以降低对专线的重度依赖，提高业务稳定性。

张观石（ 泰健科技 CTO）

张老师讲了个故事： 初始阶段，自建CDN成本高，后接入云CDN，但谈判降价困难。后期通过多云CDN架构，平衡质量和成本，使各厂商主动降价争取份额。

他从一个比较新颖的角度谈论了多云架构的优势：根据提供商的服务质量和价格，分配负载份额

另外他谈到了多云架构的优势：

多云并非只为实现多活，而是为了在架构中灵活利用不同云服务的特点和价格优势（使用特定GPU型号的业务只能在相应云上部署，提高架构灵活性）
利用不同云的产品优势，如低价存储，以降低整体成本。

通过多云策略，企业可以增加与云服务商的谈判地位，从而更好地争取资源、降低成本。同时，多云策略也提供了更灵活的资源供给方式，可以根据业务需求在不同云之间调度资源，确保服务的稳定性和容灾能力。

另外由于多云架构的复杂性，监控告警、排障流程等运维问题复杂度增加，需要考虑跨云沟通和统一运维平台的建设。这就引入了另一个问题：如何建立多云融合统一管理（CMDB）

CMDB的核心功能是收集和存储关于云环境中各种资源的详细信息，包括虚拟机、存储、网络设备等。管理员可以实现统一的交互界面，方便地查询、分析和修改资源的配置状态

根据企业对于多云管理的管理要求，可以采用以下几种方式：

十几二十几台服务器，没有必要上CMDB系统，通过管理员登录各云的控制台进行管理

资源管理型：创建虚拟机，配置网络等，基于开源的管理工具（比如rental？）二次开发较为容易，各家云厂商的API接口并不复杂。

应用管理型，属于高级别应用，可以与应用交付系统结合，从应用的视角出发，自动选择合适的云资源来部署和交付应用，基本要采购商业产品。定制化开发。或寻求混合云厂商，有现有的解决方案可选。

–完结–