中国工商银行软件开发中心微服务框架探索与实践

  随着信息技术的快速的提升，尤其是云计算和大数据技术的广泛应用，银行业在面临业务量激增和技术更新换代时，分布式架构的应用成为必然趋势。在分布式架构转型的过程中，中国工商银行软件开发中心（简称：工行软开中心）积极地推进微服务架构、容灾体系建设和技术底座的更新换代，旨在提升运营效率、保障系统稳定和提升使用者真实的体验。本文将对工商银行的微服务框架演进历程、技术挑战进行解读。

  移动互联网时代到来，业务规模的持续扩张和交易复杂度的不断的提高，这种架构模式的局限性日益凸显。巨石架构由于其固有的特性，导致系统在多重维度上面临严峻挑战：首先，代码规模庞大且结构较为复杂，使得系统扩展和维护的难度呈指数级上升；其次，模块之间的高度耦合导致任何单一模块的变更都可能引发连锁反应，增加了系统变更的风险和测试周期；再次，系统弹性不足，难以实现水平扩展，面对高并发场景时有可能会出现性能瓶颈；最后，单点故障的风险明显地增加，系统的可用性和稳定能力受到严峻考验。这些缺陷严重制约了系统的可维护性、可扩展性和业务连续性，成为制约业务发展的关键因素。

  随着分布式技术的日益成熟和业务发展的迫切需求，2014年工行软开中心真正开始启动了以微服务框架为基础的分布式架构转型工程。整个转型过程经历了六个关键阶段：第一阶段是技术预研，对微服务架构的适用性、可行性及潜在风险进行了深入研究和评估；第二阶段是微服务试点，通过在部分业务系统中实施微服务改造，验证了其技术可行性和及早识别潜在风险；第三阶段是分布式体系初步形成，并首次支撑纪念币预约活动；第四阶段是微服务全面推广，包括手机银行在内的互联网应用全面微服务化；第五阶段是以微服务框架为基本的建设开放平台银行核心系统实现与主机系统的双轨运行；第六阶段是所有应用系统全部微服务化，核心账务微服务化单轨运行，标志着工商银行完成了从传统架构到现代化分布式架构的全面转型。

  这一架构转型的核心在于将系统拆分为多个小的、独立的服务模块，每个模块专注于特定的业务功能，从而明显提升了系统的灵活性和可扩展性。微服务架构的引入，不仅使开发团队能够在小范围内快速迭代，提升了研发效率，还大幅度降低了系统的维护成本。同时，通过服务间的松耦合设计和独立部署能力，逐渐增强了系统的容错能力和可用性，为业务的持续稳定运行提供了有力保障。这一系列变革为工商银行的数字化转型奠定了坚实的技术基础，同时也为其在激烈的市场之间的竞争中保持技术一马当先的优势提供了重要支撑。

  工行软开中心在微服务框架演进过程中，成功应对了应用服务化、微服务集群规模化和容灾体系建设等挑战。以下是其应对这些挑战的具体策略和成果：3.1 应用服务化挑战与应对在采用单体架构的银行系统向微服务化转型过程中，面临着诸多挑战：首先是微服务框架在构建企业级能力方面，如何确保系统稳定、安全、高效运行；其次，如何将现有的主机应用平滑接入分布式系统，确保业务连续性和数据一致性。

  在Dubbo的基础上，对其进行精细的裁剪与深度扩展，打造出一套符合自身需求的自研企业级微服务框架。自主开发了服务网关、服务管理、服务监控、服务跟踪以及日常巡检等一系列服务治理功能，以增强系统的整体性能和管理效率。

  自主研发的服务网关能够智能地实现HTTP与RPC协议的自动转换，将主机应用所使用的服务接口元数据注册到注册中心，以便进行统一管理。其服务网关主动订阅接口元数据信息，实时更新和优化路由策略，从而逐步提升服务的动态管理和智能调度能力；确保了其微服务应用与现有的存量主机应用之间的互联互通。在应用微服务的改造过程中，主机应用通过HTTP方式接入服务网关，以便访问分布式服务，这一过程不仅简化了接入流程，也明显提高了系统的整体性能和可用性。

  随着微服务化战略的全面深化，大规模服务的部署与调用已远远超出现有开源微服务框架和注册中心的能力范围，对系统的稳定性形成严峻的挑战。例如，注册中心在处理大量数据推送时面临的效率和时延问题、网络带宽和连接数的限制、以及微服务框架在内存和CPU资源利用上也许会出现的膨胀问题。这样一些问题不仅考验着系统的承载能力，也对其稳定运行构成了重大挑战。

  工行软开中心在其服务架构中选用Zookeeper作为服务的注册中心，然而随着服务集群规模的扩大，Zookeeper注册中心遭遇了网络连接数激增和数据推送量剧增的挑战。为了应对这样一些问题，工行软开中心采取Zookeeper集群的架构升级策略，引入了Observer节点和Observer分组机制。这些Observer节点有效地分担了网络连接的负载，同时又不影响Participant节点的选举速度，Observer分组机制实现了客户端流量隔离。

  Zookeeper集群部署架构升级后，虽然解决了网络连接数和数据推送量的挑战；但是，服务集群规模化后，Zookeeper服务端还面临读写并发处理瓶颈。通过优化Zookeeper服务端源码，实现读写分离；一方面将读请求的处理逻辑从主处理线程中剥离，交由独立线程处理，避免读请求堆积影响对写请求的响应。另一方面新增读请求处理线程池，提升CPU和网络资源利用率，加速服务订阅处理。

  微服务普及后，转型进入深水区，遇上问题也更具挑战性，例如随着集群规模化慢慢的变大，大规模的服务器启停会引发服务频繁出现超时异常，即经典C10K问题。如下图所示：

  工行软开中心针对所面临的问题进行了深入剖析，发现出两个核心问题：第一，微服务框架中的频繁心跳机制导致Netty线程频繁忙碌。这种机制要求在每个心跳周期内，向所有在上一周期内未发送或接收报文的消费方发送心跳信号，同时消费方也向提供方发送心跳。随着消费方数量的增加，心跳报文的堆积使得处理这些报文的过程消耗了大量CPU资源，进而影响了业务报文的处理效率。第二，Linux服务器上全连接队列的容量不够。在提供方重启后，注册中心向所有消费方推送提供方上线的通知，导致所有消费方几乎同时与提供方建立连接，进而引发全连接队列的溢出，产生大量单边连接，这导致首笔交易非常有可能超时失败。

  针对以上问题做如下优化与升级，一是修复微服务框架在特定场景下不发送心跳的缺陷和降低单个心跳处理耗时。二是优化异步网络处理事件能力和打散心跳密集处理机制。三是调整TCP参数（增加全连接队列长度）。

  全面微服务化虽然可提升系统的可扩展性，但同时也带来了系统故障和灾难恢复的新挑战。工行软开中心基于微服务框架建设单元化架构体系，实现了故障的自动转移和恢复。

  单元化架构是一种分布式体系下企业级部署架构，该架构面向一组用户,在一个部署单元内部，内聚部署其所需要的主体业务服务，使得客户交易相关流量可在单个单元内部完成闭环，减少不必要的跨单元、跨园区访问；可在区域性故障场景下有效控制故障爆炸半径，在降低切换粒度的同时提升切换灵活性，有效克服数据中心距离带来的网络延时损耗，大幅度的提高应用对数据中心所处位置的适应能力。工行软开中心基于微服务服务框架实现具有工行特色的金融级单元化架构，可在区域性故障场景下有效控制故障爆炸半径，目标单元故障后自动切换至备份单元，故障恢复后自动实时回切。

  中国工商银行的分布式架构转型，不仅是一项技术革新，更是其推动业务数字化转型、提升服务能力的战略选择。在未来的金融科技浪潮中，工行软开中心将继续发挥技术优势，推动金融服务的创新与发展。通过逐渐完备微服务框架和分布式架构，更好地应对未来的技术挑战，提供更智能、稳定和高效的金融服务。

  特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。

  报道称若谈判未达成满意结果 欧盟拟对价值1000亿欧元的美国商品加征关税

  投诉缠身、市值蒸发超6000亿，“免税一哥”中国免税陷增长困境ESG案例

  首款RTX 50系创作本ProArt 创16 2025今日开售，定义高效AI创作

  直屏水桶机REDMI K80至尊版曝光：独显双芯+100W有线元！Buffalo推出限量版透明机械硬盘：仅保修一个月

  华为Pura80Ultra影像规格再被确认：均是国产CIS，均深度参与自研

  iPhone17不香了？只因iPhone18系列与折叠屏，频繁被确认关键信息

  《编码物候》展览开幕 北京时代美术馆以科学艺术解读数字与生物交织的宇宙节律