互联网应用的海量用户、快速迭代、不间断服务和流量突增等业务特征促进其技术架构从传统集中式到分布式SOA和微服务架构方向逐步演进。随着敏态业务的逐渐增多，对业务连续性、交付效率和故障处理效率等方面提出了更多的挑战，安信证券服务化平台实践，以赋能业务为中心，积极拥抱微服务、容器和云原生等新兴技术来解决业务系统研发过程中的实际问题。本文描述了安信证券服务化平台实践之路，包括对微服务、容器和云原生等技术的理解、业务系统研发过程中面临的实际问题、服务化平台路线规划、解决方案和实践案例，最后展望平台的未来发展方向。希望能够将实践内容和思考与读者呈现，共同探索这一领域的演进方向。

系统简介

近年来微服务架构因其具有松耦合、敏捷迭代、去中心化和弹性架构等优点，在帮助公司实现业务敏捷、IT敏捷方面发挥重要作用。在基础设施方面，随着以Docker和Kubernetes为代表的容器技术的成熟，工程师不再需要应对各种迥异的运行时环境，Docker通过集装箱式的封装方式，让应用能够以“镜像”的标准化方式发布和交付。当前微服务落地的最佳载体是以容器和Kubernetes容器编排引擎为基础，为拆分后的服务提供弹性伸缩、资源调度等一系列标准化和自动化的能力。在微服务治理方面，诞生了一系列的基础框架支撑微服务的敏捷迭代、自动化发布和服务治理等特性。如Apache开源的Spring Cloud、Dubbo等框架，通过嵌入SDK的方式实现如服务注册与发现、负载均衡、认证授权、限流熔断、运行状态等服务治理功能。同时，也有新一代如服务网格等无侵入式的服务治理方案，通过对服务间的通信流量进行代理，能够在不修改源代码的情况下实现上述服务治理功能。

随着微服务、容器等技术的发展以及应用和基础设施的云化，云原生的概念也应运而生，云原生计算基金会（Cloud Native Computing Foundation，CNCF）对云原生的定义为：帮助企业和机构在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、 服务网格、微服务、不可变基础设施和声明式 API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。

平台架构

安信证券服务化平台，从业务系统的实际需求出发，积极拥抱微服务、容器和云原生等技术，以低侵入甚至无侵入模式实现应用运行状态可观测、服务治理等功能，另一方面，为业务系统的研发提供云原生工程脚手架、并和DevOps流水线对接，是整个云原生架构版图中的核心内容。服务化平台的架构图如下所示，其中门户提供运行状态展示、观测告警以及服务治理等功能；模块与组件是用于对业务系统数据收集和服务治理的组件集合，与投资秀、高手社区、Leve2行情和用户中心等业务系统对接。

解决的问题

尽管微服务和容器等技术已广泛使用，但它们仍然需要结合具体的业务场景落地。因此，我们从实际出发，针对15个具有代表性的自研业务系统负责人进行问卷调查和访谈、同时对近两年的生产事件进行归类，梳理出不同优先级的服务化相关需求。

内部调研结果，从业务系统建设方角度，期望平台提供如下能力项：使用手册、配置中心、服务网关、负载均衡、链路分析、熔断限流、注册中心、工程脚手架、指标监控等。

生产事件分析，平台研发团队对近两年来1800+生产事件分析，归纳整理出中间件配置、外部调用、监控、环境差异、突发流量5类共性问题，对应能力项需求包括：中间件最佳实践、开发规范、指标监控、灰度发布、限流熔断等内容。

服务化探索

针对上述能力项需求与架构演进方向，安信证券服务化实践主要包括以下几个要点：

• 演进式架构设计。实际的研发过程中，大部分业务系统的服务拆分并不是一蹴而就，当出现有多个功能模块紧耦合、不同模块需要根据业务需求独立演进等情况下才会考虑适当拆分，否则，单体架构或者“小服务”（拆分粒度相对微服务低）更能简化系统的开发、测试和运维等阶段中的复杂度。

• 解决实际问题。从应用的全生命周期考虑，在研发阶段提供脚手架、开发规范并约定服务间通信协议、结合CICD流水线和容器云平台等基础设施赋能业务系统；在运行阶段，以应用的可观测性（主要包括指标、链路和日志数据）为中心收集并展示其运行状态数据，同时提供多种规则实现异常状态的告警。

• 结合容器云落地。随着安信证券容器云平台建设的完善，并规划全部自研业务系统“上云“，微服务架构基于容器云平台落地，有效解决运行环境和操作系统的标准化、应用灰度发布和弹性伸缩等复杂操作。在服务治理方面，优先考虑Kubernetes和Service Mesh等无侵入模式，而不是以SpringCloud、Dubbo为代表的SDK嵌入模式，主要原因是这类服务治理框架会带来一些额外的负担：

