文章摘要

本文以某农村商业银行敏态微服务建设为背景，探讨了敏态服务建设在农商行体系建设的难点与建设方案，提供了一条可落地的技术架构路线，旨在敏态微服务建设的路线上给大家提供下思路及建议，如有不足，希望大家能留言指出。

一、为什么要做敏态转型

近年来，随着金融行业业务的快速发展，高并发、大流量的业务场景不断涌现，行内业务系统也面临着严峻的挑战。本人所在农商行（下文称本行）原有的基础架构、技术架构已无法有力支撑不断迭代与升级的互联网业务系统。如何跟随云原生的脚步实现敏捷化，并为应用提供有效的技术架构及底层平台支撑，显得尤为重要。

基于此背景，本行于 2020 年启动了敏态分布式研发运行平台的建设。基于微服务架构体系，通过容器云平台作为敏态转型应用运行的核心载体，建设一体化的敏态应用全生命支撑平台，从开发、运维、运行多个形态提供全方位的应用管理能力。

二、建设挑战和难点

1. 现有 IT 架构和业务架构的痛点

业务架构是业务与系统的纽带，可以帮助企业完成全面的数字化转型，使企业通过技术将内部、业务与 IT 深刻的连接起来，成为高效的数字化企业。而随着业务的发展壮大，业务系统与 IT 架构之间的边界已经日益模糊，急需通过技术手段来帮助科技人员理清两者的关系。

数字化转型的首要任务是依据云原生路线，建设微服务化体系，而微服务化的体系又依赖于微服务开发、运行观测的架构管理，基础设施、资源调度的云计算设施，以及统一发布、统一运维。因此 ， 行内在仅有一部分微服务业务系统的情况下，就尽早启动了微服务化体系的建设。

建设时首先考虑微服务架构的选择、相关组件选的选型，并制定统一的开发、运维和运行规范，以便于微服务业务系统的统一管理；其次是资源维度，在原有的 IAAS 平台 能力上， 基于容器化技术建设 PAAS 平台，以提供应用服务的弹性伸缩能力，保障业务系统的高稳定性和高可用性；最后是行内大量的存量业务系统，在数字化转型的过渡期，做好存量业务的兼管，以及增量业务的快速接入，实现统一治理。

图：业务架构和 IT 架构的关系

2. 异构微服务难于统一管理

目前行内已有部分业务系统采用微服务架构，架构使用情况多数是 SpringCloud ，但是版本有所不同，另外注册中心也有差异： Eureka 、 Nacos 等未统一，还涉及到其他的治理组件，如配置相关、监控相关、日志相关的组件，均未统一设计建设。

微服务的管理几乎没有专门的管理平台，全部是基于开源组件，很多没有管理页面，更莫论统一管理。另外，各类中间件分别建设也导致资源浪费严重、微服务优势不能体现，流量控制不能灵活配置生效，管理及其不便。

从运维、管理者的角度来看，之前的所有微服务系统，后台运行情况基本上都处于黑盒，既无法获知其运行状况，更难定位其运行故障，着实难以管理。尤其现在这部分微服务的系统，再次改造将面临极大的阻力，因此对于异构微服务的统一管理将较为困难。

3. 存量业务如何兼容

行内之前一直采用 GXP 作为老一代的服务总线，伴随着业务系统增多，监控和治理能力渐感不支。此外，如何保障新老应用间的通讯，简化网络策略的运维管理，提高企业级网关的高可用，也成为必须要解决的难题。

4. API 网关如何建设

目前行内存在多网络区域，并且有外联的业务需求，在建设微服务的同时还需要考虑存量业务之间的通信，尤其在与 GXP 的兼容和替代的过渡阶段，如何实现不同协议、不同报文的通信，如何实现跨网络区的调用，如何实现灵活的访问控制和流量控制，都将落实在 API 网关的建设中。包括微服务自身的 API 网关在内，多种类型，多种运用的网关的总体建设、统一管理将是部署架构和业务架构不得不考虑的问题。

