共计 13595 个字符，预计需要花费 34 分钟才能阅读完成。
摘要
微服务架构是近几年受到各行业宽泛追捧的技术之一，微服务架构具备轻型化、便捷化、麻利化等特点，不仅可能适应业务翻新和变动的须要，而且易于保护、变更、降级，符合以后证券业务倒退的须要。然而向微服务架构转型也面临不少挑战，西方证券通过构建对立的服务治理框架，打造了一个多语言、多协定、可视化、灵便配置的服务治理平台，反对西方证券企业技术架构向以微服务为外围的现代化架构转型。文本将介绍西方证券 gRPC-Nebula 服务治理框架与星辰服务治理平台的建设成绩，并介绍转型过程中的实践经验。
作者 | 西方证券首席架构师 樊建
西方证券服务治理架构师 舒逸
1
引言
近年来，随着证券市场客户和业务量的一直攀升，以及互联网金融的衰亡和金融科技的倒退，各证券公司都制订了数字化转型的战略目标。为了把握新一轮数字化技术反动浪潮，企业信息系统架构正在一直降级变迁，很多企业外部的传统软件系统都开始向微服务架构转型，通过服务拆分、升高零碎耦合性，达到“高内聚、低耦合”，提供更为灵便的服务撑持。
随着研发人员对系统进行解耦和拆分，对大量微服务实例进行无效管控、晋升零碎运行时的服务质量变得十分艰难。在此背景下，西方证券为了适应互联网 + 时代的潮流，响应疾速更新的业务需要，迫切需要以对立、服务化的思路来进行零碎建设，建设服务治理平台，通过剖析服务调用关系及拓扑构造、优化服务质量、制订服务协定标准，达到新建零碎与已有零碎对立服务治理 ， 实现轻利用 （业务为导向，实现业务利用麻利构建，及时响应市场需求）、 重平台 （将数据和外围利用转化成平台服务，成为整个架构的外围）、 服务化 （构建外围服务网络，简化利用开发与部署） 的整体企业技术架构转型指标，实现利用全生命周期治理。
2
微服务架构
1
单体架构
传统信息系统多采纳单体架构，单体架构利用把所有的性能都打包在一个独立单元中，并当做一个整体来开发、测试和部署[1]。Java Web 利用就是典型的单体架构利用，我的项目被打包成一个 WAR 包部署在同一个 WEB 容器中，其中囊括了数据拜访层的 DAO 对象、业务逻辑层的各模块、表示层出现的 UI 等性能。单体架构的劣势是开发、调试、部署简略不便，在业务倒退初期，信息系统的规模较小，应用传统的单体架构能够无效地撑持业务的倒退。然而，随着业务的爆炸性增长，利用零碎规模一直增大，单体架构将给业务零碎的开发、保护、部署带来微小的问题。
第一，开发效率继续降落，宏大的代码规模和盘根错节的业务耦合大大增加了研发新性能的难度，开发者不仅要把握本人负责的模块，还须要理解整个利用零碎的逻辑，否则批改代码后可能会引发抵触或其余模块谬误；
第二，继续迭代存在阻碍，任何一个非核心性能的小批改都须要重新部署整个我的项目，使得零碎运维中与公布相干的危险显著减少；
第三，系统可靠性变差，传统的单体架构将所有的利用都部署在同一个过程中，如果利用中某个接口产生故障，将会影响整个零碎失常提供服务的能力，在微小的霎时流量冲击下，很容易引发零碎雪崩；
第四，扩展性先天不足，单体架构的利用只能在一个维度上进行扩大，然而不同的模块可能有不同的资源需要属性，例如有的性能是计算密集型，有的则是 IO 密集型，因为它们运行在一个实例中，因而无奈对特定模块进行扩大；
第五，技术僵化无奈重构，各个业务应用的技术栈不得不与整个利用的技术栈捆绑在一起，很难更新 SDK 版本或应用新的技术框架。
2
微服务架构
因为单体架构已不能适应古代企业信息系统的须要，近年来微服务架构被广为推崇，并在越来越多的证券公司中得以实际和落地。微服务架构是由传统的单体架构逐步演变而来[2]，将大型单体利用依照业务功能设计拆分成多个能独立运行、职能繁多的服务，与其余服务之间通过对立协定进行通信 3。
微服务架构能够很好地解决单体架构下的诸多问题：
第一，将微小的单体利用拆分成颗粒度更小的服务，服务内逻辑简略、高度内聚，易于开发和保护；第二，各个微服务独立部署，性能批改后能够针对特定局部进行公布，使得各个微服务零碎可能继续化部署，放慢了迭代的速度；第三，当单个服务零碎呈现故障时，只须要将呈现故障的服务下线修复即可，不会导致整个零碎的级联故障；第四，可依据不同微服务零碎的访问量和资源需要，动静的实现横向扩大和纵向扩大，这大大的进步零碎的利用率；第五，各个研发团队能够依据本人的需要抉择编程语言和技术栈，具备更大的灵活性。
尽管微服务架构有着显著的优越性，然而证券公司普遍存在的零碎异构化问题也给微服务架构的落地带来了微小挑战。
1. 业务接口标准不对立，管控危险大
券商行业的外围零碎由传统供应商组成，以西方证券经纪业务外围零碎为例，别离由金仕达、新意、恒生、顶点、同花顺等厂商架构组成，SPX、T2、Rest、WebService 等多种类型服务接口存在于西方证券企业外部，多业务协同适配问题突出，服务多样性对同步、异步、流式数据等都提出了技术需要，统一化难度大；不足无效的要害业务流量控制技术伎俩；全局化平台协同与调度困难重重，不足全局视角对外部服务进行统一化治理。2. 自研零碎上线面临诸多困难 随着金融科技的深刻倒退，证券行业纷纷开始进行自研外围零碎，但因为不足对立的开发框架，各业务研发团队在具体开发过程中除了业务剖析之外，还需同时会关注十分多的技术细节，如依赖服务接口对接，开发语言技能，灵便可扩大架构撑持，客户服务治理保障，对外服务协定选型，服务故障定位，申请流量管制，服务平安配置，配置管理，流量管控等，自研业务也面临着诸多事实问题。3. 传统网关模式存在有余 传统外围零碎根本采纳网关模式进行对外服务，由网关进行接入管控，其个别具备身份认证、路由配置、负载平衡等性能，在对相似手机端这样的客户端时，其能起到比拟好的作用，但用在外围机房外部服务调用就存在着显著的有余。
- 采纳网关模式，渠道端须本人封装 TCP SDK，进行网关切换，所有的流量都会打到单网关节点，网关自身往往会成为瓶颈；
- 采纳网关模式，往往通过部署多个网关节点进行横向扩大，在运维部署上就会减少相当的工作量，也耗费资源；
- 采纳网关模式，相当于多了一路网络跳转，减少网络耗时，在等同部署模式下，升高了零碎整体能接受的并发容量，增大零碎延时；
- 采纳网关模式，零碎外部微服务对外采纳网关对外服务，无奈施展出微服务主动注册，主动发现的劣势，新增服务往往须要批改网关配置进行发现，整体架构进化成了传统架构模式。
现实状况下，业务人员关怀业务梳理和场景定义，开发人员把相干业务转换成服务定义，借助代码生成工具自动化生成接口代码，最初依据业务实现接口外部逻辑。由开发框架和内部工具负责架构扩展性、服务治理、配置管理等一系列非业务相干的性能实现，实现业务和框架的解耦，进步开发效率。
3
西方证券服务治理平台
欠缺的服务治理计划是微服务架构利用稳固运行的基石 ，西方证券凭借在服务治理畛域的技术积淀和实践经验，在 gRPC 框架根底上新增服务治理个性，建设了 gRPC-Nebula 服务治理框架和星辰服务治理平台，从而实现企业外部及内部服务的统一化治理，构建服务调用关系及拓扑构造，优化改良服务质量， 图 1 展现了西方证券服务治理我的项目的总体架构。
图 1 西方证券服务治理我的项目总体架构
西方证券服务治理计划次要包含如下几个模块：
1
注册核心
注册核心是一个分布式、高可用的配置保护零碎，用于服务的注册和订阅，它寄存着所有的服务形容信息以及服务接口信息。在微服务框架零碎中，服务和接口的数量十分宏大，同时因为零碎的动静调整，服务运行的实例数量也是动态变化的，注册核心通过将服务对立治理起来，能够无效地优化服务消费者对服务提供者的感知和治理，防止硬编码地址信息。
2
服务消费者（客户端）
服务的消费者，通过注册核心交互获取服务注册信息，基于服务注册信息发动对服务端的调用；同时，采集调用端信息发送到数据处理引擎中进行剖析解决，为调用链分析提供客户端数据。
3
服务提供者（服务端）
服务的提供者，通过注册核心对外公布服务信息，响应消费者的服务调用申请；同时，响应控制台等发动的配置管理操作，对服务质量、安全策略、数据收集等进行配置管理。
4
信息收集器
独立的部署的服务，收集服务调用过程中在服务提供者和服务消费者产生的服务调用、服务响应、服务异样、服务工夫、调用链路、外部队列长度、安全事件等信息，收集后对立发送到数据处理引擎进行解决。
5
数据处理引擎
数据处理引擎，对信息采集器发送过去的信息事件流进行实时剖析解决，解决操作包含性能统计、依赖剖析、阈值告警、相干聚类、状态跟踪、可用新剖析等；同时，数据被存储到性能治理数据库，用于进一步的剖析操作。
6
服务治理门户
服务治理门户汇总了服务治理畛域的运行数据和管理系统，它是全公司服务治理的综合平台。在服务治理门户，能够查问每个微服务的实例信息、接口信息、服务状态、依赖和被依赖关系、数据统计、服务调用追踪记录等要害信息和数据，展示了企业服务治理生态的全景图。同时服务治理平台反对黑白名单、流量管制、权重配置、主备配置、高低线状态的治理性能，反对调用量、性能、服务质量、可靠性、故障事件等对象的监控告警性能，是管理人员对微服务进行集中式治理的人机接口，也是故障定位与可视化出现的中控界面。
4
gRPC-Nebula 服务治理框架
01
技术计划
西方证券调研了目前比拟风行的开源微服务框架，包含阿里巴巴的 Dubbo[5]、Facebook 的 Thirft[6]、Google 的 gRPC[7]以及从 Spring Boot 框架倒退而来的 Spring Cloud 我的项目[8]，它们都具备较好的连通性、健壮性、伸缩性和拓展性，但 Dubbo 和 Spring Cloud 框架不反对多语言，Dubbo 开源社区曾有一段时间不保护更新，最近才重新启动更新。
因为历史起因，证券行业的原有外围零碎存在多种语言开发的现状，例如外围交易系统和同花顺网上交易等零碎采纳 C ++ 语言框架开发，账户、产品、资产配置、APP 及自研类零碎大多采纳 Java 语言框架进行开发，为了解决证券行业人造存在的跨语言场景，最终咱们抉择以 gRPC 框架为根底，研发 gRPC-Nebula 服务治理框架，为业务方提供服务治理整体解决方案。
相比其余几种框架，gRPC 有以下劣势：
- 全面的多语言反对，gRPC 反对多种语言，包含 C、C++、Java、Python、PHP、Node.js、C#、Objective-C、Go、Ruby、Dart 等。目前券商网上交易和外围交易系统均是 C ++ 架构，而其余自研零碎大多是 Java 和 Python 架构，gRPC 能无效解决服务的跨语言调用问题；
- gRPC 在 Google 和宽广开源爱好者的大力支持下，目前社区沉闷、更新频繁，已在全世界多家大型科技公司内投入生产；
- gRPC 应用 Google 开源的 Protobuf 3.0 协定定义接口服务，Protobuf 是一种平台无关、语言无关、可扩大且轻便高效的序列化数据结构的协定，广泛应用于网络通信和数据存储，技术人员对 Protobuf 的相熟有助于 gRPC 技术在企业内的推广；
- gRPC 的传输应用 HTTP/ 2 规范，反对同步、异步、双向流，反对 SSL 和自定义鉴权，反对 iOS、Android、Windows、Linux 等平台，能够简略地实现客户端到后盾的多路复用与 RPC 调用。
绝对于原生 gRPC 框架，gRPC-Nebula 服务治理框架引入了 ZooKeeper 作为注册核心，如图 2 所示，交融了服务注册发现、负载平衡、黑白名单、动静分组、集群容错、流量管制等服务治理机制，本章节前面的局部将具体介绍这些服务治理机制的技术计划。
图 2 西方证券 gRPC-Nebula 服务治理框架架构图
咱们别离对 Dubbo、原生 gRPC、gRPC- Nebula 框架进行了性能测试，如表 1 所示，gRPC- Nebula 框架的性能仅比 Dubbo 和原生 gRPC 框架低 1% 左右，满足高性能服务框架的需要。
表 1 多框架性能测试比拟
02
服务注册发现
服务注册发现是服务治理畛域最外围的机制，服务提供者在启动时向注册核心注册它提供的服务信息，服务消费者向注册核心获取服务提供者的地址列表，如图 3 所示。gRPC-Nebula 服务治理框架应用 ZooKeeper 作为注册核心，具备以下个性：
图 3 服务注册发现机制
（1）具备高可用性。当注册核心任意一个节点宕机时，服务可能主动切换连贯到其它失常的节点上；当注册核心全副宕机时，只影响新服务的公布与已公布服务的下线，不影响服务的失常运行，服务消费者会应用本地缓存的服务地址列表持续调用。
（2）保证数据一致性。所有服务消费者同一时刻从注册核心不同节点获取到的服务地址列表是同一份数据，不能呈现读或写数据的不统一。ZooKeeper 应用 ZAB 协定作为其数据一致性的外围算法[10]，是具备严格的访问控制的能力的分布式协调服务。
（3）服务变更被动推送。服务消费者只须要在启动时向注册核心拉取一次全量服务地址列表，其后向注册核心订阅相干服务的变更事件，一旦服务地址列表产生变更，注册核心会被动将变更的内容推送给服务消费者，服务消费者即时调整调用的服务地址。
（4）实时感知服务状态。注册核心与服务建设长连贯，通过心跳检测机制，可能周期性地检测服务的衰弱状态，当服务过程意外终止或服务器宕机时，注册核心可能立即向服务消费者推送服务下线的告诉，实现故障隔离。
03
服务路由
在生产环境上，微服务都是多实例部署，服务路由决定了服务消费者如何从服务地址列表中抉择服务提供者进行调用。gRPC-Nebula 服务治理框架的服务路由以下三大机制形成：
（1）负载平衡机制
gRPC-Nebula 服务治理框架反对连贯负载平衡和申请负载平衡两种模式，默认连贯负载平衡，同时提供了四种负载平衡算法可供选择：随机策略、轮询策略、权重配置优先策略、一致性哈希策略。
- 随机策略即随机地抉择服务提供者进行调用；
- 轮询策略即遍历服务地址列表，每次调用时顺次抉择一个服务提供方进行调用；
- 权重配置优先策略可依据配置文件或治理门户对每个服务节点配置的权重比来抉择服务提供者；
- 一致性哈希策略中，雷同参数的网络申请总由同一个服务提供者解决，当某个服务提供者的节点宕机时，零碎基于一致性哈希算法来抉择其余的节点。
图 4 gRPC-Nebula 负载平衡配置
（2）黑白名单机制
通过设置服务端实例的黑名单、白名单，能够动静实现申请流程的转移以及服务端实例的访问控制。如果将某 IP 退出一个服务的黑名单，部署在这个 IP 上的服务消费者无奈从注册核心获取到这个服务的地址列表。
图 5 黑白名单设置
（3）权重配置
gRPC-Nebula 可能对服务提供者实例设置不同的服务权重，框架依据权重进行流量散发，这样能够达到依据不同的后端资源能力进行动态平衡。
图 6 服务权重列表
图 7 服务权重设置
（4）动静分组机制
每个微服务实例都有一个分组属性寄存在注册核心，分组属性既能够通过配置文件事后设定，也能够通过治理平台动静配置。通过分组一个微服务的集群能够被划分为多个汇合，服务消费者能够按优先级调用某几个特定分组的服务，动静分组机制能够灵便实现同机房调用和业务隔离等场景。
服务端配置：
客户端配置：
图 8 动静分组配置
- 机房调用场景，在数据机房安全性越来越失去器重的明天，多机房灾备计划被各类企业宽泛应用，然而跨机房调用的高耗时可能造成零碎的容量升高。如图 8 所示，假如所有服务实例均部署在 A、B 两个异地机房，服务消费者心愿优先调用属于同机房的服务提供者，应用 IP 段定义机房的策略灵活性和扩展性有余，服务分组策略能够无效满足这一需要。例如将机房 A 的服务提供者定义为 a 分组，将机房 A 的服务消费者配置成优先调用 a 分组的节点，同时机房 B 的服务也进行相似配置。这样，机房 A 的服务消费者会优先调用机房 A 的服务提供者，防止高耗时的跨机房调用，当 Server1 和 Server2 全副宕机时，机房 A 的服务消费者会把申请主动切换到机房 B 的 Server3 和 Server4 上。
图 9 机房调用场景
- 业务隔离场景，业务隔离是防止微服务零碎雪崩效应的罕用策略，当一个服务提供者被多个消费者调用时，个别消费者的流量激增可能导致整个服务提供者集群超负荷运作，从而影响所有消费者的调用。服务治理平台的服务分组性能能够将服务提供者集群划分为一个个独立汇合，消费者只调用特定分组的实例，这样每个消费者的调用互相隔离、互不影响，能够无效保障整个零碎的高可用性。如图 9 所求，后端服务通过设置 tc、wmp、matrix 分组，可对交易接入、财产销售核心、西方睿等零碎别离提供不同服务等级保障，达到业务隔离诉求。
图 10 业务隔离场景
04
集群容错
当服务提供者无奈失常为消费者提供服务时，如连贯被回绝、申请超时、后盾服务异样等，服务框架须要进行集群容错，从新进行路由抉择和调用，gRPC-Nebula 服务治理框架反对疾速失败（Failfast）和生效转移（Failover）两种策略：
疾速失败是指如果服务提供者返回异样，消费者不必重试间接报错。这种策略适宜一些非核心的服务，能够为重要的外围服务节约贵重的资源。
生效转移是指当服务调用异样时，从新进行路由抉择，查找下一个可用的服务提供者来发动新的调用申请。当调用一个节点间断屡次失败或在一段时间内失败率超过限度时，框架认为这个节点以后已不适宜再对外提供服务，服务消费者会将其从服务地址列表中剔除，保障一段时间内都不会调用到这个异样节点。这个机制的目标是升高系统对网络抖动的敏感性，不会因为一次偶尔的调用失败而调整流量调配，放弃服务器负载的稳定性。和服务分组属性一样，间断失败次数和一段时间内失败率的阈值都能够通过配置文件和治理平台配置。
图 11 集群容错配置
05
流量管制
历史上券商外围零碎事变都是由流量冲击引起的，当网络流量霎时爆发性增长时，对服务器 CPU 和 IO 资源的抢占会造成零碎呈现瓶颈，服务错误率迅速回升，此时上游或用户的重试行为又进一步加大了网络流量，最终使得服务彻底解体且长时间难以复原，这即是雪崩效应。为了避免雪崩，须要对服务调用过程进行管制，通过一些策略削减流量，保障后盾服务接管的申请在可接受的范畴内。
gRPC-Nebula 服务治理框架通过设置申请数和连接数限度，动静实现对各服务接口的流控治理。申请数限度即当单位工夫内申请数过多时，抛弃多余的申请；连接数限度即管制每个 IP 连贯到服务提供者的连接数，在框架内服务间调用通过 gRPC 的 HTTP/ 2 协定放弃长连贯，当连接数达到阈值时，服务提供者会回绝建设新连贯的申请。
图 12 流量管制配置
06
拜访爱护状态
拜访爱护状态性能是服务治理平台管制服务端节点高低线的形式，能够用于无损公布和疾速摘除故障节点等场景。例如零碎上线更新时，服务的敞开或重启会导致一段时间内调用失败率升高，为了防止失败产生，能够通过服务治理平台将待操作实例设置为不可拜访，注册核心会告诉所有消费者不再调用不可拜访节点。待确认服务端实例无调用申请后，运维人员施行更新操作，更新胜利后再将实例从新设置为能够拜访。更新过程中流量会平滑地从实例移除和返回，不会产生调用失败。
图 13 拜访爱护流程
图 14 拜访爱护设置
07
多注册核心反对
出于平安管控需要，很多企业将网络划分为多个网段，每个网段部署独立的注册核心。GRPC-Nebula 框架反对将服务同时注册到多个注册核心，并且能够将自定义的服务端 IP 端口注册到注册核心，这个个性为了适配多网段间可能存在的 IP 地址映射或代理的场景。
图 15 多注册核心反对
08
主备服务反对
gRPC-Nebula 框架反对主备服务，可能对实例设置主服务器和备服务器。当主服务器可用时客户端只能调用主服务器，不调用备服务器；当所有主服务器不可用时，客户端主动切换到备服务器进行服务调用。
图 16 主备服务示意图
图 17 主备服务设置
09
内外部服务
gRPC-Nebula 框架反对同一我的项目不同类型的 grpc 服务具备不同的可见性。服务提供者实现的接口能够划分为两类服务，对于外部我的项目间 gRPC 调用服务，此类服务并不对外裸露，因而应该防止内部我的项目可见；对于我的项目对外提供的 gRPC 服务则须要容许内部零碎可见。
图 18 内外部服务
10
原生 gRPC 框架优化
- 断线重连指数退却算法反对
当 gRPC 连贯到服务端产生失败时，通常心愿不要立刻重试(以防止泛滥的网络流量或大量的服务申请)，而是做某种模式的指数退却算法。参考链接如下：
https://github.com/grpc/grpc/…
但这种模式往往会造成服务端失败后，客户端一直的进化重连工夫，长时间会进化成一个十分大的工夫，当服务端重新启动胜利后，客户端反而长时间不能连贯胜利，故此 gRPC-Nebula 批改了原生框架，客户端能够自行配置最大的重连工夫，躲避此类危险。
图 19 退却算法设置
- Keepalive 心跳
gRPC 原生逻辑具备 keepalive 心跳机制，客户端心跳默认敞开，服务端心跳 2 小时发送一次，参考链接如下：
https://github.com/grpc/grpc/…。
但在理论生产网络环境中，防火墙通常设置为 15 分钟就会被动断开无申请的 TCP 连贯，证券行业的特点造成了服务申请次要集中在 9:15-15:30 这个时间段，这样在非交易工夫会有大量 TCP 连贯断开，为此咱们批改了 gRPC 框架，使客户端和服务端都可自行配置心跳工夫。
图 20 客户端心跳设置
图 21 服务端心跳设置
5
星辰服务治理平台
建设指标
因为业务的理论需要和技术倒退，开发部门和供应商通常会依据须要抉择不同的微服务框架，出现多样化选型。如何治理好这些服务，成为研发和运维部门须要面对的问题。如果能够将这些框架和服务对接到对立的服务治理平台，将能够大大降低合作开发的老本，并晋升整体的版本迭代效率，因而西方证券星辰服务治理平台的建设指标包含：1. 通用治理能力：引入中间层设计，兼容多框架的通用治理能力，采纳散发器和治理组件协调工作对立多框架通用治理能力，由散发器下发工作至不同的治理组件，由理组件实现平台纳管多框架，实现散发器下发治理工作。2. 平台自服务：平台自身采纳微服务架构及容器平台集成，提供更深度的治理性能，提供平台利用生命周期、组件部署治理、灰度、弹性和对立配置反对。
3. 多框架兼容的利用治理：兼容基于 gRPC、Spring Cloud、Dubbo 三种微服务框架，帮忙客户疾速部署或迁徙微服务利用。
4. 业务服务架构防腐化：通过服务注册核心对服务强弱依赖进行剖析，联合运行时服务调用链关系剖析，梳理不合理的依赖和调用门路，优化服务化架构，避免代码腐化。
5. 疾速故障定界定位：通过服务调用链日志、服务性能 KPI 数据、服务接口日志、运行日志等，实时汇总和剖析，实现故障的主动发现、主动剖析和在线条件检索，不便运维人员进行故障诊断。
6. 服务微管控：运行态服务治理，包含限流降级、服务迁入迁出、服务超时管制、智能路由、对立配置等，通过一系列细粒度的治理策略，在故障产生时能够多管齐下，在线调整，疾速复原业务。
7. 服务生命周期治理：包含服务的上线审批、下线告诉，服务的在线降级，以及上线、下线，主动弹性伸缩，资源扩容。
功能模块
星辰服务治理平台蕴含以下功能模块：
（1）服务治理
星辰服务治理平台反对对 gRPC、Spring Cloud、Dubbo 三种微服务框架进行治理，如图 5 所示，反对查问注册核心保护的服务实例信息，反对通过控制台配置注册核心、访问控制、主备、分组、黑白名单、流量管制、熔断等信息。
图 22 服务治理性能
图 23 服务间调用
（2）服务地图
服务地图将我的项目与我的项目、服务与服务之间的调用关系和调用量通过拓扑图的模式进行展现，如图 6 所示。零碎架构师能够从服务地图提炼出全公司的外围零碎拓扑图，找出不合理的环形调用链；运维人员能够从服务地图把握外围零碎所依赖的上游零碎，并给予外围零碎同级别的重点保障。当预期面临流量猛增时，服务地图还可用于流量预估，因为从客户端等入口预估流量最精确，进而能够沿着服务地图下沉计算出各个微服务摊派到的流量，帮助后盾零碎制订扩容预案。
图 24 星辰服务治理平台服务地图
（3）链路跟踪
在微服务架构中，一个用户操作波及到多个微服务的协同能力实现，在业务调用链路上任何一个微服务出现异常或者网络超时，都会导致失败。通过链路跟踪，咱们能够很不便的看到每个申请各个环节的耗时以及异样，帮忙咱们对系统进行优化。星辰的链路跟踪性能基于 Google 的 Dapper 论文 [11] 实现，在零碎入口接管用户的申请后，会为用户的申请调配一个 TraceID 用来惟一标识调用链。TraceID 会追随近程调用消息传递到上游服务，直到整个链路的节点都领有了 TraceID，通过 TraceID 能够串起这个申请的残缺调用链路。
图 25 调用链关系
（4）文档核心
文档核心对 ProtoBuf 格局接口定义文件进行主动解析，提供技术人员查问各服务正文信息与接口定义的性能。咱们把文档核心看作是一个服务集市，技术人员在实现一个波及通用模块或第三方利用的性能前，能够像逛集市一样来文档核心查问接口的详细信息。将来咱们还将强化文档核心的交互沟通性能，减少问答与评论性能，买通各服务上下游的交换渠道。
图 26 文档核心
（5）统计分析
统计分析模块反对对服务、实例、端点的性能监控，包含响应工夫、可用性、吞吐量等；反对数据大屏，全景展现以后所有服务的运行状态；记录用户申请解决工夫，剖析出被调用服务的性能；记录服务响应工夫，并展现响应工夫最长的数个服务，即慢服务列表。
图 27 平台统计分析
（6）告警核心
告警核心反对基于监控数据的告警规定设置，并以自定义的形式收回告警告诉。
图 28 告警设置
（7）框架对立纳管
为了更好的反对企业架构转型，也便于各业务方零碎外部有更多的微服务框架供选择，晨辰服务治理平台同时对多种微服务框架进行了对立纳管，在反对 gRPC 服务的根底上，减少了 dubbox 及 Spring Cloud 框架。
图 29 多框架反对
6
转型实际
数字化转型
多年来，随着西方证券各类业务的继续倒退，数百套业务及撑持零碎在线经营，各类利用零碎间开始出现简单的依赖关系，零碎运维的复杂度急剧减少。特地是因为以往零碎建设次要由各厂商开发等因素的影响，西方证券外部存在大量的异构业务零碎，对外裸露的接口也出现多种形式，各厂商都有各自公有协定，且存在有 SPX、T2、Web Service、REST、TCP 等各类型异构接口，进一步减少了零碎开发、运维的难度。基于这些起因，西方证券从公司策略和技术治理上进行了改革。2018 年初，公司提出了“数字化转型”的战略目标，并将“加强金融科技利用”列入公司的六大倒退策略工作之一，这促使咱们以更加踊跃和凋谢的心态倒退科技。
与此同时，西方证券同步在企业技术架构上制订了大中台策略，这也是公司数字化转型中的三个外围策略之一（另两个为：外围自主研发、重构企业技术架构），旨在通过架构转型为公司科技工作的久远倒退打下坚实基础。为了推动架构转型工作，2019 年初，西方证券成立了以首席信息官舒宏总负责主任的架构委员会，旨在通过架构委员会重点进行企业架构转型的工作，同时创立了金融科技翻新研究院，以整合西方证券及子公司的技术资源、提倡以钻研为主导的技术利用为次要工作。外围自主研发策略的确立，不仅彰显了西方证券对本身技术实力的信念，同时也展现出在实现信息技术自主、平安、可控方面的胆识与气魄。
架构规范
为了建设各业务方遵循规范进行开发的能力，让企业架构建设有据可依，西方证券架构委员会制订了架构规范的决策流程及机制，通过架构规范去束缚各零碎相应开发实际，2019 年 5 月，咱们通过服务治理平台接入标准的架构规范，确定了企业技术架构转型的外围框架，各零碎采纳对立的接口调用形式，要求零碎间调用必须应用 gRPC 提供服务，零碎外部能够采纳 gRPC/dubbo/Spring Cloud 三种框架，反对西方证券 IT 技术架构从传统架构向微服务为外围的现代化面向服务架构全面转型。
图 30 服务治理架构决策
大中台策略
为了实现数字化转型，西方证券制订了三年架构布局，通过架构布局及落地施行，打造行业当先的 IT 架构和一流的 IT 队伍，造成公司科技倒退的竞争力，架构布局中有七大重点工作，其中一项是建设弱小的业务共享中台，提炼外围业务流程，为前端产品线提供业务共享能力，给前台提供弱小的“炮火声援”能力，确保“厚中台，薄利用”的胜利落地。
依照证券行业的畛域特点，咱们将整个中台畛域划分为产品、账户、财产、交易、资产、行情、资讯、日志、认证等核心，而服务治理框架也成为了整个业务中台的外围基础设施。
图 31 西方证券大中台策略
开源共享 / 行业标准
西方证券 gRPC-Nebula[9]，自身就是在站在开源 gRPC 的伟人肩膀之上倒退而来，为了更好的反馈社区，2019 年 6 月中旬，西方证券发表开源 gRPC-Nebula 服务治理框架，开源地址：https://github.com/grpc-nebula，目前社区已建设了社区决策委员会，初期拟设 7 名委员，含 1 名委员会主席，设有专人进行 GitHub 代码的跟踪、保护、解决。
同时，委员会会定期组织研究和常态化沟通、社区技术交换、协调开发力量进行社区开发、社区筹款、审议版本 maintainer 的版本和功能集、进行社区委员会选举等工作。社区将秉持金融科技翻新，对外技术输入的准则，致力于成为行业内首家基于 gRPC 可治理 RPC 框架下的开源社区，并取得了 2019 年信通院 OSCAR 尖峰开源技术创新奖（基于社区开源二次开发）及第四届中国优良云计算开源案例一等奖。
整个证券行业长期以来在技术架构畛域没有统一标准，各家厂商都有本人相应的技术框架，从而造成了整个行业始终面对的异构化难题，gRPC-Nebula 开源也旨在为整个行业提供参考倡议，同时，咱们也踊跃退出了深交所技术产品联盟，推广 gRPC-Nebula 在行业内的应用，心愿能达成行业共识，造成对立技术标准，大幅升高行业各零碎间对接老本。
实际成绩
从 2019 年初开始，西方证券进行服务治理框架研发工作，截止 2020.9 月，gRPC-Nebula 框架 Java 语言共迭代 14 个版本，C++ 语言共迭代 8 个版本，平台迭代了 4 个版本，较好的撑持了业务各类的需要。
同时，西方证券在外部大力推广服务治理框架及平台的应用，截止 2020.9 月，共接入各类利用 46 个，我的项目 99 个，服务数 369 个，办法数 3125 个，日承载各类申请量已达到数千万级。
从零碎维度来看，西方证券服务治理框架已接入外部西方赢家 APP、私行 APP、通达信网上交易、同花顺机构版、西方睿、西方大脑、智能投顾、大营运平台、业务中台（财产、交易、产品、账户、资产、行情、资讯等）、资产配置等外围零碎，从厂商维度来看，微软、恒生、金仕达、新意、顶点、通达信、同花顺等外围厂商及自研团队也已依照架构规范接入服务治理框架及平台，实际成绩非常明显。
图 32 服务治理平台实际成绩
总结
本文探讨了企业架构畛域的关键技术，并具体介绍了西方证券服务治理我的项目的建设成绩与实践经验。西方证券在企业架构层面制订了大中台策略，旨在通过业务架构转型为公司科技工作的久远倒退打下坚实基础。
作为大中台策略的外围组成部分，服务治理我的项目的建设，是公司进步金融科技外围竞争力的重要冲破。gRPC-Nebula 框架和星辰服务治理平台曾经利用于西方证券业务中台（财产核心、交易中心、账户核心、产品核心等）、西方赢家 APP、私行 APP 和西方睿机构交易产品线等数十个我的项目，同时实现了各微服务框架 (gRPC-Nebula/dubbox/Spring Cloud) 的对立纳管，为业务线开发提供了更多的开发框架抉择，随着平台生态的一直优化和倒退，将来将在外部全面推广，服务于更多产品线和用户，为公司 IT 治理标准和体系化架构建设做出更多奉献。
参考文献
[1]Fowler M, Lewis J. Microservices. Viittattu, 2014, 28: 2015
[2]Fotis Aisopos, Konstantinos Tserpes, Theodora Varvarigou. Resource management in software as a service using the knapsack problem model. International Journal of Production Economics. 2013 (2)
[3]Thones J. Microservices. Software IEEE, 2015, 32(1): 116-116
[4]李贞昊. 微服务架构的倒退与影响剖析. 信息系统工程, 2017(1): 154-155
[5]https://dubbo.io/
[6]https://thrift.apache.org
[7]https://grpc.io/
[8]https://spring.io/projects/sp…
[9]https://github.com/grpc-nebula
[10]Hunt P,Konar M,Junqueira F P, et a1. ZooKeeper:Wait-free Coordination for Interact-scale Systems[C]// USENIX Annual Technical Conference. 2010, 8: 9.
[11]Sigelman, Benjamin H., et al. Dapper, a Large-Scale Distributed Systems Tracing Infrastructure. Technical report, Google, 2010
