技术专家说 | 金融分布式多活架构在落地之时，都有哪些值得关注的点？

本文作者：李忠良

市场的变幻，政策的完善，技术的革新……种种因素让我们面对太多的挑战，这仍需我们不断探索、克服。

今年，网易数帆将持续推出新栏目「金融专家说」「技术专家说」「产品专家说」等，聚集数帆及合作伙伴的数字化转型专家天团，聚焦大数据、云原生、人工智能等科创领域，带来深度技术解读及其在各行业落地应用等一系列知识分享，为企业数字化转型成功提供有价值的参考。

今天是第7期，由网易数帆云原生技术专家翁扬慧对话InfoQ编辑，为大家分享了金融分布式多活架构在落地时，都有哪些值得关注的点，为行业数字化转型下的金融技术架构演进提供参考。

01 挑战篇

InfoQ：翁老师，您和大家打个招呼，能够介绍下您所在的团队以及您的工作内容？

翁扬慧：大家好，我是来自网易数帆轻舟云原生技术团队的翁扬慧，目前主要从事于云原生技术的学习研究，以及相关技术的落地工作。

我有十多年的软件开发经验，对于微服务和云原生等领域也持续在关注，比如早些年的微服务架构比较火，对 Spring Cloud、Dubbo 还有 gRPC 等一些微服务架构设计可能用到的技术选型有过比较深入的学习和实践。

这几年除了持续在技术领域的学习和探索之外，更多是把精力花在了我们云原生产品包括后续会介绍到的分布式平台等的持续打磨，以及用户侧的技术落地工作，比如分布式平台建设、服务网格、应用多活等项目的设计和交付。我们最担心出现闭门造车的情况，虽然我们很多产品都是基于网易业务的一些支撑经验总结和沉淀出来，但是问题就在于不同的行业，不同的领域，不同的用户的组织架构，对于一个产品的设计要求的差异也是非常大的。尤其这几年一直投身并参与金融行业的架构落地，发现金融行业相比其它行业有着更高的设计要求，同时在整个落地过程中也存在着很大的困难，这也是我们团队希望通过我们的产品帮助用户解决的问题。

InfoQ：您参与过一些金融级分布式技术平台建设项目，落地过程中也遇到了不少问题，能否简单介绍下，都遇到了什么样的问题？以及你们是怎么解决的？

翁扬慧：这几年在金融行业的一些分布式技术平台建设项目过程中，我觉得遇到的问题以及难度要远远超过我们真正参与落地项目之前所预想的。在一个产品的设计开发过程中，大部分技术工程师，技术架构师或者产品经理，可能都会有这种体验：前期“自我感觉非常良好”，觉得我当前设计的产品形态一定是用户迫切需要的，一定是业界最领先的，能够帮助用户去解决痛点，而实际的结果往往会让我们大失所望，这是第一个比较大的问题。

这是面向产品设计驱动和面向解决问题驱动的两种方式本质的区别，并不是说我们的产品功能层面设计得天花乱坠，更多的是想说明产品在实际落地过程中，应该关注和聚焦在用户的实际使用场景和解决的问题，而不是一味地基于技术能够实现什么，去堆砌功能点，这只会让产品变得越来越臃肿，用户在使用上也会容易陷入一种迷茫状态：我究竟应该用哪个功能，怎么用这个功能？相反，业务团队自己也有一些技术平台或者工具，虽然界面比较简陋，功能比较简单，但解决的是一个特定场景的问题，似乎从需求的角度方面匹配度更高一些，所以这是我们在落地过程中遇到的一个关于产品匹配度的问题。这是做平台型产品经常容易陷入的一个误区，拿着锤子找钉子，从技术实现出发去做设计，往往会导致很多功能并不是用户需要的。