5. 容器云网络痛点分析

目前，各家厂商都有自己的独特的网络方案，如何既满足行内本身业务架构体系的诉求，又满足业务人员的需求，是 我们需要解决的 主要痛点。

从运维管理角度，运维人员更倾向于采用二层网络模型：在主流的二层组网的数据中心中，受限于硬件能力、运维人员的能力和管理复杂度等需求，大部分运维人员不希望引入 BGP 等三层路由概念，希望采用大部分运维人员比较熟悉的二层网络方案。

从网络角度考虑， 业务通信需要 容器云内部网络与外部网络互联互通：业务应用往往会在容器云平台内外同时部署， 因此业务通信需要 平台内外网络能够直接打通， POD 与虚拟机 / 物理机同等地位，也更有利于与已有的云产品无缝整合。此外，还需要支持 Pod 固定 IP 地址：应用互访跨防火墙的等场景下，需要 POD 具备固定 IP 地址，避免 pod 重启后，运维人员频繁手动更新配置防火墙策略。还需要考虑管理网络和业务网络分离； IPV6 支持；高性能，低抖动；灵活的网络隔离：强安全性的硬件隔离和灵活的软件隔离等。

三、技术选型和厂商选型分析

银行对系统运行的可靠性和安全性要求极高，因此在建设之初需要充分考虑各类因素：

• 存量系统与增量系统的互联互通，可用性检测，以及性能保障；
• 现有系统与容器平台的对接，迁移问题；
• 稳定性、可靠性与敏捷性、分布式的平衡点；
• 行内技术人员对容器、微服务技术的接受程度；
• 当下的建设方案的可延展性，以及基于此建设的未来发展路线；
• 技术选型方面是否允许未来的扩展，是否在哪些方面会被技术绑架。

基于以上背景，我行通过组织专门团队对微服务化和容器云建设进行了深入学习，对各类容器云和微服务产品进行深度分析，对行业内相关厂商产品、技术和服务能力进行了对比，最终选定在微服务和容器云建设方面具备成熟产品、先进技术和大量实践经验的本土厂商博云来提供转型建设方案。

四、建设方案

1. 总体方案

基于以上背景，本行于去年启动了敏态分布式研发运行平台的建设。整个平台的建设范围如下图所示：

建设基于微服务架构和弹性容器云的敏态分布式研发运行管理平台，提供开发、运维、运行等多形态的应用全生命周期管理。项目整体包括弹性容器云平台、敏态分布式运行平台、敏态分布式开发平台三个部分。其中，弹性容器云平台作为敏态业务的运行底座，为敏态业务提供底层运行态的能力支撑。敏态开发平台提供了前后端的开发脚手架，辅助业务快速开发，快速上线，降本增效。敏态运行平台实现了应用的微服务治理，实现了微服务管理的统一，增强业务运行态的精细化运维能力。

在部署架构方面，是一地两中心设计，双活部署，两个数据中心上层有 F5 。两中心距离 20 公里，网络延迟 1-2ms 。主中心副中心（生产）环境集群，其中生产环境集群包含多个业务区域，如：业务一区（核心），业务二区（应用）， OA 区（办公）功能区，外联 DMZ 区等。主、副中心的多个网络区域，网络侧需要策略才可互相访问，敏态平台整体部署 如下图所示：

2. 统一架构与组件建设方案

由于目前行内很多系统的技术栈不同、产品定位不同、厂商利益不同，导致各套系统都只做了该套系统体系内的独立自治，因此基于原有组件架构是无法做到统一治理的。同时各套系统的自建设造成了资源浪费、难以运维的局面。

为了解决这个问题，实现服务治理平台化，本行设计了微服务架构与组件统一建设的方案。将微服务框架（ SpringCloud ）、注册中心（ Nacos ）、监控中心（ SkyWalking 、 Prometheus ）、配置中心（ Apollo ）统一建设。

