中国工商银行软件开发中心微服务框架探索与实践
伴随着信息技术的迅速发展
一、分布式架构转型的背景与动因
在移动互联网时代背景下，随着业务规模持续增长以及交易复杂度日益提高，在这种架构模式下面临着越来越严峻的问题。巨石架构虽然具有一定的优势但也存在诸多限制：首先开发规模大且架构复杂导致系统扩展与维护难度呈指数级攀升；其次由于模块间的高度耦合性问题，在任何一个模块发生变更时都会引发连锁反应进而增加系统变更的风险和测试周期；再者系统的弹性不足使得纵向发展受限于现有技术架构难以实现水平扩展面对高并发场景容易陷入性能瓶颈；此外关键节点故障率显著提升导致系统的可用性和可靠性面临严峻考验这些问题严重制约了系统的可维护性和可扩展性成为影响业务发展的主要障碍
二、微服务框架演进阶段
随着分布式技术的不断发展与业务需求的日益增长, 2014年工行软件开发中心启动了基于微服务框架的分布式架构转型项目.整个转型过程划分为六个核心阶段:第一阶段为技术预研,深入研究微服务架构的适用性、可行性及其潜在风险;第二阶段开展微服务试点,在部分业务系统中实施微服务改造以验证其技术和风险;第三阶段实现初步分布式体系框架,并成功支撑纪念币预约活动;第四阶段全面推广微服务应用,包括手机银行在内的互联网应用实现了完全微服务化;第五阶段基于微服务框架构建开放平台银行核心系统,实现与主机系统的双轨运行模式;第六个大步骤推动所有应用系统全面转向微服务架构,核心账务采用单轨运行模式,标志着工商银行完成了从传统架构向现代化分布式架构的历史性转变.
该架构转型的关键是将系统划分为若干个相互独立的服务模块，在每个模块内实现特定的功能领域操作。这一变革极大地增强了系统的灵活性与扩展能力。采用微服务架构后不仅极大地缩短了开发周期，并且实现了快速迭代的同时显著提升了研发效率。此外还大大降低了维护成本并进一步增强了容错能力与可靠性为此系列变革为工商银行的数字化转型提供了坚实的技术保障同时也为其在市场竞争中巩固技术优势奠定了基础
三、微服务框架演进中的挑战与应对
工商银行在构建微服务框架的过程中，在应用服务化方面取得了显著进展，并且成功实现了微服务集群的规模化部署。针对上述技术挑战与业务需求的持续优化，在具体策略上主要体现在以下几个方面：一是通过模块化设计提升系统灵活性；二是建立统一的服务网格架构以增强可扩展性；三是完善容灾预案体系以确保系统安全稳定运行；四是引入自动化运维机制以提高管理效率。经过一年来的持续努力，在各项关键指标上均达到了预期目标
3.1 应用服务化挑战与应对
在银行系统的单体架构向微服务化转型过程中, 面临着面临的重大挑战: 首先是基于微服务架构支撑企业级功能方面所面临的挑战——即保障系统的稳定性、安全性以及运行效率; 其次是实现现有主机应用顺利过渡到分布式架构环境以确保业务连续性与数据一致性。
企业级微服务框架能力建设
基于Dubbo平台进行精雕细琢的优化与深层次的强化，在此基础上打造出了专属于本公司的企业级微服务架构体系。经过团队的努力构建了全面的服务治理模块，并在此过程中显著提升了系统性能水平并强化了管理效能
存量主机应用平滑接入分布式体系
该服务网关具备智能化能力以完成HTTP与RPC协议间的自动转换从而进一步提升了其动态管理能力和智能调度效能；并确保了微服务架构与其现有存量主机应用之间的良好互联互通。在实施微服务架构改造的过程中基于HTTP方式接入该 service gateway以便访问 distributed service资源这一过程不仅简化了接入流程步骤也显著提升了系统的整体性能和可用性水平
3.2 规模化挑战
随着以微服务为基础的战略全面深化, 大规模服务部署与调用规模已远超现有开源微服务框架及注册中心的能力极限, 给系统稳定性带来了严峻考验. 由于 register center 在处理海量数据推送过程中会面临效率低下与延迟积累的问题, 同时网络带宽及连接数量受限, 而由于 micro service架构在内存占用及 CPU 利用度上存在过度扩张的风险. 这些问题不仅会对系统的承载能力构成挑战, 也会给系统稳定运行带来重大威胁.
注册中心
工商银行软件开发中心在其服务架构中采用了Zookeeper作为服务注册的核心组件；然而，在服务集群规模不断扩大时；该系统面临网络连接数量激增以及数据推送量急剧上升的问题；为此；工商银行软件开发中心决定实施Zookeeper集群优化升级方案；并在原有架构基础上引入了全新的.Observer节点以及基于其设计的分组机制；这些新增节点不仅能够均匀分配网络连接负担；而且能够有效隔离客户端流量而不影响参与节点选举的速度
Zookeeper集群部署架构经过优化后，在一定程度上缓解了网络连接数量与数据推送能力方面的限制；然而，在服务集群规模扩大时，Zookeeper服务端仍需应对高并发的读写性能挑战。通过改进代码结构实现对读与写的独立化管理：一方面将单独抽出专门的线程负责处理所有读请求，在不影响主线程效率的前提下释放了资源；另一方面建立了 dedicated 的读队列处理器集群系统以提高系统吞吐量与响应速度。
RPC网络通信挑战
随着微服务架构的广泛应用后,企业逐渐迈入了技术发展的深层阶段,面临着更为严峻的技术挑战.其中,当集群规模不断扩大时,由于规模庞大的服务器启停操作会导致频繁出现超时异常情况,这被广泛称为C10K问题.参考下图所示:
工行软开中心通过深入剖析的方式揭示出两大关键问题：其一，在微服务架构中频繁的心跳机制导致Netty线程处于高负载状态。这种机制要求每个心跳周期结束后必须向所有未在上一周期发送或接收报文的服务端发起一次心跳信号，并由这些服务端将相应的心跳信息反馈给提供端；其二，在Linux服务器环境中存在全连接队列容量不足的问题。当服务端重启后系统会自动向所有接入服务端推送新的上线通知消息这一行为会导致几乎所有接入服务端瞬间建立连接从而引发全连接队列饱和并产生大量的双向通信链路这将直接威胁到首次交易请求的时间响应效率
针对上述问题做如下优化与升级：首先，在特定场景下修复微服务框架存在的无法正常发送心跳的漏洞，并缩减单个心跳节点的处理耗时。其次，在异步网络中优化事件节点的处理能力，并分散密集型节点的心跳机制。最后，在TCP配置中进行参数调整（主要是提升全连接队列的最大承载能力）。
3.3 容灾与高可用
采用全面微服务化策略虽然能够显著提升系统的可扩展性 但这也带来了系统故障与灾难恢复方面的全新挑战 工商银行软件开发中心基于微服务框架构建了单元化架构体系 并实现了故障的自动转移与恢复过程
单元化架构在分布式环境中实现企业级部署，在独立的功能模块内整合所需主要业务服务，并为特定用户群体提供服务。该架构设计使客户交易相关流量能够在单一功能模块内实现完整闭环运行，并降低了不必要的跨模块、跨地域的数据访问频率。在区域性故障情况下能够有效限制故障范围，在降低切换粒度的同时提升了系统的灵活性与响应速度。同时该架构成功克服了数据中心物理布局带来的网络延迟问题，并增强了系统对物理位置变化的适应能力。基于工行特色金融级微服务框架构建的工行软开中心实现了高效可靠的服务运行机制，在区域性故障场景下能够快速定位并切换至备用功能模块，在故障恢复后能实时切换至主功能模块以保障服务连续性。
四、未来展望
中国工商银行的分布式架构转型不仅是推动业务数字化转型的关键举措之一，并且也是其核心战略的一部分。在未来的金融科技浪潮中积极应对这一趋势，在未来将持续发挥工行软开中心的技术优势，并不断提升其在微服务框架和分布式架构建设方面的能力。通过不断优化和完善相关架构设计，在未来能够更好地应对各种技术挑战，并为客户提供更加智能化、稳定性和高效的金融服务体验