举个金融场景的例子，我们在做金融级的服务治理之前，有两个治理功能，叫做熔断和限流，大家都知道当出现突发状况的时候，一般的设计思路是要么触发限流规则，返回 429 状态码之类的，要么触发熔断规则来保护服务可用性。这个设计本身没什么问题，但是在金融系统里，就没有这么简单了，即使是已经触发了治理规则，但实际上已经返回了错误，或者即将会发生大量的错误返回，会导致整个连路上的错误率有明显的上升，这种情况是不太能接受的。所以在熔断和限流的基础上，还要结合一些指标监控，负载均衡算法等，尽可能多地把流量转移到一些处理能力更强的节点上，俗称“能力越大，责任也越大”就是这个意思，因为银行里一般对于某个业务团队的整体的请求响应的成功率是有要求的，所以有时候在设计的时候，就需要进一步去思考，从本质出发去解决问题。而且，服务治理这个点，在银行的很多业务里也是基于类似于交易码或者服务码的概念的，和传统企业基于服务粒度或者接口粒度也是有所不太一样，这就是典型的产品匹配度的问题，金融行业有着比较特定的业务场景，是需要结合对于场景的深入理解才能做成一个更好用的产品，这也是我们这些年来不断经验积累和沉淀到产品的一个方面。

第二个比较大的问题，是产品的落地兼容性。金融行业相较于传统企业有着更高的监管要求，因为交付上线的哪怕一个小的功能都有可能会真实影响到我们的日常金融系统，业务一不小心某个 bug 可能会导致转账失败了，可能突然间又爆出一个安全漏洞，会让整个金融系统陷入了风险之中。所以金融行业在整个软件交付过程中，要做很多相关的安全扫描，包括不限于开源漏洞扫描、内存泄漏扫描、代码静态检查等等，做过这块的同学应该不太陌生，也深知这里面的痛苦，大家印象最深刻的我相信莫过于去年的 log4j2 的漏洞升级，当时被爆出来有漏洞之后，我记得那个时候刚好是周五，我们可以说是周末连夜紧急修复，最终把这个漏洞给堵上了。

其实一些安全修复最大的难处不在于紧急修复，而是当一个在用的框架被扫描出来有风险要升级的时候，你需要充分评估升级的兼容性，以及升级后的相关影响，简单的可能只是改个包依赖重新上线即可，有些推荐包的升级跨度太大，比如 Spring Boot 要从 1.x 升级到 2.x ，兼容性方面存在巨大的挑战，这个修改可能还需要进行大量的功能测试回归验证，投入的精力也是比较大的。好在我们经过这些年的磨炼，已经把已知问题都修复了，另外是我们在内部也建设了相应的工具和体系来确保我们交付的产品是足够安全的。除此之外，我们在整个系统上也是采用了插件化设计，可以方便地对接不同银行或者企业内部的一些用户系统等，这也是我们在交付了多个项目之后打磨出来的一些灵活的对接特性。这是第二个问题，基本上都是在讲产品在落地过程中的一些“水土不服”的问题。

InfoQ： 之前您谈过金融 IT 系统业务连续性的挑战，这里都包含哪些内容？

翁扬慧：简单来说，金融 IT 业务系统的连续性挑战主要是在业务连续性的技术挑战之上，又叠加了金融行业的一些特色的要求。主要有这几个方面：

首先，是最本质的问题，如何有效地保障业务的连续性。保障的方式或者手段有很多，最核心的一个思想是永远不要让核心业务有可能处在单点故障风险中，所以从技术架构的演进历程中，为了解决服务的单点故障，我们一般采用至少双副本高可用部署，并且尽可能分散在不同的服务器上。为了解决机房的故障，我们提出了同城双活的架构方案。那城市如果出现问题了怎么办，于是我们又提出了异地多活的架构方案。这是层层递进的，本质上都是为了解决不同级别的单点故障，只要我两个服务或者两个以上服务同时在线，一旦其中一个出现问题的时候，就能随时切换服务，从而保障了业务的连续性。但这里说起来简单，实际上在这个设计过程中还是面临很多的技术问题，在软件开发领域，大家都知道，我们在引进一项新的技术或者新的架构时，往往会引入一些额外的问题，以多活来说，并不是在多个城市部署多个机房同时部署业务这么简单，它还需要解决数据分片，数据一致性，跨区访问，业务改造等等问题，这里面的每个问题都是需要有很多技术和经验积累的，不是说随便找几个人就能做出来的。

