一、项目背景及目标

当今的应用程序开发和IT系统管理都由云驱动，通过与基础设施深度整合优化，将计算、存储、网络资源管理以及相应的自动化部署能力交由云基础设施执行，应用自身变得更为灵活。将大型服务器虚拟化成较小的虚拟机，按需要扩容，充分利用机器计算资源，降低管理成本。相比于传统架构，云原生架构强调业务研发应充分利用云平台提供的IaaS和PaaS能力，处理分布式环境下复杂的非功能性问题，如分布式存储、弹性伸缩、流量管理等。云原生作为新一代的应用开发和运维范式，正在逐步改变企业的IT架构和业务模式。

随着业务规模上升，微服务应用也逐渐成为苏州银行未来系统建设的发展趋势，在信创云、VMWARE等环境中迫切需要更高质量的协同能力。同时，厂商也逐渐往微服务应用转型，但往往自成体系，行内虽具备统一的ESB治理，但缺少统一的微服务治理，因此在引入后造成资源浪费和管理不便。在此背景下，我行探索实施智能微服务平台，统筹IT应用交易线架构规划和网络规划，旨在统一服务目录和服务总线，避免未来信息系统建设混乱，降低系统间的服务访问复杂度，使未来苏州银行数字化转型更加高效。

二、创新点

智能微服务平台包括管理平台、注册中心、配置中心、监控中心、应用控制台、通讯协议SDK在内的多个组件，在内部采用命名空间逻辑隔离各个环境的服务和配置，采用业务域（对应网络大区）和网络区（对应网络小区）逻辑管理各个应用节点。其创新主要体现在以下方面：

（1）便捷化服务管理

通过管理平台管理注册中心，屏蔽了单独操作注册中心的操作复杂性和危险性，提高了对于服务、订阅、方法等数据的管理便捷度。服务信息用于登记应用提供的服务元数据、服务地址，支持方法实例上下线；订阅信息用于登记应用消费的服务和方法，支持超时时间配置。所有的配置和修改可在管理平台完成，按照不同命名空间生效，有效隔离各个环境中不同动态的服务数据。应用只需集成平台提供的SDK就可以完成服务纳管，形成服务、订阅资产。

（2）安全化服务调用

SDK提供了一份SSF协议定义整个服务调用，内部采用本地缓存机制，将管理平台下发的服务信息等数据缓存在应用本地，点对点发起服务调用，即使注册中心出现故障，依赖于本地缓存仍可以保障现有服务的可发现，确保调用无报错。SDK还统一定义了整个寻址过程，包括服务鉴权、灰度、熔断、限流、降级、负载均衡、链路追踪、推空保护、通讯重试、无损下线、同机房路由优先等多种管理和保障机制，其中熔断、限流、降级最大支持到方法级别，且实时生效。在负载均衡方面，SDK提供随机、加权、循环、繁忙等软负载算法，支持扩展策略，即应用系统可自行定义，进行负载均衡算法的管控。通讯层支持普通调用和泛化调用两种调用方式，通讯协议采用谷歌最新的gRPC协议，更加稳定高效。

（3）自动化应用部署

应用控制台承接了应用管理态、部署态到运行态的完整生命周期，支持寻址算法、服务端口、健康探测、JVM设置。在管理态提供机器纳管、应用创建、应用分组、应用扩容等功能；在部署态提供自动化部署、无损起停，灰度发布等能力，对接了国产信创的tongWeb、BES、apachetomcat多种中间件部署方式，兼容应用部署在任意云平台；在运行态登记应用实例信息，提供实例上下线、配置管理和下发、流量控制、应用监控等能力。

（4）全链路化监控

平台内部的监控组件解决了大规模微服务集群难以监控的问题，在服务调用出现问题时，及时产生相应告警，通过内部的全区流水号快速定位故障交易，交易链路信息则包括了应用的每笔交易信息、交易状态、处理时长、处理节点。在产生告警时，又可以设置灵活的告警规则统计出应用交易的超时笔数、交易的失败笔数、交易成功率等信息。此外，监控组件还提供了丰富的机器监控和JVM监控功能，包括fullGc、CPU、内存、负载、磁盘、网络流量等数据。

三、项目技术方案

（1）服务双注册与双订阅

注册中心采用了nacos和zk双中心容灾设计，当一中心集群因节点异常下线或产生网络分区等原因，无法对外提供服务时，由另一中心保障新服务的注册与订阅。Nacos用于存放注册服务和治理参数信息，通过Nacos同步复制保证集群内服务信息一致。静态数据采用CP算法保持一致性，动态数据采用AP算法保证可用性。Zookeeper用于存放注册服务和治理参数信息，采用3台以上（奇数）集群部署，通过ZK同步复制保证集群内服务信息一致。应用作为提供方同时完成Nacos和ZK的服务注册。应用作为消费方同时同步Nacos和ZK的静态数据（应用信息、服务信息、流控规则等）和动态数据（应用地址、服务地址）。

（2）无损上下线

