Application
支信证券服务化平台实践
文II安信证券股份有限公司信息技术中心段苏隆周巍沙烈宝李银鹰
建设之初的思考
互联网应用的海量用户、快速迭代、不间断服务和流量突增等业务特征促进其技术架构从传统集中式到分布式SOA和微服务架构方向演进。当前，以Docker、Kubernetes和服务网格等为代表的云原生技术进一步促进微服务的发展，解决了标准化交付、自动化调度和无侵入式服务治理等复杂问题。
在工程实践方面，诞生了一系列基础框架、工具组件和基础平台支撐微服务的敏捷迭代和服务治理等特性，如Apache 开源的Spring Cloud、Dubbo等框架；在同行业中，有东方证券开源的微服务治理框架gRPC-Nebula、国信证券开源的Zebra微服务框架和恒生闭源JRES3.0分布式服务开发平台等，这些框架通过嵌入SDK的方式实现如服务注册与发现、负载均衡等服务治理功能。同时，也有新一代如服务网格的无侵入式方案，通过对服务间的通信进行代理，能够在不修改源代码情况下实现复杂的服务治理功能。
随着敏态业务的逐渐增多，对业务连续性、交付效率和故障处理效率等方面提出了更多的挑战，这些需求促进着技术架构的转变。安信证券服务化平台实践，以赋能业务为中心，积极拥抱微服务、容器和云原生
等新兴技术来应对业务系统研发过程中的实际问题。
1.解决什么问题
尽管微服务和容器等技术已广泛使用，但仍然需要结合具体的业务场景落地。因此，我们从实际出发，针对15个具有代
表性的自研业务系统负责人进行问巻调查
和访谈，同时对近两年的生产事件进行归
类，梳理出不同优先级的服务化相关需求。
(1)内部调研结果。从业务系统建
设方角度，期望平台提供如下能力项：使
用手册、配置中心、服务网关、负载均衡、
链路分析、熔断限流、注册中心、工程脚
手架、指标监控等。
(2)生产事件分析。平台研发团队
微服务网关和注册中心区别对近两年来1800+生产事件分析，归纳
整理出中间件配置、外部调用、监控、环
境差异、突发流量5类共性问题，对应能
力项需求包括：中间件最佳实践、开发规
范、指标监控、灰度发布、限流熔断等内容。
2.服务化探索
针对上述能力项需求与架构演进方
向，安信证券服务化实践主要包括以下几
个要点。
(1)演进式架构设计。实际的研发
过程中，大部分业务系统的服务拆分并不
是一蹴而就，当出现有多个功能模块紧耦
合、不同模块需要根据业务需求独立演进
等情况下才会考虑适当拆分，否则，单体
架构或者“小服务”(拆分粒度相对微服
务低)更能降低系统的开发、测试和运维
等阶段中的复杂度。
(2)解决实际问题。从应用的全生
命周期考虑，在研发阶段提供脚手架、开
发规范并约定服务间通信协议等内容；在
运行阶段，以应用的可观测性(主要包括
指标、链路和日志数据)为中心收集并展
示其运行状态数据，同时提供多种规则实
现异常状态的告警。
(3)结合容器云落地。随着安信证
券容器云平台建设的完善，并规划全部自
研业务系统“上云”，微服务架构基于容
器云平台落地，有效解决运行环境和操作
系统的标准化、应用灰度发布和弹性伸缩
等复杂操作。在服务治理方面，优先考
虑Kubernetes和服务网格的无侵入模式，
而不是以SpringCloud、Dubbo为代表的
SDK嵌入模式，主要原因是这类服务治
理框架会带来一些负担：一是注册中心提
供动态的注册与发现功能，但不解决网络
权限等问题。例如两个服务A和B间的
通信，引入注册中心C后，需确保A和B、
B和C、A和C之间的所有实例通信正常。
二是注册中心内外调用容易混淆。服务A
和B间的通信，服务A必须明确服务B
是否注册在同一注册中心，如果是，则使
用注册名动态发现月艮务的多个实例地址后
发起调用，否则，需要使用IP或者域名
进行调用。实际使用中，这两种调用模式
往往同时存在而导致混淆。三是SDK耦
合问题。SDK与业务耦合，当服务端升
级且对低版本不兼容时，将面临所有业务
系统需升级的大量工作。
规划先行—
—服务化演逬路线
结合微服务、容器等技术的演进和业
务系统面临的实际问题.制定服务化演进
路线如下。
POC(2018-2019)：针对各类低
83
睡E3画詞Application
迟延、高并发的业务应用场景，探索以gRPC通信协议为基础的低侵入服务治理框架，支持多种开发语言接入，并提供服务注册发现、负载均衡、容灾容错、服务治理、服务度量、统一配置、服务网关等一系列开箱即用的解决方案。
阶段一(2019-2020)：建设配置中心Apollo、基础框架SpringBoot、链路追踪Skywalking和运行指标Pro­metheus.脚手架等基础设施、打通指标、链路与日志等数据以提升应用系统的可观测性、提供数据展示的服务门户、用户对接的详细文档。
阶段二(2020-2021)：推动全部自研类业务系统进行服务化改造，根据用户反馈进一步完善基础设施，探索基于Service Mesh的限流熔断、灰度发布等功能；同期Nginx/Redis等常用中间件最佳实践、JAVA/C++/VUE等一系列开发规范同步发布，进一步提升业务系统的交付质量。
阶段三(2021-)：推广基于Service Mesh的服务治理体系，将服务治理功能与业务完全解耦，真正实现开发人员只关注业务。
模
块
与
组件
Keycloak
大屏展护
Prometheus Grafana Spring Boot
Mysql Swagger
Apollo
Skywalking Elasticsearch Spring Alertmanager
gRPC
图服务化基础平台架构图
II?解决方案——开源定制，量伸裁衣
为了有效落地阶段一规划内容，安
信证券和博云合作研发，基于开源组件进
行个性化定制，实现链路追踪、拓扑绘制、
配置中心、指标收集等功能。
1.以应用为中业，整合统一门户
提供以应用为中心的服务画像、服
务治理和观测告警等功能；展示接口慢响
应、吞吐量、接口调用异常等关键运行数
据，并根据预定规则进行告警；动态生成
服务间和系统间链路拓扑图；收集应用及
中间件的运行指标，如日志错误率、堆内
存使用率、HTTP错误响应码占比等。
2标准化开发框架，规范应用环境
标准化开发框架、基础依赖库、配置
管理、日志输出等基础组件；结合CI/CD
流水线提升开发测试和部署效率；实现开
发工程脚手架的功能，通过代码自动生成
达到基础框架和版本、工具、脚本等进行
规范和标准化。
3.链路追踪，故障分析之利器
基于自动埋点Traceld方式将一次
请求完整串联，并记录每个环节的耗时,
再将链路追踪和日志数据关联，对于接口
响应慢等常见故障的排查非常实用。
总结与展望
服务化基础平台的建设，是整个云
原生架构版图的重要组成部分。经过近1
年的投产使用，在平台能力建设方面已
逐步完善，并推动自研类业务系统进行
改造升级。目前已顺利上线29套业务系
统、99个服务和319个运行实例，接口
调用次数日峰值超过2亿次。主要的创
新点包括以下三个方面。
1.无侵入式调用链可视化
通过无侵入插件方式实现对各业务
系统方法调用埋点及数据收集，极大提
升了跨系统的故障定位能力。根据系统
间API调用情况，动态生成系统拓扑图,
实时显示上下游系统的调用频次、调用
时长等关键数据，为评估跨系统调用瓶
颈提供最有力依据。
2.统一技术栈打造云原生快速开
发平台
基于开源组件定制的云原生应用脚
手架，实现一键生成项目工程，能够将项
目构建从小时级缩短至秒级，也能够让应
用更加标准化，将基础框架以代码模板的
方式固化下来。
3.基础设施平台化赋能业务系统
通过制订接入规范，各业务系统可按
需对接。根据已上线的项目实施过程统计,
项目1至2周时间即可完成平台对接及验
证。相比之前各业务系统各自实现上述非
功能性需求，无论是建设效率还是建设质
量，都有大幅的提升。
随着自研类业务系统逐步地迁移上
云，以容器云和服务网格等云原生技术为
基础的无侵入式服务治理是未来演进的重
要方向，它将治理SDK的功能全部分离
到I Sidecar上，真正实现开发人员只关注
业务。服务网格是服务化实践下一阶段的
主要方向，期望能够更进一步提升业务系
统的研发效率和交付质量。冒
84