其次，我们始终绕不开的一个问题，就是成本问题。这个成本不限于工具或者平台开发的线性成本，这些成本是相对比较好理解和评估的。还包括一些隐性的潜在成本，比如业务的改造、接入成本，应用多活或者单元化的改造会比传统的比如微服务改造都要难和复杂，一定程度上说它是在微服务的基础上做的进一步的设计，比如应用多活中一项比较重要的能力是流量调拨，而流量调拨的基础是有一个统一的管理平台，并且能够通过对流量进行识别然后进行按照设定规则的转发，这本来就是微服务框架所涉及的范畴，所以想要做异地多活的业务改造，中间的成本其实不低，如何降低成本是我们在设计时要考虑的。

成本方面还需要考量整个项目的投入产出比，前面介绍到，不同层级的容灾设计，提供的故障应对能力是不一样的，比如异地多活的架构能解决城市级别的故障，但是它的整体建设投入成本会比较高，那作为项目的负责人或者技术架构师，就不得不思考这个技术投资是否真的有必要。夸张一点，即使异地多活解决了城市级别的故障，那万一地球被三体攻击了，我们还需要考虑地球级别的容灾吗？答案严谨一点说应该是暂时不用，确实没有必要。所以，所有的技术都有它的适用性，没有一项技术是能一刀切解决所有问题的，多活也一样，在建设的时候也要评估好成本。在一个技术大会上，一个券商的技术负责人说，真的出现城市级别的故障的时候，能做到保全好数据的完整性其实就已经很不错了，仔细想想确实是这么一个道理，有时候最适合当前业务的需求的实现，往往是性价比最高的。

第三个点，我认为挑战可能在于如何降低整体的系统复杂度和运维难度。比如我们在做一些容灾系统的设计，以多活为例，这里面会牵涉到很多的技术概念，同时也会横向交叉着一些流量治理的设计，用户学习和理解这个系统的成本其实是比较高的，但用户真正能够用好一个技术产品，是需要对这个产品的设计有深入的理解，所以降低用户的学习和理解成本，反过来又成为了我们首要需要思考的问题，既要保证在设计上能有一些通用性，去适应不同的业务团队，业务场景，又要考虑在实现上不太过于抽象，导致用户在使用的时候不知所措，这是一个在系统设计复杂度方面考虑如何去优化的挑战。另外是运维方面，运维是一个长期的过程，系统上线之后，大部分可能都要转交到一些运维团队做日常的巡检、演练和配置等，有一些企业的多活容灾系统，与其说是系统，不如说是一个工具合集，一些常用的功能经常需要在不同的平台之间来回切换，可能数据指标在负责监控的团队开发提供，流量配置在负责服务治理的团队中提供，这样子的运维成本很高，并且往往由于数据分散，很多时候没有办法形成一些统一的操作视图，用户使用运维起来也是相当心累。所以这是第三个关于在产品设计易用性方面的一个挑战，这往往会和团队的建设经验有关，有过多个类似的项目支撑，可以避免走很多弯路。

最后一个点是想说的是，在金融行业特有的合规性方面的挑战。其实国家针对金融信息系统的容灾设计要求方面一直都有监管要求，早在 2008 年就提出了类似《银行业信息系统灾难恢复管理规范》等面向银行的规范，而在 2021 年的时候，也颁布了《金融信息系统多活技术规范》，文件里明确提出了针对金融业务连续性保障的一些设计要求，首先是架构分层，要求多活系统应当分为业务接入层、业务处理层和数据存储层这三层，其次是针对这三个层次，规范中都有详细的定义了设计要求和参考方法，此外还针对业务多活接入、监控、流量分配等方面进行要求。

