专栏名称: 分布式实验室

最专业的Docker文章，最权威的Docker新闻。关注容器生态圈的发展。

安信证券服务化平台，助力业务系统云原生架构转型

分布式实验室 · 公众号 · 后端 · 2021-02-28 08:15

正文

互联网应用的海量用户、快速迭代、不间断服务和流量突增等业务特征促进其技术架构从传统集中式到分布式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输出至日志文件，再通过日志收集器统一收集至日志大数据平台，并提供日志查询接口，实现链路和日志数据的关联，更进一步方便用户通过链路和日志数据综合判断故障原因。

实践案例

系统介绍

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

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

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

造前的系统架构图如下：

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

改造过程

改造步骤：

引入平台服务化的工程脚手架，快速构建Spring Boot工程；应用配置分离、多环境配置，为云原生改造打下基础；
开通配置中心、调用链、监控告警等的相关网络权限；
集成Apollo的客户端到工程当中，把原有的配置迁移到Apollo配置中心；
服务器安装Skywalkingagent，应用日志添加TraceId；
工程引入Prometheus相关依赖包；
工程代码修改通讯接口协议gRPC或Restful HTTP。

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

gRPC服务通讯改造的工作量大，或多或少会影响业务需求的迭代；
Skywalking 调用链日志埋点TraceId为空的问题，该问题还是费了一点时间，经过服务化项目组的通力协助才得以解决。

实施效果

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

服务门户见下图：

应用案例：

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

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

后期规划

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

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

总结与展望

总结

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

安信证券服务化平台，助力业务系统云原生架构转型

正文

请到「今天看啥」查看全文