• • 注册中心提供动态的注册与发现功能，但不解决网络权限等问题。例如原本两个服务A和B间的通信，确保A和B之间的通信正常即可，引入注册中心C后，需确保A和B、B和C、A和C之间的通信正常，同时，在高可用模式下，还需考虑服务A和B与多个注册中心实例的通信状态。在金融行业严格的网络防火墙限制下，也削弱了注册中心的动态弹性伸缩功能；

  • 注册中心内外调用容易混淆。服务A和B间的通信，服务A必须明确服务B是否注册在同一注册中心，如果是，则使用注册名进行调用（通过注册名动态发现服务B的多个实例地址，并进行负载均衡），否则，需要使用IP或者域名进行调用。实际使用中，很难在短期内让所有业务系统在同一注册中心注册（一般也不会这样做，风险较大）这两种调用模式往往同时存在，这对开发者极不友好。尽管能够通过一些约定和封装将二者统一，但也增加了复杂性，不利于故障快速分析。

  • SDK耦合问题。如果是通过传统SDK等方式实现的服务治理功能，则与业务耦合，当服务端升级且对低版本不兼容时，将不得不面临所有业务系统需升级的大量工作。同时，SDK的耦合也意味着对具体开发语言有要求，无法实现像Kubernetes完全与开发语言解耦合。

规划路线

结合微服务、容器等技术的演进和业务系统面临的实际问题，制定服务化演进路线如下：

• POC（2018-2019）：针对各类低迟延、高并发的业务应用场景，调研Dubbo、SpringCloud等服务治理框架和Consul、Eureka、Zookeeper等注册中心方案，探索以gRPC通信协议为基础的低侵入服务治理框架axsi（AnXin Service Infrastructure，安信证券服务化基础平台），支持多种开发语言接入，并提供服务注册发现、负载均衡、容灾容错、服务治理、服务度量等一系列开箱即用的解决方案。

• 阶段一 （2019-2020）：建设配置中心Apollo、基础框架SpringBoot、链路追踪Skywalking和运行指标Prometheus、脚手架等基础设施，打通指标、链路与日志等数据以提升应用系统的可观测性，提供数据展示的服务门户、用户对接的详细文档；试点3套业务系统，并对接容器云平台。

• 阶段二 （2020-2021）：推动全部自研类业务系统进行服务化改造，根据用户反馈进一步完善基础设施，部分业务系统改造后部署上云，探索基于Service Mesh的限流熔断、灰度发布等功能；同期Nginx/Redis等常用中间件最佳实践、JAVA/C++/VUE等一系列开发规范同步发布，进一步提升业务系统的交付质量。

• 阶段三 （2021-）：全面推广基于Service Mesh的服务治理体系，将服务治理功能与业务完全解耦，真正实现开发人员只关注业务。

解决方案

为了有效落地阶段一规划内容，安信证券和博云合作研发，基于开源组件Apollo、Spring Initializr、Skywalking、Prometheus、Grafana、Alertmanager等进行个性化定制，实现链路追踪、拓扑绘制、用户管理、应用管理、服务管理、配置中心、指标收集、告警规则和历史等功能；规范化服务间通信协议Restful HTTP（普通场景）和gRPC（高性能场景）；制定JAVA等开发规范并通过CICD流水线检查项落地。

以应用为中心，整合统一门户

对用户、系统、角色和权限等元数据统一管理，按系统-服务-运行实例三个层次对应用运行状态描述，提供以应用为中心的服务画像、服务治理和观测告警等功能；展示接口慢响应、吞吐量、接口调用异常等关键运行数据，并根据预定规则进行告警；动态生成服务间链路拓扑图、系统间链路拓扑图；支持中间件指标收集自服务配置；集成审计日志、用户手册等常用功能。

标准化开发框架，规范化应用环境

标准化开发框架、基础依赖库、配置管理、日志输出等基础组件；结合CI/CD流水线提升开发测试和部署效率；实现开发工程脚手架的功能，通过代码自动生成达到基础框架和版本、工具、脚本等进行规范和标准化。

横纵交叉，立体展示业务系统运行状态

在传统对应用使用资源的监控基础之上，在业务系统可观测性方面，对链路追踪数据的展示以及和日志数据的联动，同时也收集了 Spring Boot 应用及中间件的运行指标，多维度展示业务系统运行状态，并基于收集的指标二次计算，形成特定场景的告警，例如应用日志错误率、堆内存使用率、HTTP错误响应码占比、GC频率等指标超过设定的阈值。

在每个交易日，平台会通过邮件将当日的系统运行简报发送至各个业务系统负责人，使其对每天的运行状态了然于心。