规范中还给出了多活的关键评估指标，分别是多活业务集中度，多活接管容量能力、多活同城业务集中度，多活业务接管时间、多活数据恢复点目标，最后两个对应的通常缩写是 RTO 和 RPO。所以对于金融行业，我们在连续性的系统设计时，并不是可以完全按照自己的想法去开发的，是需要按照规范中的设计要求去实现的，这是金融行业相对比较有特色的一个要求，也是一项比较大的挑战。

02 洞察篇

InfoQ：面对这些问题，对于金融企业来说，在多活容灾的设计过程中，和普通企业的多活技术设计思路和落地形态上有哪些区别？

翁扬慧：先说设计思路方面，普通的企业，相比一些金融企业，在多活容灾方面的建设时间可能也更早一些，因为互联网出现过一个爆炸式的增长，需要对业务的容灾有更好的保障。在容灾技术设计方面，几年前我们就已经听到了各大互联网企业有一些关于异地多活和单元化的落地实践，尤其是当业务增长到一定的规模的时候，机房建设都会从单一城市扩展到了多个城市，甚至是全球各地。在这种机房的部署形态下，为了更充分利用资源，就有了多活的架构设计。包括我们支撑过的网易云音乐、严选等，也是结合自身的业务需求做了多活和单元化的设计。所以，在容灾多活技术领域，早年大家各自为战，没有统一的标准，都是从解决各自的业务问题出发，不管白猫黑猫，反正能抓到老鼠的就是好猫，尽管技术设计上存在不少差异，但好在整个架构的顶层设计思想上基本上还是一致的，做多活为了解决业务的水平扩展和连续性保障问题，有一些单元化或者类似单元化之类的关键设计点。

而前面提到了，作为金融企业的 IT 团队，在做多活容灾的系统的设计时候，不能完全按照自己想法来，现在已经是有规范作为参考指引的。不管从架构的分层也好，从系统的关键设计指标也好，都是有一些相对比较明确的要求。

换个角度说，如果金融企业现在需要新做一套多活容灾系统的话，已经有一个顶层的架构设计参考建议或者标准，一定程度上也是能够有效避免走一些弯路的，所以这是围绕整个设计思路上的区别。我们在设计多活的时候，也参考了《金融信息系统多活技术规范》的要求，目的是为了更好地帮助金融用户能够减少建设成本，避免重复或者二次开发。

再来谈一下落地形态，首先是围绕上面的设计思路方面，会有一些业务架构分层的设计差异，在普通企业，其实整体上也绕不开这些分层设计，但是可能不叫这个名字或者表现不明显。比如规范中提到的业务接入层，在普通的企业中业务是通过一些全局接入网关或者微服务网关做的，没有什么接入层的概念，但实际上是有这个能力的。在金融多活的系统中，这个划分和界定也许会更加清晰，在使用上用户也更容易达成一致的认知，所以这是围绕整个设计规范在落地上的差异，比较好理解。

除此之外呢，我想重点介绍一下我们在金融行业的多年支撑过程中积累和理解的一些其它可能存在的落地差异，如果前面因为多活容灾建设时间不一样我们把它叫做时机的话，还有个比较大的差异就是动机。

随着这几年分布式技术的发展日趋成熟，很多银行在内的金融企业在做的一个事情就是传统的集中式架构往分布式架构的升级改造，也就是我们经常听到的“主机下移”。分布式架构的转型过程，对于银行现有的业务来说，是一次巨大的冲击，不管是从架构形态上还是技术栈的实现，同时它也是一个非常时间窗口，允许金融业务趁着架构转型完成整个业务技术形态的升级。所以相比传统企业只是为了解决特定的问题而提出多活的方案，在金融场景下，这可能是大的技术升级浪潮的一个重要组成拼图，它是围绕整个分布式架构的体系去做设计和建设的，可能也会参考一些行业的技术标准，例如《金融分布式架构设计参考规范》之类的。

