洞察分布式架构及银行业应用

Posted 2021-04-14 兴业数金

随着云计算、大数据、移动互联、社交网络等技术的发展，线上业务由于不受线下物理网点的限制，其交易量呈现几何级数的增长。尤其是随着铺天盖地、花样繁多的营销活动，互联网业务经常面临在短短时间内出现以往线下难以想象的业务峰值冲击。我们开始好奇这些互联网公司的IT系统是如何具备这样庞大的业务处理能力。于是，基于分布式的微服务架构开始备受关注。

文/纪建锋，兴业数字金融 研究开发总部总经理

---

       说到分布式架构，它其实并不是一个新事物，从上个世纪中叶就有人提出了分布式系统的概念。随着计算机技术的快速发展和应用场景的不断变化，现在我们所谈论的分布式架构与传统的分布式架构有了较大区别。传统的分布式架构一般指通信层、应用层、数据库等各个层次的集群部署，使每个层次都具备了较好的横向扩展能力，从而实现压力的分散，使系统的并发处理能力、吞吐量以及可用性有了较大程度的提高。现在所谈论的分布式架构一般是指基于分布式的微服务架构，或者称微服务架构，在分散压力之外更多的是能力的分散，使一笔业务不同处理环节分散到多个服务/能力中心进行处理，降低了业务的复杂性，也使每个服务具备了独立扩展的能力。

       除了互联网公司、互联网金融公司外，一些银行也开始在一些业务领域试水分布式架构。但大多数银行之所以开始采用分布式架构搭建银行业务系统，其主要目标还是实现业务系统的高并发能力、高吞吐量以及较为灵活的横向扩展能力。在实现过程中对业务特性以及处理逻辑等进行简单的局部的分析，按高内聚松耦合的原则将交易系统划分为若干个服务/能力中心，使得一项业务通过多个服务/能力中心协作处理，从而宣告分布式架构成功落地。但这仅仅是分布式架构的皮毛。对于类似阿里等技术能力较强的互联网公司，分布式架构不仅是一个底层技术平台，更是一个治理和管控平台。且就技术平台而言，也不仅仅是采用了一个类似DUBBO的底层技术平台，还需通过企业多年沉淀的软件开发标准和规范来较好的支撑各类应用在分布式架构上的实现。因此同样是落地了分布式架构，在不同的企业内部，其所达到的目标和意义有着云泥之别。

       目前银行大多都有上百套系统，虽然对单个系统来说都是集中式或者传统的集群部署架构，但其中很多业务现在也无法仅仅由单个系统就能全部处理完毕，也涉及多系统协作。从企业级架构来看，也勉强可以说是能力分散的分布式架构，只是能力划分的颗粒度较大而已。随着多系统协作的业务越来越多，由于系统间接口的不一致性，异常处理的不一致性，加上之前单个系统建设时未在多系统协作上充分考虑，其接口设计、日志规范等均无法较好的支持跨系统协作。因此在过去的十来年间，为了解决这些问题，不少银行纷纷启动了SOA和ESB的建设。当时较流行的一种说法是“银行系统间交互都是网状结构，软件更新复杂程度高，牵一发而动全身，因此急需建设ESB，使系统间交互基于总线结构，并通过ESB进行服务治理，实现企业级的SOA”。

       多年前我曾经参与了一次关于ESB的讨论，我的看法大致为：“银行之所以需要ESB，是因为银行的大多数系统在建设时，系统间交互的标准规范缺失，这些规范包括消息接口规范、数据字典规范、异常处理规范、消息安全规范、服务管理规范等等。没有了标准也就没有了系统间交互的通用语言，就相当于多个国家的人在一起交流，需要一个翻译，而ESB就是这个翻译。当有了较为完整的系统间协作的规范后，ESB就可以退出历史舞台了。现在互联网其实就是一个网状结构，有了html等各种基于互联网服务访问的协议，使得互联网上的各个服务虽然是各自建设的，但他们也能很好的高效的协作。”因此，基于ESB的企业级架构只是用于解决当时问题的临时性架构方案。

       回到基于分布式的微服务架构上看，相比原来基于一种/类业务场景构建一个系统，微服务的分布式架构把颗粒度分得更细，服务中心之间的协作远比之前的系统间协作更为复杂，环节也更多，这对服务间协作的规范和标准提出了更大的挑战。虽然基于DUBBO等基础技术构建的微服务分布式架构已经帮我们解决了一部分标准的问题，如消息接口规范、服务管理规范等，但在数据/事务一致性等方面仍然存在欠缺。相对于银行业务来说，电商业务较为简单，环节较少，而银行的业务要复杂很多，处理链条也要长很多。在一致性等方面的规范标准缺失将会使得应用了分布式架构的系统随着业务种类越来越多、越来越复杂，将面临较原来基于集中式架构所出现的网状结构问题更大得多的架构危机。因此，在落地分布式架构时，不能简单的完成类似DUBBO等基础技术框架的应用，还要重视服务间协作、事务一致性、数据标准等各种规范的建设以及服务、数据的规范管控，这样才能使我们基于分布式架构的各类应用有坚实的平台，才能使分布式的微服务架构成为ESB的“终结者”，企业的SOA治理也就不再需要ESB。由此可见分布式的微服务架构落地的更大意义是科技治理、服务治理，是实现企业级SOA的“利器”。当然，企业级SOA的实现，技术方面仅仅是一小部分，绝大部分取决于管理。管理包括规范标准的制定和服务、数据、架构的管控，这些对企业的IT标准化规范化水平和管控能力提出了较高的要求。到目前为止，很少有企业能宣称较为全面规范的实现了组织级的SOA化。之所以说分布式的微服务架构是实现企业级SOA的利器，是因为基于分布式的微服务架构要作为企业的服务能力平台以及服务管控平台进行落地时，对企业内部的服务标准化、服务治理和服务管控同样提出了较高的要求，也就是对企业的SOA化提出了要求，从而支持并推动企业持续进行SOA治理，最终实现全面的企业级SOA。

       关于银行在进行微服务架构试水时，为保障存量系统的稳定性、可用性，避免风险失控，建议先在小范围试点，在指定的某个领域或某个系统采用微服务架构进行构建。但在试点过程中要有大格局、高标准，相关服务的设计、服务标准化以及服务管控必须按企业级架构管理的水平进行要求。规范标准以及相关制度必须同步进行甚至先行，使微服务架构的落地不仅是一种技术架构的探索，也要推动企业进行一整套标准规范、治理管控体系直至方法论的逐步落地，使得试点微服务架构的落地从开始就做好了“由点到面”推广到企业所有IT信息系统的准备。总而言之，基于分布式的微服务架构将逐渐成为主流，银行IT架构也将从集中式向集中分布相融合发展，直至实现完全的面向SOA的分布式微服务架构。

---