构建云原生架构版图：安信证券服务化平台实践
互联网应用的海量用户、快速迭代、不间断服务和流量突增等业务特征促进其技术架构从传统集中式到分布式 SOA 和微服务 [1] 架构方向逐步演进。随着敏态业务的逐渐增多，对业务连续性、交付效率和故障处理效率等方面提出了更多的挑战，安信证券服务化平台实践，以赋能业务为中心，积极拥抱微服务、容器和云原生等新兴技术来解决业务系统研发过程中的实际问题。
近年来微服务架构在帮助公司实现业务敏捷、IT 敏捷方面发挥重要作用。根据中国信息通信院开源生态白皮书（2020 年）[2] 显示，我国超过六成企业已经应用或正在测试微服务框架。微服务具有松耦合、敏捷迭代、去中心化和弹性架构等优点，但微服务并非“银弹”，在实践中主要有以下几个方面的挑战：
（1）服务拆分粒度。尽管有领域驱动设计（DDD）[3] 等经典方法论指导服务的拆分，但服务是否拆分、拆分粒度仍然是仁者见仁智者见智的话题。不合理的拆分可能导致重复代码多，服务间依赖关系错综复杂等问题。
（2）服务拆分会大大增加系统的复杂度。服务拆分后，原本进程内的通信转换成进程间的网络通信，网络的不稳定性需考虑重试、限流等治理功能、还可能面对分布式事务、多个依赖的服务部署等复杂问题，大大增加了开发和测试的复杂度。
在微服务工程实践方面，诞生了一系列的基础框架、工具组件和基础平台支撑微服务的敏捷迭代、自动化发布和服务治理等特性。如 Apache 开源的 Spring Cloud、Dubbo 等框架，在同行业中，有东方证券开源的微服务治理框架 gRPC-Nebula [4]、国信证券开源的 Zebra [5] 微服务框架和恒生闭源 JRES3.0 [6] 分布式服务开发平台等，这些框架通过嵌入 SDK 的方式实现如服务注册与发现、负载均衡、认证授权、限流熔断、运行状态等服务治理功能。
同时，也有新一代如服务网格 [7] 的实现 Istio [8]、SOFAMesh [9] 等无侵入式的服务治理方案，通过对服务间的通信流量进行代理，能够在不修改源代码的情况下实现上述服务治理功能。
当前，基础设施云化已经成为最热门的演进方向，微服务落地的最佳载体是以容器和 Kubernetes 容器编排引擎为基础，为拆分后的服务提供弹性伸缩、资源调度等一系列标准化和自动化的能力。与经典的微服务治理 Spring Cloud 等框架相比，Kubernetes 包含运行时基础设施的管理等额外功能 [10]。同时 Kubernetes 对应用无侵入，将服务治理能力下沉至平台层，与业务松耦合，甚至对开发语言无具体要求。
根据 Gartner 报告 [11] 预测，到 2022 年将有 75% 的全球化企业将在生产中运行容器化应用系统。中国信息通信研究院的调查报告 [12] 显示，43.9% 的用户已在生产环境中使用容器技术部署业务应用，这使得用户对容器技术的认知和使用进入新的阶段，技术生态也在快速的更迭。行业内也不乏广发证券和华泰证券等容器云平台建设，银行业更有中信银行信用卡中心核心交易系统运行于容器云平台之上。
随着以 Docker 和 Kubernetes 为代表的容器技术的成熟、工程师不再需要应对各种迥异的运行时环境，Docker 通过集装箱式的封装方式，让开发和运维工程师都能够以“镜像”的标准化方式发布和交付应用。同时，在微服务等开发理念的带动下，将应用部署到云端已经是大势所趋，云原生（Cloud Native）[13] [14] [15] 的概念也应运而生，它最早是由 Pivotal 公司的 Matt Stine 于 2013 年提出，随后，Google 在 2015 年成立了云原生计算基金会 (Cloud Native Computing Foundation，CNCF)，CNCF 对云原生的定义为：帮助企业和机构在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、 服务网格、微服务、不可变基础设施和声明式 API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。
尽管微服务架构、容器和云原生等新兴技术已广泛使用，但它们仍然需要结合具体的业务场景落地。因此，我们从实际出发，针对 15 个具有代表性的自研业务系统负责人进行问卷调查和访谈、同时对近两年的生产事件进行归类，梳理出不同优先级的服务化相关需求。
平台研发团队在 2020 年初对近两年来 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 完全与开发语言解耦合。
针对各类低迟延、高并发的业务应用场景，调研 Dubbo、SpringCloud 等服务治理框架和 Consul、Eureka、Zookeeper 等注册中心方案，探索以 gRPC 通信协议为基础的低侵入服务治理框架 axsi（AnXin Service Infrastructure，安信证券服务化基础平台），支持多种开发语言接入，并提供服务注册发现、负载均衡、容灾容错、服务治理、服务度量等一系列开箱即用的解决方案。
建设配置中心 Apollo、基础框架 SpringBoot、链路追踪 Skywalking [16] 和运行指标 Prometheus、脚手架等基础设施，打通指标、链路与日志等数据以提升应用系统的可观测性，提供数据展示的服务门户、用户对接的详细文档；试点 3 套业务系统，并对接容器云平台。
推动全部自研类业务系统进行服务化改造，根据用户反馈进一步完善基础设施，部分业务系统改造后部署上云，探索基于 Service Mesh 的限流熔断、灰度发布等功能；同期 Nginx/Redis 等常用中间件最佳实践、JAVA/C++/VUE 等一系列开发规范同步发布，进一步提升业务系统的交付质量。
全面推广基于 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 配置中心；
服务器安装 Skywalking agent，应用日志添加 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 亿次。
本项目的实施，为提升业务系统研发效率和故障定位能力奠定了坚实基础，在平台建设和业务推广两个方面积累了大量的经验，是整个云原生架构版图的重要组成部分。主要的创新点包括：
如何实现从用户请求到应用、中间件、数据库、以及关联系统的全链路展示一直是个工程难题，原因在于各系统有各自不同的用户请求处理机制，有效识别同一用户请求往往需要各系统做代码上的改造，成本相当高。
服务化基础平台通过无侵入插件方式实现对各业务系统方法调用埋点及数据收集，通过全局请求跟踪标识实现跨系统的调用日志聚合，极大提升了跨系统的故障定位能力。根据系统间 API 调用情况，动态生成系统拓扑图，实时显示上下游系统的运行状态、调用频次、调用时长等关键信息，为评估跨系统调用瓶颈提供最有力数据依据。
云原生技术生态发展迅速，涉及的概念和可选技术栈庞大，对于传统金融企业，如何打造适合自身的企业级落地的云原生基础设施，是一件有技术难度的事情。
基于开源组件定制的云原生应用脚手架，实现一键生成云原生项目工程，能够将项目构建从小时级缩短至秒级。通过将云原生基础能力项标准化，以代码模板的方式固化到脚手架中，实现了所有新建项目的框架统一、配置统一和构建及部署方式统一；通过插件化设计，实现管理平面与业务平面有效分离，平台功能与业务功能升级互不影响。对于已有项目，采用脚手架新生成项目工程、迁移业务代码至新项目，同样可快速升级为云原生应用。
服务化平台实现服务治理、运行指标、链路追踪、告警规则等一体化管理，结合配置中心、容器云平台、DevOps 流水线，组成云原生基础设施平台，已成为重要的 IT 基础依赖。通过制订接入规范，各业务系统可按需对接能力项，提升应用可观测性。根据已上线的项目实施过程统计，除少数需要完全改造通信协议项目以外，普通项目 1 至 2 周时间即可完成首次平台对接及验证，后续逐步形成约定沉淀下来。相比之前各业务系统各自实现上述非功能性需求，无论是建设效率还是建设质量，都有大幅的提升。
当前，服务网格是云原生架构的关键技术之一。关于服务网格 [7] 的概念，借用 Linkerd 维护者 William Morgan 的一段定义 ：
服务拓扑交互和治理功能是微服务框架中最复杂的技术特性，以前需要 SDK 来承载，意味着对应用是有侵入性的。服务网格就是尝试将治理功能进行物理分离，做到无侵入性，对比 Spring Cloud、Dubbo 这类基于 SDK 实现治理的框架，最重要的区别是治理实现的复杂度全部由代理 (Sidecar，也称为边车，如下图所示) 来承担，使得业务程序层面能彻底放飞自我，甚至连开发语言也不限制了，完全解除了业务功能与治理功能的耦合。只要通讯协议是标准的 HTTP/gRPC， Sidecar 总能捕获到这些流量，进行动态控制。因此，也有人将它称为：微服务 2.0 时代。
服务网格有多种实现，其中 Istio [8] 是当前最为流行的一种，从 2018 年 6 月发布 v1.0 至今 v1.7 才 2 年，发展趋势上虽然也有过曲折，但也渐渐步入被大家广泛接受的阶段。在 ThoughtWorks 2020 最新的技术雷达 Vol. 22 [17] 中，Istio 终于挺进了采纳区，对其具体描述如下：
随着自研类业务系统逐步地迁移上云，以容器云和服务网格等云原生技术为基础的无侵入式服务治理是未来演进的重要方向。服务网格是安信证券服务化实践下一阶段的主要方向，期望实现开发人员只关注业务，更进一步提升业务系统的研发效率和交付质量。
作者介绍：安信证券股份有限公司信息技术中心 段苏隆 周巍 沙烈宝 李银鹰
参考资料：
http://martinfowler.com/articles/microservices.html
《开源生态白皮书（2020 年）》
《领域驱动设计》
https://github.com/grpc-nebula/grpc-nebula
https://gitee.com/gszebra/zebra
https://www.hs.net/openDay/jresService.html
https://philcalcado.com/2017/08/03/patternservicemesh.html
https://istio.io
https://www.sofastack.tech/projects/sofa-mesh/overview/
https://dzone.com/articles/deploying-microservices-spring-cloud-vs-kubernetes
https://www.gartner.com/en/newsroom/press-releases/2020-06-25-gartner-forecasts-strong-revenue-growth-for-global-co
《云原生发展白皮书（2020 年）》
pivotal.io/cn/cloud-native
《持续演进的 Cloud Native 》
《未来架构: 从服务化到云原生》
https://skywalking.apache.org/
https://www.thoughtworks.com/cn/radar####
InfoQ 写作平台欢迎所有热爱技术、热爱创作、热爱分享的内容创作者入驻！
还有更多超值活动等你来！
扫描下方二维码
填写申请，成为作者
点个在看少个 bug 👇
相关内容
微信扫码咨询专知VIP会员