此外，在多年的金融项目支撑中我们发现，金融企业对于整个技术实现的要求往往更高，而且在落地实施过程中也更加保守。普通的企业，尤其是在互联网公司，通常讲的是快速迭代，快速试错，有一些功能设计经过一定的测试和验证没有问题之后，就可以考虑尝试接入线上流量去做灰度验证。但是在金融行业，任何一个哪怕比较小的功能或者技术点，都是需要经过前期非常充分的讨论，以及方案验证的，而且从设计上也会提出更高的要求。举个例子，比如流量切换这个点，很多时候能实现一些机房的切换就能满足大部分的应用场景了，在金融场景下，可能会要求按照特定规则流量、单元、机房甚至是地区不同的级别都能实现流量切换的能力，并且要求切换的过程是秒级无感知的，这个实现起来就比较困难了。在实施过程中，也是需要长期的线下稳定性测试之后，及时到了线上，也可能也是通过旁路的一些方式先做并行验证，等经过长时间的验证确保业务都正常稳定之后，才会可能执行相关的上线，所以这是在落地过程中金融行业的一些高要求的区别。

还有一点差异可能大家都听过，就是这两年提得比较多的信创国产化，金融行业作为国家的重要支撑产业，我们的很多核心技术是需要自主掌控的，所以我们轻舟云原生平台在技术的一些选型和落地方面，也是做了大量的信创适配和验证等方面的工作，比如适配了国产操作系统，国产数据库，开源治理等相关工作，这些在非金融的行业，目前是不需要考虑这些问题的。

03 实战篇

InfoQ：能否大致介绍下分布式多活架构的技术实现，可以为在场的听众提供一些设计参考？

翁扬慧：涉及到整个分布式多活的架构实现，会比较复杂，也很难通过三言两句描述清楚，我就大概讲一下我们在多活产品设计的一些思路和理念，再结合几个比较关键的技术来做介绍，希望能给大家抛砖引玉，有一些启发。

首先从设计理念上，前面其实有提到，我们整个分布式多活的架构是参考了金融行业的设计标准，也结合了多年我们金融行业的支撑经验和内部互联网的技术积累设计的，因为作为一个面向商业化的产品团队，我们一方面需要考虑前面说的产品匹配度的问题，我们希望设计出来的产品对于用户而言是能够开箱即用的，所以相较于一些分散式的产品组合形态，我们提供的是一站式的平台产品，在一个控制台系统内我们把网关、微服务、监控、中间件等多个产品能力通过多活容灾集中进行管理，用户可以比较方便的进行操作使用。

另外再说下一些技术实现部分，大家知道，技术是会一直往前发展的，这几年其实爆发了很多新的好用的技术。包括这几天热点很高的 ChatGPT，一项新的技术有时候突然就诞生了，并且被大家所熟悉和认可。技术的选型也和电子产品一样往往是“买新不买旧”，在开发新的产品，也会先调研当前业界的主流选型，选用一些当下最合适的实现方案。

作为金融行业，在新技术的探索和追求方面，也从未停止过。一方面是一些陈旧的技术实现随着时间的推移会变成一些历史包袱，成了新业务发展和新技术落地的阻碍。另外一方面是新技术的“诱惑”让金融行业的 IT 从业者们尝试一些新的设计理念、实现方案。

那我们数帆轻舟云原生团队因为长期都在云原生领域里面摸爬打滚，算是在这方面积累了大量的经验，所以我们默认采用的整个技术实现也是偏云原生化的，比如整个平台架构是基于 K8s 部署的，在网关实现上基于云原生的代理 Envoy 做了很多优化和增强，而微服务也是基于微服务框架和 Istio 服务网格等多种技术引擎实现，满足客户的不同的架构设计需求，当然我们也在 Proxyless 方面做探索，包括像 Proxyless Mesh 和 Ambient Mesh 我们也做了一些探索和落地。为了解决一些用户的改造接入成本，我们在多活上的实现上，也基于轻舟云原生平台的无侵入式的 agent 做了增强，在部分的业务场景下，用户可以不用修改业务代码也能完成一些多活的业务改造，这是关于技术实现侧的一些介绍。

