来源：2022第三届中小金融机构数智化转型优秀案例评选
获奖单位：西南证券
荣获奖项：
专家好评TOP10优秀案例奖
一、项目方案
1.系统设计思想
线上业务在打破物理时空屏障的同时，提升了工作效率，降低了成本，因此线上业务系统的建设使用逐步取代了传统的现场业务办理的方式。随着线上业务的发展，系统功能及访问量的增加，单体应用架构已不能满足企业发展的需要，特别是在建立统一的客户应用场景、代码复杂度、发布方式、可靠性、扩展能力、可维护性方面存在较多问题。
为了更好的支持APP的部分功能以及开户、大规模营销活动等对系统大并发、稳定性要求比较高的功能，本项目搭建了符合最佳实践的微服务架构，建立了适合的开发、运维管理流程。打造了一个技术中台系统作为公司级能力复用平台，起到支撑和链接的作用，为各类前台如PC，APP，H5等提供功能，与后台各类交易系统进行链接，为客户提供各类除实时交易类以外的服务，并在不同的客户端提供统一的视图。该项目的实施更利于业务的沉淀，降低研发成本，提高研发效率，打破不同产品之间壁垒，实现了“大中台，小前台”的整体架构。
2.系统整体架构
云原生线上业务中台系统采用k8s+微服务的基本框架，如图1所示，系统设计为五层次的系统架构，同时各个层次的组件可以根据实际需要灵活配置和部署。五层体系包括：
①基础设施层。该层主要为云服务运行环境以及相应的第三方依赖。
②平台服务层。该层为经过抽象的服务，这些服务可以实现高度的复用，减少重复构建应用的成本。
③业务层。该层为具体的业务流程处理层，基高度依赖于平台服务层，通过对平台服务层的服务进行整合、组装，达到快速对业务响应的目的。
④网关层。该层也为接入层，外部请求对内部的所有访问都必须经过该层进行安全校验、鉴权、统一日志打印等。
⑤展示层。该层为客户或者操作员提供可视化的操作界面，同时通过友好的接口定义和分离设计实现与后端业务层的解耦。
图 1. 云原生线上业务中台应用系统的五层架构体系
3.技术实施方案
线上业务中台主要利用云原生的技术体系，从微服务治理、容器化改造、DevOps赋能三个方面设计了整体的技术改造方案。主要采用社区中成熟的开源框架，持续改进信息技术架构。
3.1 微服务治理方案
利用Spring Cloud实现微服务架构整体改造，它为微服务架构中涉及的服务治理、断路器、负载均衡、配置管理、控制总线和集群状态管理等操作提供了一种简单的开发方式。
微服务是系统架构上的一种设计风格，它的主旨是将一个原本独立的系统拆分成多个小型服务，这些小型服务都在各自独立的进程中运行，服务之间通过基于HTTP的RESTful API进行通信协作。被拆分成的每一个小型服务都围绕着系统中的某一项或一些耦合度较高的业务功能进行构建，并且每个服务都维护着自身的数据存储、业务开发、自动化测试案例以及独立部署机制。通过轻量级的通信协作基础，可以使用不同的语言来编写。
1)技术框架选型
为了更好实现对技术架构的自主掌控，减少对外部供应商的依赖，在开源框架的选取上，主要遵从三个主要原则：
开源框架背后支持的厂商
一线大厂支持的开源框架，技术都在实际的产品中实践过较长时间，不管从技术成熟度、迭代升级、应用稳定性都有比较高的表现。近几年国内的厂商逐渐开始拥抱开源，国内一线大厂的开源产品更加适合国内的互联网生态。
社区活跃度
社区活跃度越高，解决问题的速度越快，框架也逐渐完善。当出现问题时，能够快速在社区找到相应的答案。
框架特性是否契合业务发展需求
目前不少开源框架的应用场景类似，具体的选型，需要根据业务场景的需求做必选。一般会从网络吞吐需求、高可用需求、复杂程度、安全性和与其他框架之间的兼容性做考虑。
目前主流的微服务框架有Spring Cloud、Dubbo和HSF。Spring Cloud是基于REST的协议进行通讯，而Dubbo和HSF则是通过RPC的协议进行通讯。
Spring Cloud项目是一个更高层次的、架构视角的综合性大型项目，其目标旨在构建一套标准化的微服务解决方案，让架构师、开发者在使用微服务理念构建应用系统的时候，面对各个环节的问题都可以找到相应的组件来处理。这可以有效减少在组件的选型和整合上花费的精力，可以快速构建起基础的微服务架构系统。同时，由于Spring社区的活跃度，市场上很容易找到有相关经验的开发人员，能极大的减少对人员的依赖，因此最终选择Spring Cloud作为微服务架构改进的基础框架。
2)技术架构
现有微服务架构是基于开源Spring Cloud架构搭建的，架构中多数组件基本采用了Spring Cloud提供或推荐的组件,如图2所示。
服务网关采用了Spring Cloud生态中的Spring Cloud Gateway，为架构提供了简单有效的统一API路由管理方案，并基于Filter链方式扩展了网关的基本功能，如认证、监控、限流、熔断等。
JWT用于存储在外部请求中的用户签名信息，保证传输过程安全性。其位于服务网关中，由用户认证微服务应用派发返回，避免每次请求的身份验证，从而降低服务器负载。
注册与配置中心采用了Spring Cloud Alibaba项目中的Nacos，用于构建应用的动态服务发现、配置管理和服务管理平台。
限流和熔断采用了Spring Cloud Alibaba项目中的Sentinel，包括流控制，并发限制，熔断和自适应系统保护，以确保微服务的可靠性。
性能监控和链路跟踪采用了Apache基金会下的SkyWalking，自动收集所需的指标，并进行分布式追踪。通过这些调用链路以及指标，感知应用间关系和服务间关系，并进行相应的指标统计。
图 2 微服务架构选型
3.2 容器云平台
容器云平台核心采用具有高可靠性的Kubernetes框架。如图3所示，在资源架构方面打通虚拟机、物理机和容器；在业务架构方面支持微服务构建独立的业务平台系统，解决应用之间的耦合关系；在部署架构方面，容器云平台运行在企业内部核心域，外部通过代理服务器访问，增强了安全性。
图3 容器云平台整体架构
容器云平台以容器为单元，提供了全新的应用发布方式，为应用开发者带来环境一致性，基于容器镜像的应用发布流程不仅能覆盖整个应用周期，还减少了传统云平台对应用架构、支持的软件环境服务等方面的限制，容器云平台给用户提供了极大的开发运维自由度。
容器云平台从底层IaaS层构建虚拟资源池，以容器为资源单元，在容器云平台内部架设管理架构，编排和管理容器单元。容器云平台还创建了一个容器云运维门户，隐藏了底层逻辑，方便用户使用。用户只要明白简单业务逻辑，即可在容器云平台完成开发、创建、部署、管理和运维等全生命周期操作。
1）总体方案
基于Kubernetes原生的解决方案。平台集成弹性计算、分布式存储、软件定义网络、镜像级漏洞扫描和图形化云运维UI等核心技术，同时满足适配原有的业务、应用、网络及存储原型。
2）方案拓扑图
图4 方案拓扑图
3）平台组件架构
图5 容器云平台组件架构
3.3 开发运维一体化
1） 总体方案
根据DevOps赋能的需求，基于Kubernetes+Docker云原生的解决方案集成DevOps工具链。
DevOps集成方案包含代码管理方案、依赖管理方案、配置文件管理方案、持续集成方案、持续部署方案、自动化测试方案、研发度量方案、DevOps集成方案及IT治理建议方案。
通过端到端打通代码版本库管理工具、自动化构建工具、代码扫描工具、自动化测试工具、自动化部署工具及开发者“沙箱”等，从而实现应用全生命周期的功能，如图6所示。从而达到敏捷开发团队可以快速交付应用，提升业务价值的目的。
图 6 开发运维一体化生命周期
2）技术架构
持续集成：是一种软件开发实践，即团队开发成员经常集成它们的工作，通过每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建来验证，从而尽早地发现集成错误。主要包括以下步骤:
①开发者向gitlab 提交代码。
②gitlab 通过webhook通知Jenkins有更新。
③Jenkins 从代码库下拉最新代码、dockerfile 以及其他文档。
④Jenkins 在 Slave 节点构建 Docker 镜像，实例化并且执行。
⑤若是测试通过，Jenkins 会把镜像推送到镜像库。
持续交付：是通过自动化的构建、测试和部署循环来快速交付高质量的产品。
CICD构建独立于系统节点与业务节点，集群中有特定的构建节点执行构建操作，防止构建对系统组件或应用造成影响。
3）代码管理方案
代码管理采用开源代码版本管理工具Gitlab，与Github类似，GitLab能够浏览源代码，管理缺陷和注释。可以管理团队对仓库的访问，它非常易于浏览提交过的版本并提供一个文件历史库。它还提供一个代码片段收集功能可以轻松实现代码复用，便于日后有需要的时候进行查找。
4）依赖管理方案
Maven是一个项目管理和综合工具。Maven提供了开发人员构建一个完整的生命周期框架。开发团队可以自动完成项目的基础工具建设，Maven使用标准的目录结构和默认构建生命周期。考虑安全问题、考虑网络问题、考虑控制问题、考虑版本统一问题等，且项目都是在公司内网进行开发，于是创建一个公司专属的Repository，然后所有Java项目都专属的Repository交互，包括下载依赖、下载插件、编译构建等，既节省了网络带宽也会加速项目搭建的进程和项目的统一管理。
本次专属的Repository使用的是Nexus Repository OSS。
5）持续集成方案
采用了Jenkins作为本项目的持续集成工具。Jenkins是一个开源软件项目，旨在提供一个开放易用可扩展性强的持续集成平台。通过对Jenkins软件进行Docker容器化封装，并部署到容器平台。
二、创新点
1. 服务组件化
构建标准化的组件，实现模块化开发，研发转向微服务框架；代码标准化，减少人为配置。
2. 开发运维一体化
资源使用情况可视化；业务可视化，业务状态、资源占用、性能指标可视化；面向具体场景的智能化预测，针对资源使用、故障发生等方 面的预测，以及进一步的智能化辅助决策和处置。
3. 去中心化治理
服务共用一个最小型的集中式的管理，针对不同业务选择不同的技术平台，服务可用不同的语言开发，也可以使用不同的数据存储技术。
4.基础设施自动化
一键申请、自动归还资源；一键部署，覆盖全环境；资源自动化监控、资源占用自动感知、网络状态自动感知、应用状态自动感知。
5.开发运维流程标准化
人员可视化，开发和运维人员的效率、质量、进度可视化；建立符合实际情况的开发流程和开发规范，并提供支持工具，如需求管理，代码检查工具，测试管理，发布管理，流程检查工具，持续集成工具等。
三、技术实现特点
云原生线上业务中台承载了开户、网厅、金融商城的所有业务，这对系统的稳定性、高可用性有很高的要求，对系统架构、应用设计和运维管理等提出很高的挑战。以下就实现的关键技术要点进行分析和总结：
1.统一性
云原生线上业务中台应用模块众多，应用系统的数据量、日志等分散、庞大，因此系统需要具有高度的统一性才能实现有效管理和高效运维。具体来说，统一性主要体现在：
①统一限流。当请求超过系统的最大业务承载量时，通过网关进行统一限流阻断超过限流标准的流量，防止将系统击跨，同时给用户友好的提示。
②统一网关。所有的外部请求都需要经过统一网关访问应用，在网关上需要指定分发路由，只有满足要求的请求路径才会分发到系统，同时，对系统的参数、鉴权等实现初步验证，将无效的请求拦截在系统之外，提高系统的安全性和健壮性。
③统一资源管理。将所有的主机资源加入到集群中，组成为资源池，并对资源池中的资源进行逻辑划分以实现可以按需分配给不同的项目，实现资源的统一分配、复用，提高资源利用率。
④统一配置中心。通过统一的配置中心，将配置进行集中存储，并且将程序实现的配置文件进行隔离，很好的实现了程序的可迁移性。同时，当对配置进行修改时，通过实时的推送机制将修改的配置推送到应用中，实现修改配置后不需要重启应用，提高运行维护效率。
⑤统一日志查询。通过构建统一的日志采集、分类、清洗、存储、查询机制，实现云原生线上业务中台整个业务系统的日志快速查询，提高系统分析、故障定位的机制。
⑥统一平台入口。通过云原生线上业务中台系统以及云平台的建设，将开户系统、网上营业厅系统、金融商城系统集中到一个系统中进行统一的发布、运行，减少了开发、运维的工作量，提高了效率。
⑦统一运行环境。所有的应用都通过容器运行，通过对制作容器的基础镜像进行统一，从而实现测试、生产等环境中容器应用的运行环境保持一致，屏蔽了环境对应用的影响，提高程序的迁移性，彻底解决因为运行环境不一致导致的各种故障。
2.复用性
通过对各个业务系统中的公共服务抽取，组建基础服务作为底层服务为各个业务系统提供服务。由于云原生线上业务中台所涉及到的业务流程中对这些基础服务的需求非常普遍，所以通过构建基础服务大大提高服务利用效率，提高可维护性，大幅减少对需求的响应时间，降低服务建设成本。
3.智能性
线上业务中台的智能性主要体现在以下方面：
①自动负载均衡。服务模块采用容器集群的方式对外提供服务，自动实现容器集群内部的负载均衡。
②自动扩容、缩容。系统的请求流量并不是固定不变，在业务高峰时请求流量会增加，在业务低谷时请求流量会大幅减少，同时，随着促销活动的开展，流量可能会相比较于平时流量成倍增加，因此，如何在硬件投入与实际性能需要间取得平衡成为一个重要的问题。云原生线上业务中台系统支持手工、自动扩容和缩容。例如，在促销活动开始前，手工对应用处理节点进行扩容，提高系统处理能力，当活动结束后，手工缩容释放系统资源。同时，对于高峰时的突发流量，系统也通过配置指定阀值，当超过阀值时自动对处理节点进行扩容，流量降低后自动缩容以释放资源。
③自动告警。统提供对资源占用、服务请求量、网络流量等进行实时监控，可以配置相应的阀值，当指标超过阀值时进行邮件、短信等告警，实现对问题的快速发现。
4.用户友好性
系统支持基于容器实例的灰度更新实现无感升级。在更新时，先更新一个容器实例，当该实例已经更新完成并且成功对外提供服务时，再更新其它实例，以此实现在整个更新过程中容器集群都能正常处理客户的请求，用户感知不到系统正在升级，从而达到无感升级的目的。
四、项目过程管理
云原生线上业务中台项目由西南证券金融科技部牵头和实施。云原生线上业务中台项目的实施配合微服务平台容器化改造实施的计划，采用试运行到全切换分阶段的方式。主要经历以下几个阶段。
1.需求分析和设计阶段
此阶段时间段为2019年9月至2019年11月，其间主要完成了需求分析、云原生技术架构设计、云原生服务容器化改造方案设计和开发运维一体化流程设计。
2.私有云平台开发实施阶段
此阶段时间段为2019年12月至2020年6月，其间主要完成了云原生平台的开发、测试和部署的工作。以及DevOps开发运维一体化工具链的搭建。
3.云原生服务容器化改造阶段
此阶段时间段为2020年6月至2020年7月，其间主要完成了基于云原生技术架构的业务微服务容器化改造和技术上线准备工作。
4.云原生线上业务技术上线阶段
此阶段时间段为2020年7月至2020年9月，其间主要完成了云原生线上业务中台的业务系统的技术上线，并监控各个系统的运行情况，为试运行做准备工作。
5.试运行阶段
此阶段时间段为2020年9月至2021年2月，其间主要完成了云原生线上业务系统试运行工作，切换了20%的流量到云原生线上业务中台，并监控各个系统的运行情况。
6.运行阶段
此阶段时间段为2021年2月至今，其间主要完成了云原生线上业务中台完全接管所有业务请求的流量。业务系统稳定运行，各项线上业务有序开展，项目如期完成。
五、运营情况
1.系统总体运行情况
基于微服务架构的线上业务中台的业务系统于2020年7月技术上线，并通过试运行于2021年2月完全接管所有业务请求的流量。目前已顺利上线多套业务系统、34个服务和62个运行实例，接口调用次数日峰值每分钟超过1万次。从系统上线以来运行情况来看，各项线上业务有序开展，系统运行稳定，性能良好，各项指标均已达到原来的设计目标。该系统基于中台特性，支持7*24小时交易，突破了证券交易时间的限制。同时极大的提高了需求响应速度，持续进行快速的版本迭代，进一步优化了业务流程，提升了用户体验。
2.系统各组件运行情况
线上业务中台提供的网上营业厅、网上开户等组件，运行稳定，功能丰富，全面覆盖公司现有线上业务，包括证券账户新开和下挂、三方存管、创业板权限开通、科创板权限开通、资料修改等，有效支撑了经纪业务的开展。基于中台实现的活体检测、人脸识别等组件，已经运用于单向视频开户和网上营业厅，极大的提升了审核效率，增加了客户满意度，增强了产品竞争力。
线上业务中台提供的金融商城、定投组件，运行性能良好，功能完善，产品体系全面覆盖公司自有产品和代销产品，包括公募基金、银行理财、收益凭证、资管、信托、私募基金等，有效支撑了财富管理业务的开展。其中基于中台支持的收益凭证业务的开展，提供了固定收益凭证、浮动收益凭证16个系列的产品展示和销售服务。基于中台实现的定投组件，突破了原有柜台定投周期单一、扩展性弱的不足，为用户提供了灵活的定投周期，并且支持扩展；提供了完善的多重重试机制，保障用户定投成功率。
线上业务中台提供的报价回购组件，运行稳定，通过产品化的设计，为用户提供了优秀的用户体验，用户满意度极高。基于云原生线上业务中台快速的需求响应速度，在短时间内完成了报价回购业务涉及的权限开通、产品购买、产品提前购回、产品预约提前购回、产品展期设置、产品扫单权限开通/关闭、产品留存金额设置等功能，保障了业务的顺利开展。
3.系统运行性能情况
3.1 资源占用
相比于传统的在服务器上直接运行应用程序的部署方式，基于容器的K8S平台将所有的工作主机纳入了统一资源池中进行统一管理，高度实现了资源复用和灵活分配，并且可以对资源池中的资源进行统一的监控。系统资源主要分为：CPU资源、内存资源、网络上传与下载资源、磁盘存储等资源。其中CPU资源和内存资源为关键资源，对系统的性能影响较大。网络上传与下载主要依赖于运营商出入口的带宽，磁盘存储资源可以通过共享存储实现存储的灵活分配，这里主要分析CPU资源和内存资源对系统的性能和容量的影响。
图7 云原生线上业务中台应用系统整体资源情况
图8 云原生线上业务中台应用系统最近24小时CPU占用情况
CPU资源占用随工作时间呈规律性变化，忙时主要分布在工作日的9点30分-10点30分、13点到15点，即使是忙时，CPU所占资源也仅占分配的资源的50%左右，同时目前所有应用的CPU占用数量仅占整体CPU数量的7.2%。
图9 云原生线上业务中台最近24小时内存占用情况
内存资源占用相对稳定，主要是因为容器启动后即对内存进行了分配，运行期间内存基本保持不变。通过对每个容器所占用的内存进行观察和监控，没有容器出现内存占用超过90%的情况出现，同时，目前已分配的所有内存占整体内存的20.5%左右。
通过上述分析可以看出，对比各阶段上线前的资源占用情况，资源占用率大幅下降，相同的主机资源可以部署更多的应用。
3.2 性能分析
通过平台的监控页面可以对系统当前的性能进行可视化监控，同时也可以配置相应的监控告警规则，达到一定阀值时通过邮件、短信告警等方式通知相应的责任人。
图10 云原生线上业务中台业务忙时响应时间分布
从监控平台可以看到，在业务忙时采样的这段时间，系统50%的请求在10毫秒内完成，75%的请求在50毫秒内完成，90%的请求在260毫秒内完成，95%的请求在740毫秒内完成，99%的请求在1.63毫秒内完成。通过对超过1秒完成的请求进行采样分析，确定这些请求需要访问第三系统占用了较长时间。
图11 云原生线上业务中台业务忙时CPM分布
从监控平台可以看到，在业务忙时采样的这段时间系统CPM最高为t2网关系统，约3699CPM，转换为QPS约600，其次是网关、网上营业厅等系统，在当前的业务场景下，系统资源占用合理，系统稳定运行。
六、项目成效
1.经济效益
云原生线上业务中台的建设提高了开发效率，加快了业务响应速度，缩短了业务功能上线时间，促进了业务开展，为公司抢占市场份额赢得了先机。用户越早参与新业务，创造的业务价值和经济价值也随之增加。开发效率的提升，潜在的提升了开发人员的人均产出，在同等的人力成本和时间成本下，为公司贡献了更多的产出物，创造了更多的价值。
云原生线上业务中台基础设置自动化的特性，实现了资源的动态申请，动态扩容，能够根据业务压力情况，动态进行扩缩容，提升了硬件服务器资源的利用率，降低硬件购置成本。
云原生线上业务中台开发运维一体化的特性，能够实现业务组件监控的可视化，面向具体场景的智能化预测，针对资源使用、故障发生等方面的预测，以及进一步的智能化辅助决策和处置。该特性能提高系统的稳定性，降低生产事故的发生概率，当事故出现时，也能及时发现和处理，降低事故带来的损失。
2.社会效益
云原生线上业务中台能够提升开发效率，快速将合适的优秀的业务功能或者服务提供给客户，满足客户的投融资需求，帮助客户进行财富管理，提升客户投资的幸福感。同时，云原生线上业务中台对系统稳定性的保证，也能让客户对公司产生信赖，提高客户对公司的满意度。用户体验和满意度的提升，有助于公司品牌形象的树立，吸引并服务更多的客户，结合投资者教育，帮助更多的投资者进行理财投资和财富管理。
七、经验总结
整个项目大致可分为技术选型阶段、建设实施阶段和推广应用三个阶段。
在技术选型阶段，采取积极调研、拥抱开源的策略。通过结合公司数字化转型规划、业务实际需求和现有架构情况进行综合分析，确定了利用云原生的技术体系，从微服务治理、容器化编排、开发运维一体化DevOps赋能三个方面进行整体的技术改造的方案。围绕着“打造高可用私有化平台”和“建立开发运维一体化”两个主要目标，调研各种技术方案的可行性。主要考虑采用云原生社区中成熟的开源框架，这样一方面可以降低对于外部供应商的依赖，更好实现对技术架构的自主掌控；另一方面，国内一线互联网大厂的开源产品技术成熟度更高、迭代升级更快、应用稳定性更好，出现问题也可以及时从开源社区寻找到答案。另外，还需要根据业务场景的需求做必选。一般会从网络吞吐需求、高可用需求、复杂程度、安全性和与其他框架之间的兼容性做考虑。
在建设实施阶段，采取逐步迁移、持续完善的策略。云原生线上业务中台项目从2019年10月开始启动，从探索性功能线上销户业务开始，完成了主体框架的选型。随后完成了金融商城、网上营业厅、营销活动，报价回购、账户分析、历史交易查询、电子签平台、定投等业务的迁移，在迁移过程中，同时对整体架构逐步进行完善。通过业务迁移与架构完善相互结合，共同促进的方式，提高了线上业务中台建设的效率，降低了成本。
在推广应用阶段，采取试运行到全切换分阶段进行的策略。2021年2月，云原生线上业务中台开始生产试运行，并引入DevOps工具链。由于DevOps工具链的引入和原生云平台的生产上线，解决了以前需要手工进行生产发布运维的问题，极大的提高了发布的效率，同时保证了生产和测试验证环境的完全一致，极大的减少了生产验证的时间，对于生产出现的问题，可以通过统一的日志平台进行查询，极大的减少了处理问题的时间。同时，生产的稳定性也进一步得到了保证。通过逐步扩大线上业务的范围，形成统一的线上业务中台，同时结合实际情况，完善开发流程和开发规范，通过这种方式，有效的降低了生产风险，最终实现“大中台，小前台”的整体架构和统一的研发制度。
通过线上业务中台项目实施，利用云原生的技术体系，对现有的服务进行整体技术改造，建立健全公司自主研发体系架构。对业务系统解决业务快速变化问题、对安全稳定运行保障业务持续开展起到关键作用。
更多金融科技案例和金融数据智能优秀解决方案，请登录数字金融创新知识服务平台-金科创新社官网案例库、选型库查看。