（1）统一微服务框架建设

微服务框架需要在开发阶段做好依赖和规范，本行为了做统一的治理，将所有的开发所需要依赖的框架、配置、日志、治理等 SDK 统一封装，在微服务研发时作为标准规范引入。另外现有的微服务系统，通过两种兼容方案，一种是做轻量的 SDK 替换改造，一种是在统一管理平台中兼容其版本和组件，实现异构微服务的管理。

（2）统一注册中心建设

建设全行级统一的注册中心，考虑行内存在多个网络区域，且有主中心、副中心的多活场景，需要建设高可用的注册中心，并在每个网络区域、每个主副中心均部署注册中心的节点，通过网络策略打通，以便于数据的同步。

（3）统一监控中心建设

在主中心和副中心的多个网络区域分别部署一套 skywalking 、 prometheus ，由于外网区域没有机器就没有 Prometheus ，只部署一套 skywalking 。每个网络区域都有监控采集节点，监控数据集中存储。

（4）统一配置中心建设

在主中心、副中心的每一个网络区域中都建设一套配置中心，其中配置中心的配置管理端在主中心的某一网络区域中，所有配置中心的数据都统一存储到该网络区域下的 MariaDB 中，同时，配置管理端的数据给到敏态微服务运行平台上。

3. 微服务平台统一接入引擎方案

敏态分布式研发运行平台的管理对象是各个应用系统，因此，设计一套方案实现微服务应用和非微服务系统的快速接入至关重要。

平台需要对接的业务系统可以分为两种类型：

①存量的异构系统，包括基于 GXP 的服务、单体的业务应用

②增量的微服务化的业务系统

针对这两种类型的业务系统，本行定制了统一的接入引擎（ NSHSDK/NSHSideCar ）。对于存量的未能改造的业务系统，采用 SideCar 的方式接入平台，对原有的代码无侵入性，采用这种边车代理的方式实现该类业务系统的快速接入。对于增量的微服务化业务系统，只需在研发阶段导入 SDK 工具包，后期只需正常进行编码、测试，即可完成业务系统的上线。

4. 网关统一建设方案

本行原有的消息总线为 GXP ，伴随着业务系统的增多，监控和治理能力渐感不支。同时， GXP 原有的单点部署的方式不具备高可用，急需拿出新的方案来完成 GXP 的替换。

我们将行内下一代网关分为三类，即微服务网关、内联网关和外联网关。所有类型网关都是具有替代 ESB 能力的企业级网关。微服务网关面向传统应用，内联网关面向微服务应用，外联网关面向外联专线 DMZ 区，放在不同位置则出现不同角色。我们采用这种分布式的网关来逐步替换原有的 GXP 系统，在不同的网络区域、不同的业务区域进行了建设。

同时，因存量系统架构不统一，通信协议不统一，导致增量的微服务系统与存量的系统通信出现障碍。因此， API 网关还需要实现协议的转换、报文的转换，以及编码格式的转换，以保证服务间畅通，这一点至关重要。

5. 容器平台网络方案

通过采用博云的 BeyondFabric 网络方案，将容器管理网与应用业务进行分离，业务网络与管理网都为实际物理层面的二层网络，可以让容器的 IP 直接对外提供访问。 BeyondFabric 完全满足 CNI 协议规范，结合社区提供的工具和 kubernetes job 等网络测试套件，我们对 BeyondFabric 进行了长时间的测试，测试结果证明 BeyondFabric 具备生产可用能力。

6. 容器云技术路线方案

关于容器资源层的选择 ，在众多的容器云建设方案中，我们选择了目前最成熟、最普及的解决方案，即 docker+k8s 。

docker 容器技术有几大优势，首先是内核级的虚拟化，隔离性高，安全可靠，并且资源利用率更高。其次是 docker 打包镜像的方式是将应用及应用运行所需的依赖进行打包，使得镜像极其轻量，能够快速部署，快速启停，快速扩容缩容，天生具备开发运维一体化的特性。