不过可能听众也许会有疑问，很多银行目前部署都还是基于虚机甚至是物理机，云原生的这种架构和这些技术形态是不是真的能比较低成本的落地。确实如此，基于云原生的整个形态使我们的标准形态，在落地过程中其实还是会面临刚才我们讲的一些“水土不服”的问题，有时候确实也是需要去考虑做一些兼容和适配的，所以我们整个产品在设计上也把灵活性和扩展性作为一个比较重要的目标，允许在不同的环境都能做到快速适配，也能快速对接不同的现有系统。比如在多活的产品设计上，除了在 Envoy 上支持多活的流量切换外，考虑到不少银行也是基于 Spring Cloud Gateway 作为网关的，所以我们也是提供了相对应的实现模块，可以比较灵活帮助用户现有系统改造升级。

尽管在实现上，我们的云原生平台会考虑针对不同的客户实际落地情况去做适配，但我们也看到好的方面是，越来越多的客户也逐渐更加接受并实践一些云原生化的技术，比如部署从虚机开始逐渐转到容器，并且用上了 K8s，服务治理也开始使用了服务网格这样子的云原生的治理系统。云原生是一种技术趋势，有时候你不得不承认，不知不觉其实大家都已经在这艘船上了。

InfoQ：多数据中心架构下，多活应用的架构有没有落地的最佳实践或者实施路径建议？

翁扬慧：前面基本上已经大致介绍过一些技术选型上我们的方案，这里我想补充一些关于整个系统在组织结构方面的落地最佳实践。在之前的一些项目支撑过程中，我们经常会被一些业务团队问到一个问题，多活是一个相对比较庞大复杂的系统，在整个架构的落地过程中，究竟应该是以业务作为出发点去设计呢，还是从平台的角度去设计，这也是一个关乎与架构落地最佳实践的问题。

按照我们的经验是在一个企业内部，平台化的统一架构设计思路更佳，有这么几个原因。

第一，还是绕不开的成本问题，我们已经知道了多活容灾系统的建设成本其实并不低，如果只是聚焦于业务去做多活的设计，后期如果有另外一个业务团队也需要建设多活能力的话，会面临技术重复建设的质疑，为了避免重复造轮子，所以在一个企业内部尽可能应该是一套通用平台来应对不同的业务部门的容灾需求；

第二，建设难度偏高，业务团队首要的业绩目标应该是聚焦于业务方面，所以日常对于业务方面会更加精通。而类似于多活这样子的技术平台，建设所需要的技术和人才储备是巨大的，不是随便找几个人搞个几个月就能折腾出来应用的，一般而言，有个企业内部会有专门的基础架构团队来承接做这样子的基础设施的建设，他们在技术方面有着更多的经验和积累，也更加能够通过协调一些横向资源，比如数据库团队、运维团队等；

第三，不利于企业内部的规范统一，我们看到很多银行这几年在推行内部规范的统一，尤其是早些年金融业务的快速发展，甚至有些是总分行的组织架构，各个团队各自为战，内部的技术实现、开发规范等等都是按照各自的标准定的，那随着业务的日趋庞大，发现不同的实现愈到后面愈难管理，中间还伴随着一些人员的变动，可能有些老的代码在经历几次交接之后，现在都没人敢去动它。这就是规范不统一带来的弊端，因此不少企业内部从开发规范、开发流程、开发工具，包括技术平台等基建方面开始去做统一这个事情，在这个背景下，如果还是按照业务维度去做多活的落地，与统一规范的理念是有点背道而驰的。

所以从整个实施路径上，我们更加倾向和建议的是平台化的落地设计思路。在一个企业内部，应当建设一套标准的，统一的分布式平台或者多活容灾平台来支撑不同的业务团队。这样子在后续的演进过程中也能有更加专业的人员去支撑，提供技术的演进和维护，所以有时候对于平台的设计也是一个考验，需要做的比较灵活，从而能满足不同的一些业务场景诉求，例如多活的流量分片规则引擎实现，它不应该是几个固定写死的规则，而是用户可以自由灵活配置，并且动态能够生效的这么一项能力。这里面实现上可以通过一些自定义插件等方式去做，具体细节方面就不展开介绍了。