链路追踪，故障分析之利器

链路追踪，通过自动埋点TraceId方式将一次请求完整串联起来，并记录每个环节的耗时，对于接口响应慢等常见故障的排查非常实用，往往能够将一些未发生告警的潜在问题提前发现；另一方面，应用将TraceId输出至日志文件，再通过日志收集器统一收集至日志大数据平台，并提供日志查询接口，实现链路和日志数据的关联，更进一步方便用户通过链路和日志数据综合判断故障原因。

实践案例

系统介绍

投资秀系统作为早期的试点项目也是改造的标杆项目，积极配合并极大推动了基础设施建设的完善。该业务系统是面向移动互联网用户，线上展示投顾相关产品、观点、以及安信研究报告的窗口，同时也是公司投顾产品的主要营销渠道。主要的功能模块有：组合产品、资讯产品、股票池产品、投顾观点、安信研究、十大金股、策略回顾、模拟下单等。

随着业务的发展，对系统的稳定可靠性的要求也在逐步提高，同时业务需求的迭代效率也有新的要求，以投资秀系统原有的系统架构已经不能适应当前的要求。

为提升系统的可用性，提高服务能力，提升需求迭代效率，按照平台研发部的指引，引入统一的工程脚手架开展系统的服务化改造。改造完成后将为后续的系统服务拆分，微服务化打下基础。

造前的系统架构图如下：

改造后的系统架构图如下：

改造过程

改造步骤：

1. 引入平台服务化的工程脚手架，快速构建Spring Boot工程；应用配置分离、多环境配置，为云原生改造打下基础；

2. 开通配置中心、调用链、监控告警等的相关网络权限；

3. 集成Apollo的客户端到工程当中，把原有的配置迁移到Apollo配置中心；

4. 服务器安装Skywalkingagent，应用日志添加TraceId；

5. 工程引入Prometheus相关依赖包；

6. 工程代码修改通讯接口协议gRPC或Restful HTTP。

实施过程中的问题与困难：

1. gRPC服务通讯改造的工作量大，或多或少会影响业务需求的迭代；

2. Skywalking 调用链日志埋点TraceId为空的问题，该问题还是费了一点时间，经过服务化项目组的通力协助才得以解决。

实施效果

改造完成后，我们可以通过配置中心快速便捷的统一配置应用服务，通过服务门户可以非常直观的监控应用服务的健康状态，通过Skywalking可以监控接口的调用情况状态，而Prometheus则有服务相关的各种状态仪表。

服务门户见下图：

应用案例：

2020年5月25日，10时15分Skywalking调用链告警，tzx-manage服务接口响应延时达400ms+。

tzx-manage是内部的消息接收应用服务，经排查，是从非金融订单系统接收kafka消息后的业务处理逻辑较复杂导致，排除非故障后，计划在项目后续的版本进行复杂业务的拆分来优化。

后期规划

目前投资秀系统已经完成服务化改造，根据业务边界进行了业务拆分，并已将部分服务迁移至容器云平台，前期以虚拟机与容器并行的方式，保持系统平稳过渡；后期对新业务功能需求直接以云原生架构方式进行建设，并部署于逐步完善的容器云平台基础设施，同时将存量虚拟机部署的服务逐步迁移至容器云平台，最终下架原虚拟机的应用服务。

在服务治理方面，依托容器云和Service Mesh等基础设施实现无侵入式的限流、熔断和灰度发布等功能，逐步将业务代码中耦合的非功能性需求代码下层至平台。远景效果见下图：

总结与展望

总结

服务化基础平台的建设，是以“赋能业务”为第一目标，以“规划先行、逐步迭代”为建设思路，以“产品化建设”为原则，以“建设+运营”双路线来促进功能的完善，不重复造轮子，解决用户实际痛点，在平凡中创新。经过近1年的投产使用，在平台能力建设方面已逐步完善，并推动自研类业务系统进行改造升级。目前已顺利上线29套业务系统、99个服务和319个运行实例，接口调用次数日峰值超过2亿次。

本项目的实施，为提升业务系统研发效率和故障定位能力奠定了坚实基础，在平台建设和业务推广两个方面积累了大量的经验，是整个云原生架构版图的重要组成部分。主要的创新点包括：

无侵入式调用链可视化

如何实现从用户请求到应用、中间件、数据库、以及关联系统的全链路展示一直是个工程难题，原因在于各系统有各自不同的用户请求处理机制，有效识别同一用户请求往往需要各系统做代码上的改造，成本相当高。

服务化基础平台通过无侵入插件方式实现对各业务系统方法调用埋点及数据收集，通过全局请求跟踪标识实现跨系统的调用日志聚合，极大提升了跨系统的故障定位能力。根据系统间API调用情况，动态生成系统拓扑图，实时显示上下游系统的运行状态、调用频次、调用时长等关键信息，为评估跨系统调用瓶颈提供最有力数据依据。