K8s 是开源的容器编排调度引擎，用于容器的编排和自动部署，实现对容器批量调度，在谷歌内部经历了多年的平稳运行，并且拥有壮大的开源技术社区。但随着 k8s 与 docker 的解绑，后续的维护成本也是要考虑的痛点及难点之一。

四、价值收益

1. 完整闭环的能力支撑

为敏态应用提供完整闭环的能力支撑，从项目的创建管理 → 资源准备 → 依托开发框架快速研发 → 利用运维平台实现发布管理 → 利用运行平台对服务运行态进行监控治理 → 通过开放银行将业务能力提供给外部服务。为行内基于云原生的数字化转型奠定了基础，真正的迈出了数字化转型的第一步，解决了微服务建设难以下手、不明方向的问题，为行内敏态未来指明了方向。

2. 微服务学习成本降低

分布式架构的学习需要较大的成本，博云提供的脚手架能力，规避了这个问题。在开发过程中，脚手架的使用让研发人员只关注业务代码的程序编写，提高了研发效率；在统一管理方面，脚手架对微服务架构的推广、微服务系统的接入，提供了标准和便利。

3. 新老系统共存，替换现有的 GXP

通过内联网关、外联网关、微服务网关的建设，保证了跨网络区域下，不同类型应用之间的通讯问题，解决了新型网关和传统 ESB 落地过程中的过渡与结合的问题。同时，微服务和 API 网关的治理功能，也解决了由于通信流量过大而引起的服务不可用、故障频发，保证了服务运行的健康问题。

4. 架构建设统一

架构的统一建设，减少了组件重复建设造成的资源浪费，减轻了运维人员的压力，有利于行级统一的微服务管理平台集中管理了不同网络区域下不同架构独立自治的微服务体系。

5. 管理平台统一

依据行内集中管理的监管要求，博云提供的统一管理平台建设，避免了多个管理平台切换跳转的复杂操作，以此降低了客户的管理成本。

五、未来规划，下一步建设方案

本行的敏态分布式研发运行平台是基于云原生技术构建的完整闭环的 PaaS 层能力平台。本次主要分享了平台建设相关的实践经验，后期将从以下方面来持续完善和扩展平台能力。

1. 增强异构应用的发布能力，做到微服务应用的统一编排部署，支持不同环境下制品库间的流转和配置扭转，做到业务部署发布的规范化，保障部署的稳定性，提高业务部署上线的效率。
2. 通过敏态分布式研发运行管理平台来打通需求、开发、测试、部署和运营等多环节之间的壁垒，以适应敏态业务迫切需要的高效率、高质量的交付的要求。实现敏捷开发、持续交付和应用运营的无缝集成。能够有效地提升公司 IT 效能，在保证稳定的同时，快速交付高质量的软件及服务，灵活应对快速变化的业务需求和市场环境。
3. 提高对于敏态应用监控运维的能力。当前的敏态平台对于监控运维的能力还不够强大，后期考虑支持多种视图查看服务的调用过程，支持从服务的视角搜索和查看日志，支持查看不同业务域和系统间的拓扑图。以增强敏态平台在监控运维侧的能力。
4. 在云原生架构下，为实现各层面的互操作性，组件 / 功能模块之间必须具备开放性，带来组件交互的开放性安全风险，传统防护手段已经失效，纵观容器的生命周期，容器存在的三个形态为：模板、镜像和容器。应用容器是由模版文件先进行编译成镜像，镜像通过运行变成容器，最终容器方式运行其中的应用。在整个容器的安全生命周期中，应通过采用自动检测、自动分析、自动处理的方式来防御整个容器生命周期中所遇到的安全威胁。在防护技术上使用到智能检测、机器学习与威胁预测等先进的方法来确保容器及容器内应用安全。

最终利用敏态分布式研发运行平台，完成 PAAS 技术中台与业务场景深度融合，实现我行业务的数字化转型。