InfoQ：如何确保设计的多活架构，容灾架构能在面对实际重大生产故障的时候能发挥作用？

翁扬慧：如果是想问如何确保多活架构能够一定应对业的故障，确保业务是能够一直连续，我想说这非常难，甚至可以说做不到。时至今日，我们还能偶尔听到一些云厂商的业务出现服务不可用的新闻，连谷歌和亚马逊都不能幸免于难。

容灾的建设不单单是一个技术问题，更是一个体系化建设的事情。因为要保障业务的连续性，不出现故障，中间牵涉的原因可能点有很多，而每一次出问题的点，往往是那些容易被忽略的地方，它并不是说技术架构上存在设计缺陷，更多的是一些在实施和管理中的疏忽，因为有人的地方，总是避免不了会出错。

所以从保障容灾的这个大的目标上来说，首先在技术架构方面，肯定要基于实际的容灾要求和目标去做相应的建设，并且配合一些有效的指标监控和告警手段及时反馈出一些风险，这也是我们设计容灾监控大盘的目的之一，希望通过直观的数据展示来有效的反馈出系统当前的健康状况。

回过来说，如果这个问题是想问说有没有手段可以帮助来检查当前的架构是否能够真的能应对一些故障场景，那答案是有的。最重要的应该属常态化的故障演练，通过结合一些故障注入工具，来模拟真实线上环境可能会出现的一些故障，来达到演练的效果。这种方法，对于检验一些容灾能力的有效性方面，还是有很大的帮助的。有的时候，为了提高对于故障有效性和真实性，我们也会引入一些工具，比如混沌工程，通过一些随机化的故障，让故障变得更加“捉摸不透”。即使这样，还是很难有效保障系统在某个环节出现故障时仍然可以对外正常提供服务。

为什么说是体系性的建设，作为多活或者容灾的建设，除了故障发生时的一些应对处理机制，在故障没有发生的时候，提前做好一些应急预案的制定，一旦真的出现问题，也能帮助我们能够快速地恢复业务，从而可以减少一些损失。所以有些地方会按照事前、事中和事后的维度来做容灾体系的建设，这也是另外一种建设思路。

InfoQ：金融分布式多活架构在落地过程中有没有一些坑，或者大家容易存在的误区？

翁扬慧：其实关于技术上的一些所谓的坑，大多数都是由于当时在做这个事情的时候的认知水平不够导致的，只要在问题发生之后，能够彻底弄清楚问题的根本产生原因，解决掉它之后，也就不存在所谓的坑，学习的过程本身可以说就是踩坑积累经验的过程。

这里我想可以稍微讲几个新人在学习过程中可能容易存在的一些误区，也许能更好帮助大家理解一些多活的设计。

首先，今天的主题是多活，我们提到异地多活往往会结合单元化设计去落地，并不是说单元化的设计解决了业务的连续性保障问题，而是异地多活的架构下，通过单元化的设计可以更合理地利用资源，它解决的是跨区数据访问性能瓶颈和系统水平扩展问题。而这种异地多活的架构恰好又能较好的保障好业务的连续性，支持地域级别的故障切换，但是它引入的其它的问题也是需要我们去解决的，比如数据一致性等，所以这里面的逻辑关系需要厘清。但这里重点想说的，异地多活架构不一定必须做单元化，同城多活也不是不可以做单元化，这两者没有直接关联关系，这是一种设计最佳实践。单元化设计它不是万能的。所以我们在做架构设计的时候，还是要基于实际的业务场景，选用最符合当前诉求的容灾架构。