为避免服务提供者中某个实例在下线时主动在注册中心中注销的服务实例状态无法实时被上游消费者感知到，从而导致调用已下线实例的问题。在接收到下线命令即将下线前，提供者对于在等待下线阶段内收到的请求，在其返回值中都增加特殊标记。让服务消费者接收到返回值并识别到相关标志后主动拉取一次注册中心服务实例，从而实时感知提供方实例最新状态，达到服务提供者的下线状态能够被服务消费者实时感知的目的。

无损上线在应用部署时执行，判断应用就绪后进行服务正式对外。通过探测手段检查应用实例是否准备就绪，提供小流量对刚上线应用实例进行预热，保护刚启动的应用实例。

（3）推空保护

应用正常停止会将该实例状态改为下线。然而当应用宕机或发生网络故障时，心跳全部丢失，注册中心会将该实例删除，当该应用所有实例都删除时，会开启推空保护机制。该机制保障了在极端情况下应用不会因找不到可用实例而产生交易风险。

（4）限流降级

限流：通过调节不同消费方流量阈值来控制通过提供方系统的最大流量值，保证系统安全可靠运行。支持按照应用、应用分组、服务、方法多个级别设置。

降级：降级通常用于对下游出现超时的非核心服务提供者进行低优先级调用，确保上游核心应用（服务消费者）不被影响。支持按照应用、服务、方法多个级别设置。

（5）服务治理

统一服务元数据：定义一套适用全行系统共用的元数据，包括：系统元数据、应用元数据、服务元数据、方法元数据、流控元数据等。

统一调用协议：内部采用google最新推出的gRPC协议和自主设计的寻址算法，封装成行内统一的SSF协议。

统一流量控制：采用自主设计的流控算法，包括：灰度、限流、熔断、降级，支持到应用级、应用分组级、服务级、方法级。

统一接口治理：参考ESB模式治理方式，引入接口治理和鉴权，保障接口的规范性、安全性，提高对接口的管理能力。

四、项目过程管理

为确保项目按计划上线，整体实施过程严格按照苏州银行项目管理办法相关要求开展，主要包括以下工作阶段：

（1）需求分析及评审

分析对比与EDAS、SOFA、TSF、Kubernetes、SpringCloud等多个方案的优劣，如应用打包、服务框架、发布和调度、弹性伸缩、进程隔离、环境管理、服务治理等方面。另外也对其他银行的架构现状和产品进行调研，开展相关同业交流，确定实施的内容和范围，形成会议纪要和需求初稿。在项目初期识别项目相关方，分析记录参与度、相互依赖性、影响力等，与相关方沟通确认需求并组织评审。

（2）计划制定与开发

分别制定项目里程碑、需求管理计划、开发计划、质量管理计划，根据需求和计划创建WBS，进入设计开发阶段。

（3）系统测试及验收

进行相应的SIT测试、UAT测试、高可用测试、容灾测试、性能测试、破坏性测试、稳定性测试验证平台功能。

（4）项目上线及推广

2023年6月“智能微服务平台（SSF）”正式上线，并进行试运行期间功能验证，根据验证清单检查相关功能，2023年8月顺利接入统一消息平台，2023年10月接入身份核查系统，2023年11月接入中间业务系统，2024年5月接入营销平台。

五、运营情况

目前线上对接了中间业务、身份核查、消息平台、营销平台四个系统，涉及的应用数量分别是：3个、1个、4个、2个，服务数量分别是：9个、8个、36个、10个，接口数量分别是： 43个、43个、87个、47个。身份核查、消息平台的近7日调用总次数分别为1054431笔和18895165笔，单日调用次数分别为218437笔和2305516笔。上线以来配置的三个监控规则产生的告警数量分别为：系统间5分钟超时监控6条、磁盘监控49条、应用健康检查告警56条。总体运行情况稳定。

六、项目成效

智能微服务平台的建设促进了苏州银行在分布式架构、云原生应用领域的科学研究，显著提升了苏州银行开发、应用部署、应用监控、应用运维能力。新的系统使异构应用也可以使用微服务调用，无需再依赖ESB，避免了单点问题，使苏州银行的云原生应用进一步扩展到信创云和vmware，并可以按照行内网络架构进行灵活部署。采用微服务架构的各个新系统也无需再依赖于自带的注册中心和配置中心，减少了重复建设成本。在项目推广过程中，有助于提升苏州银行对于云计算平台的自主掌控水平，提升企业科技创新能力。

七、经验总结

在项目建设前期，我行组织了多次方案选型调研、POC论证推演，论证了其实现难度、周期、价值，并选用瀑布型项目模式，进行了项目可行性分析、成本估算、范围估算。选派行内有相关领域经验的部门经理、项目经理、研发人员、测试经理参与到项目的架构设计、开发、测试中，在项目过程中，分别于项目多个阶段进行高层汇报决策，完成整个项目的实施和推广计划制定。并与行内的其他应用领域专家合作，弥补了项目短板，为项目争取到了更多的实践和验证机会，为平稳推广奠定了基础。