共计 12109 个字符，预计需要花费 31 分钟才能阅读完成。
作者：李忠良
市场的变幻，政策的欠缺，技术的变革……种种因素让咱们面对太多的挑战，这仍需咱们一直摸索、克服。
往年，网易数帆将继续推出新栏目「金融专家说」「技术专家说」「产品专家说」等，汇集数帆及合作伙伴的数字化转型专家天团，聚焦大数据、云原生、人工智能等科创畛域，带来深度技术解读及其在各行业落地利用等一系列常识分享，为企业数字化转型胜利提供有价值的参考。
由 网易数帆云原生技术专家翁扬慧对话 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 无效地晋升了治理和运维效率。也有一些客户，曾经在一些要害的业务上落地了服务网格等云原生的微服务架构状态，也正在摸索多运行时等一些新的设计理念，金融架构的倒退，实质上是做金融架构技术的这部分技术工程师们主导的，那云原生基本上是业界和社区倒退所认可的，这是逐步“标准化”的过程。
而另外一个标准化，我想说的是金融架构由内到外都随着业务倒退 朝着一个更加对立好治理的形式演进，所谓由内，金融企业外部开始由一些架构团队制订一个对立的开发标准，来约定大家的开发模式和开发行为，实质上为了更低成本地去做进步生产力的事件。这和咱们的出发点是一样的，只不过咱们是通过平台和工具，他们是通过流程标准。而内部，从整个金融行业的行业标准、监管标准等方面，都造成了一些架构设计规范，包含对于信创国产化，技术自主可控等方面的要求，也促使金融架构越来越趋于标准化。
所以，云原生和标准化，两者是有肯定交加的。云原生的局部设计理念是通过一些规范的技术形象来对立不同的技术实现，但这个 标准化不是说给用户限定了一种选型，反而是让用户以更加规范、凋谢的形式来解决软件开发的生产力问题。这也是我认为金融畛域架构会倒退的方向，当然金融架构在稳定性、安全性、合规性方面有着更高的要求，这个是始终不会变的。
理解更多网易金融分布式解决方案