另外，即使是业务已经发展到了异地多活，并且必须要要上单元化的设计之后，并不是所有业务都需要做单元化改造的，允许存在一些全局、或者局部的“中心化”业务。全局业务比较好理解，所谓的局部中心化“业务”我们也叫做区域信息系统，一般来说是针对一些不可拆分或者不需要拆分为多子信息系统，并且访问频率不高的业务，可以根据性能需求在每个地域部署并提供可读能力。而全局信息系统则是针对一些访问频率低，数据仅有一份，数据一致性要求非常高的业务。所以，第二个容易存在的误区是很多人往往会以为一旦业务要上单元化之后，所有的业务以及流量都得考虑要做拆分，这个思路是不对的。并且即使是针对同一个业务，在整个后续的灰度上线过程中，也会存在一些新旧业务的兼容形态，以确保整个上线过程是平滑的。

最后，针对同一个业务系统，单元化的规则它也不是唯一的或者是一成不变的，比如有的业务可以根据用户的 id 取模分片进行单元化的划分，但有的就可以根据一些特定的标识，比如地域信息，甚至业务属性等进行单元切片划分，不同规则是允许同时存在一个系统内运行的。另外，单元化的规则也是只是动态的调整，从而可以用于满足一些例如扩容或者缩容这样子的业务需求场景。所以这对于平台的这种灵活性设计要求还是比较高的。

04  展望篇

InfoQ：分布式架构在金融领域不是新技术，您认为接下来金融领域的架构会往哪个方向演进？

翁扬慧：确实分布式架构不是一项新技术，但是这几年在金融行业被经常提起，我认为主要的一个背景是前面提到的传统银行的技术架构从集中式架构往分布式架构转型的过程中，需要依赖于很多分布式技术作为承载，这是去 IOE 过程中非常重要且不可或缺的一环。

但是分布式架构涉及的范围其实又非常广，从最简单的 RPC 调用，到服务注册发现，再到服务治理和监控等等，都是分布式架构中会面对的一些常见问题。好在目前在技术领域很多东西是开放的，大家可以相互学习和借鉴，甚至都不需要任何操作，就可以直接引用别人提供的一个比较完善的框架，这是技术时代我们享受到的红利。

技术的快速发展、更迭，有时候就好比宇宙大爆炸一样，出现各种各样的开发语言、技术框架、技术组件等，导致有时候用户在选择和使用技术的时候，不得不陷入思考：我究竟应该用哪个技术，如果用这个会不会有什么问题，使用起来难度会不会很大，后续在业务的长期演进中会不会有问题……诸如此类的烦恼。

所以我们通过一种平台化的设计理念，通过分布式技术平台，设计了一些通用能力，提供一些更加云原生和标准化的开发最佳实践，来帮助用户更好的去业务开发，从而提高整个生产效率。

而金融领域的架构，我们看到的，是朝着一个云原生和标准化的方向演进。前面其实有提到，有不少银行客户，在一些内部的业务系统上已经改造成容器化的方式运行，通过 K8s 有效地提升了管理和运维效率。也有一些客户，已经在一些关键的业务上落地了服务网格等云原生的微服务架构形态，也正在探索多运行时等一些新的设计理念，金融架构的发展，本质上是做金融架构技术的这部分技术工程师们主导的，那云原生基本上是业界和社区发展所认可的，这是逐渐“标准化”的过程。

而另外一个标准化，我想说的是金融架构由内到外都随着业务发展朝着一个更加统一好管理的方式演进，所谓由内，金融企业内部开始由一些架构团队制定一个统一的开发规范，来约定大家的开发模式和开发行为，本质上为了更低成本地去做提高生产力的事情。这和我们的出发点是一样的，只不过我们是通过平台和工具，他们是通过流程规范。而外部，从整个金融行业的行业标准、监管规范等方面，都形成了一些架构设计标准，包括对于信创国产化，技术自主可控等方面的要求，也促使金融架构越来越趋于标准化。

所以，云原生和标准化，两者是有一定交集的。云原生的部分设计理念是通过一些标准的技术抽象来统一不同的技术实现，但这个标准化不是说给用户限定了一种选型，反而是让用户以更加标准、开放的方式来解决软件开发的生产力问题。这也是我认为金融领域架构会发展的方向，当然金融架构在稳定性、安全性、合规性方面有着更高的要求，这个是始终不会变的。