1.开始之前，请先容许我介绍下华泰证券，华泰证券中全国领先的大型综合性证券集团，具有庞大的客户基础、领先的互联网平台及敏捷协同的全业务链体系，股票代码601688，主营业务主要有经纪及财富管理、投资银行、投资及交易、资产管理、海外业务，经济业务多年保持市场第一，去年系统交易总额35万亿元。
2.券商以往系统建设都依赖于服务厂商，所以也造成了各系统之间的多样异构化，各种类型的系统架构都长期存在，例如集中交易用的恒生系统，主要基于C语言的消息路由架构，自营系统则是恒生系统的tuxdeo架构，管理系统基于ESB架构，APP服务端则已基本是JAVA化的互联网化架构
3.随着华泰证券自主研发的大规模投入，迫切需要改变这种烟囱式的系统建设方式，以统一化的服务化架构来建设系统，我们先来看下华泰证券对服务化框架的一些需求：
- 跨语言，因为原有系统开发语言主要有C、PHP、JAVA，同时也为了以后能支持更多的语言服务业务系统，所以跨语言是服务化框架的最重要的属性
- 服务注册中心，便于动态的注册和发现服务，使服务的位置透明，便于服务消费方发现服务，同时注册中心需要高可用
- 服务负载均衡，提供服务调用负载均衡机制，方便服务调用请求自动负载均衡至后端服务，同时可以动态设置服务权重，根据权重进行相应服务负载均衡
- 服务调用链，当系统间服务数量众多时，需要服务化框架自动绘画出各服务间的依赖关系，便于日后的服务治理
- 服务授权，众多的服务涉及数据，需对服务调用进行授权验证及黑白名单设置，以防止数据及应用安全问题
- 服务流控，服务提供方需要对各类服务请求流控，当请求超标或失败时，能拒绝部分请求，进行自我保护，同时优先保证重要的服务调用方请求
- 服务质量等级协定(SLA)，服务消费者和服务提供者约定《服务质量等级协定(SLA)》，SLA包括消费者承诺每天调用量、请求数据量，提供方承诺响应时间，出错率等，同时将SLA记录在监控中心，定时与监控数据对比，超标则进行报警
- 服务审批，当服务众多时，可能会有不合乎规定的服务上线或未经允许下线，所以服务上线和下线都前需经过审批才能进行
- 服务版本管理与灰度发布功能。提供服务版本的管理功能，实现服务版本升级、降级、多版本共存等功能；支持服务升级的灰度发布功能，实现服务的平滑稳定升级。
- 服务调用优先级功能。支持调用者优先级配置，实现不同优先级的调用端提供不同的服务质量，确保高优先级调用者能够获得较高的服务质量。
- 服务文档库功能。建立服务WIKI知识库，方便服务调用方查找服务所在地
- 服务编排工具，开发专业的服务编排工具，能根据相应权限自动发现相应类型服务，并可通过图形化及编程形式对多种服务进行编排，从而创建新的服务并发布
4.在这些需求之下，现在来看下我们对服务化框架的一些设计思考
服务治理框架包括客户端框架、服务端框架、服务注册中心、采集器、流处理引擎、pmdb数据库、监控报警模块、认证授权模块、日志分析引擎、服务仓库、调度器、服务分析引擎、编排与服务网关、控制台。整体架构如图所示：
5.主要关键流程：
- 服务注册流程
调度器根据管理员的指令从服务仓库中读取服务软件包和配置信息，结合管理人员给出的安全配置信息，根据既定的策略部署到目标环境；等待部署完成后，把服务名称、版本、上线时间、TTL、状态、优先级、角色、服务协议、服务IP/Port信息、服务命令及参数信息、访问路径、安全ACL等注册到注册中心中。整个流程如下图所示：
- 服务调用流程
其操作流程如下：客户端从注册中心获取注册服务的列表信息，缓存到本地内存中方便快速查询；客户端根据既定的负载均衡策略选取一个服务结点发起服务调用，服务端接收客户端调用请求；整个过程由信息采集模块采集调用信息，发送到流处理引擎中进行进一步的处理。整个流程如下图所示：
- 服务跟踪流程
服务跟踪流程分为两个子过程：采集-处理-存储子过程和分析-可视化子过程，前者完成数据的采集、流式处理，以存储到PMDB和日志系统结束。后者基于存储的数据进行进一步的数据分析，完成容量预测、故障定位、关联度分析等高级功能，通过可视化界面对外呈现。整个流程如下图所示：
6.下面我们来看下关键技术的选型
目前开源的RPC框架主要有DUBBOX，GRPC，THRIFT，我们通过对比，目前想法主要是采用THRIFT技术来实现我们的RPC服务化框架
- DUBBOX确实是一个比较优秀的RPC框架，有很多公司在用，但DUBBOX社区基本消亡，已基本没有更新，我们不希望把公司这么重要级的平台建立在一个已经不前进的技术之上
- GRPC比较新，刚出来1.0，还有待观察，根据测试的结果，承载的性能比THRIFT有较大的差距，未来也许会考虑
- THRIFT社区比较繁荣，且多语言客户端支持较好，性能也在我们理想范围内，所以目前选择定制化THRIFT做为我们的企业级RPC服务框架
7.目前看，主要可能定制化的内容如下：
1) 扩展TSocket支持从注册中心获取服务列表，并根据既定的策略进行负载均衡；（客户端）
2) 扩展TServiceClient支持超时熔断保护及故障时的主备切换等策略；（客户端）
3) 扩展TProtocol支持调用信息采集操作；（客户端）
4) 扩展TNonblockingServer支持多优先级队列模型；（服务端）
5) 扩展TNonblockingServer支持安全策略模型，引入黑白名单机制；（服务端）
6) 扩展TProcessor支持信息采集操作；（服务端）
8.服务跟踪与分析
服务跟踪与分析技术包括三个部分的内容，分别是服务上下文信息采集、服务调用关系传递和服务调用时间序列分析。
- 服务上下文信息采集
服务上下文信息采集主要采集服务请求从进入服务端到离开服务端的全流程记录，包括进入服务端、放入队列、离开队列、开始执行、结果返回、执行结束等几个信息采集点。同时，要采集的信息包括服务器IP、进程/线程ID、时间戳、身份ID、会话ID等信息，采集后的信息导入到Riemann中进行实时处理。 - 服务调用关系传递
服务调用关系传递依赖扩展TServiceClient实现。通过在调用协议里封装当前服务ID和当前会话ID，实现调用依赖向下一级传递。依赖于服务上下文信息采集技术，服务ID和会话ID会被记录在调用处理的上下文时间序列时间流中，交给Riemann流处理系统进行聚类分析。
- 服务调用时间序列分析
Riemann基于服务上下文信息采集传递过来的事件流进行分析，分析主要操作是从事件流中分离出相同会话ID的流和相同服务（IP加上线程ID）的流，分别分析其相关性。利用二者综合分析技术，识别出调用事件流所属于的调用链。
9.其实以券商系统对时延以及各业务系统的系统复杂度，光RPC服务框架可能只解决了部分的服务调用问题，我们还会有TCP直连/消息中间件/ESB等系统交互形式，旧有系统也不可能大范围的重构，所以也要确保这类系统能纳入到我们的服务治理框架下来，当然这类系统没法做到服务的自动注册、发现等机制，但我们可以制定相应的服务协议规范，给出相应语言的SDK，自动落下协议日志，通过分析日志生成服务治理平台所需的各类信息，从而达到服务治理的目标。
10.好了，以上都是华泰证券在服务化道路上的一些探索与思考，有的地方考虑的并不深入，希望大家能多给宝贵意见，谢谢!
分享者简介：
樊建博士毕业于上海大学计算机应用专业，云计算、大数据专家，曾任上海大学硕士生导师。主持和参与多项国家几省级项目，获上海市科技进步奖1项；共发表三大检索论文近20篇，专著一本；申请专利近20项；拥有多年上市公司研发、管理及自主创业经验；现为华泰证券股份有限公司平台架构总监，负责公司整体平台架构规划、研发工作。
本文转载自微信公众号 中生代技术 freshmanTechnology