统一技术栈打造云原生快速开发平台

云原生技术生态发展迅速，涉及的概念和可选技术栈庞大，对于传统金融企业，如何打造适合自身的企业级落地的云原生基础设施，是一件有技术难度的事情。

基于开源组件定制的云原生应用脚手架，实现一键生成云原生项目工程，能够将项目构建从小时级缩短至秒级。通过将云原生基础能力项标准化，以代码模板的方式固化到脚手架中，实现了所有新建项目的框架统一、配置统一和构建及部署方式统一；通过插件化设计，实现管理平面与业务平面有效分离，平台功能与业务功能升级互不影响。对于已有项目，采用脚手架新生成项目工程、迁移业务代码至新项目，同样可快速升级为云原生应用。

基础设施平台化赋能业务系统

服务化平台实现服务治理、运行指标、链路追踪、告警规则等一体化管理，结合配置中心、容器云平台、DevOps流水线，组成云原生基础设施平台，已成为重要的IT基础依赖。通过制订接入规范，各业务系统可按需对接能力项，提升应用可观测性。根据已上线的项目实施过程统计，除少数需要完全改造通信协议项目以外，普通项目1至2周时间即可完成首次平台对接及验证，后续逐步形成约定沉淀下来。相比之前各业务系统各自实现上述非功能性需求，无论是建设效率还是建设质量，都有大幅的提升。

展望

当前，服务网格是云原生架构的关键技术之一。关于服务网格的概念，借用 Linkerd 维护者 William Morgan 的一段定义 ：

服务网格（Service Mesh）是处理服务间通信的基础设施层。它负责构成现代云原生应用程序的复杂服务拓扑来可靠地交付请求。在实践中，Service Mesh 通常以轻量级网络代理阵列的形式实现，这些代理与应用程序代码部署在一起，对应用程序来说无需感知代理的存在。

服务拓扑交互和治理功能是微服务框架中最复杂的技术特性，以前需要 SDK 来承载，意味着对应用是有侵入性的。服务网格就是尝试将治理功能进行物理分离，做到无侵入性，对比 Spring Cloud、Dubbo 这类基于 SDK 实现治理的框架，最重要的区别是治理实现的复杂度全部由代理（Sidecar，也称为边车）来承担，使得业务程序层面能彻底放飞自我，甚至连开发语言也不限制了，完全解除了业务功能与治理功能的耦合。只要通讯协议是标准的 HTTP/gRPC， Sidecar 总能捕获到这些流量，进行动态控制。因此，也有人将它称为：微服务 2.0 时代。

服务网格有多种实现，其中Istio是当前最为流行的一种，从2018年6月发布v1.0至今v1.7才2年，发展趋势上虽然也有过曲折，但也渐渐步入被大家广泛接受的阶段。在 ThoughtWorks 2020 最新的技术雷达 Vol. 22 中，Istio 终于挺进了采纳区，对其具体描述如下：

如果正在构建和运行规模化的微服务架构，且已采用Kubernetes，那么使用服务网格来管理所有架构切面，应当是一个默认选择。在众多服务网格实现中，Istio是最主流的。它的功能十分丰富，包含服务发现、流量管理、服务到服务以及源到服务的安全性、可观测性（包括遥测和分布式追踪）、滚动发布及韧性机制等。其最新版本易于安装，并提供了控制面板架构，用户体验得到了改善。尽管我们承认维护自己的Istio和Kubernetes实例，不仅需要足够的指示，还需要一定的内部资源，可能并不适合能力不足的团队，但在我们的诸多项目中，Istio在保证运维质量的同时，的确降低了大规模微服务的实现门槛。

随着自研类业务系统逐步地迁移上云，以容器云和服务网格等云原生技术为基础的无侵入式服务治理是未来演进的重要方向。服务网格是安信证券服务化实践下一阶段的主要方向，期望实现开发人员只关注业务，更进一步提升业务系统的研发效率和交付质量。

作者：安信证券股份有限公司信息技术中心：段苏隆、周巍、沙烈宝、李银鹰

文章来源：上交所技术服务，点击查看原文。

Kubernetes管理员认证（CKA）培训

本次CKA培训在北京开班，基于最新考纲，通过线下授课、考题解读、模拟演练等方式，帮助学员快速掌握Kubernetes的理论知识和专业技能，并针对考试做特别强化训练，让学员能从容面对CKA认证考试，使学员既能掌握Kubernetes相关知识，又能通过CKA认证考试，学员可多次参加培训，直到通过认证。点击下方图片或者阅读原文链接查看详情。