交易技术前沿基于分布式调用链框架证券

本文选自《交易技术前沿》总第四十一期文章（年12月）

罗明伟、曾利、任荣、王东、王洪涛

海通证券股份有限公司信息技术管理部

摘要

　　世界经济一体化和全球信息网络的发展浪潮中，各国金融市场日益联结成一个统一整体，复杂庞大金融数字化的深入发展为金融市场一体化奠定了坚实基础。证券行业IT体系也浪潮的推动中，在数字化方向的发展上也呈现上升泰势，传统的集中式系统正往分布式系统的方向逐步演变，分布式系统的引入为复杂证券业务的快速变化提供了灵活支撑，但同时也增加了业务调用深度，深度的增加导致一个业务请求可能涉及到几十个应用系统，对链路跟踪的缺乏，无法快速定位出问题系统，最终导致解决问题的效率低下。为了解决分布式系统架构下快速定位问题难的现状，基于对原业务系统侵入尽可能低的目标下，本文提出了一种分布式调用链框架设计方法。 　　该框架主要包含调用链信息采集、指标处理、链路展示、指标分析等几大模块，能够实现端到端的调用信息监控和跟踪，给生产环境问题排查、接口性能分析带来了很大的便利性，该框架成功运行于海通证券的相关应用系统，并且取得了良好的实际效果。

一、引言

　　随着互联网的不断发展以及国家信息化建设步伐的加快，迫切要求企业要跟上信息化建设的步伐，其中对于在国家金融发展中有着举足轻重的证券行业也显得尤为迫切。证券公司IT体系的快速民展，应用系统业务复杂度增大、系统数量的快速增多，系统与系统之间的信息交互越来越多，这些方面都加剧了系统的维护成本，往往一个业务场景会涉及十几个乃至几十个系统的共同协作才能完成。一旦业务过程中发生问题，对问题的定位将是一种高难度挑战，定位问题占用了开发人员的很多精力，使开发部门幸福感变低，工作效率变差，为此，设计分布式调用链框架，辅助业务系统快速定位问题，则显的非常有必要。

二、相关概念

1)分布式调用链

　　在广义上，一个调用过程代表了一个事务或者流程在分布式系统中的执行过程

图1分布式调用过程

　　图1中A-E五个节点表示五个服务。用户发起一次请求到前端服务A，该请求依赖后端服务B与C，因此服务A分别通过发送RPC请求到服务B和服务C，B处理完A的请求后将响应返回给A，但是服务B还依赖服务D和E，B再发起两个RPC请求分别到D和E，D和E处理完毕后回到B，B才继续应答到A，最终A将调用结果返回给用户。分布式调用链的目的，就是将用户一个入口请求及相应的其它后续请求进行网络拓扑汇制，最终生成表示调用关系的调用图。

2)分布式调用链Span

　　分布式请求调用会触发多个系统的之间的请求和响应，而将两个服务之间的请求/响应过程叫做一次Span，一个多层次调用过程由多个Span组成，其调用过程可以用以下表达式构成： 　　分布式调用链=SpanA+SpanB+SpanC+……. 　　图1的span的结构图如下

图2Span的结构图

　　上图中，包含了5个span（非RootSpan），其中B和C是A的子节点，D和E是C的子节点，某次请求调用过程的Span关系时间轴关系图如下所示：

图3Span的时间轴关系图

　　分布式调用链记录每次发送和接受动作的标识符和时间戳，将一次请求涉及到的所有片段服务串联起来，以此实现对一次请求的完整调用跟踪。

三、分布式调用链框架简介

　　前文介绍了分布式调用链的相关概念，后续将对分布式调用链框架进行介绍，从框架的整体设计而言，整个分布式调用框架主要由以下几个部分构成：调用链日志生成器、数据采集器、采集数据处理器、数据存储器以及调用链可视化组件构成，其中调用链日志生成器负责对整个业务请求过程中所涉及的应用进行卖点并且格式化输出到日志文件中，数据采集器负责对各个应用的日志文件数据进行采集上报，数据存储器需要对数据采集器上报的数据进行存储，并且对采集的数据进行相关指标运算，为系统告警或者相关的应用的性能分析做出参考，调用链可视化组件主要为相关调用链日志查询提供可视化界面查询，并且在查询速度上有比较高的要求。分布式调用链框架的核心设计图如下所示：

图4调用链整体设计示意图

四、调用链框架评估分析

　　针对调用链框架给系统带来的效果进行评估，主要采用了以下几种评估标准用于评估调用链框架效果，评估的维度如下： 　　●系统入侵性 　　●接口性能排查 　　●出错问题排查 　　●可复用性 　　下面通过几个维度的对比，以列表的形式展现了特点。

表1调用链框架给系统影响

五、分布式调用链框架的设计

　　本节会重点阐述一下分布式调用链整体的设计与实现，分布式调用链从功能实现上来说，有两大核心模块：调用链日志生成模块、日志采集与展示，下面将针对这两大模块的设计方案展开描述。

1)调用链日志生成模块

　　首先介绍几个核心概念：Tracer(跟踪器)、Span(跨度)、SpanContext(上下文)、Carrier(承载器) 　　●Tracer(跟踪器) 　　分布式系统调用链Trace代表一个完整的请求调用过程，Trace由多个服务系统请求/响应组成，一个trace可以认为是多个span的有向无环图。Tracer用来创建Span，以及处理注入和抽取Carrier，用于跨进程边界传递，为了跟踪一个请求的全部路径，往往通过生成TraceId方式进行跟踪。 　　●Span(跨度) 　　表示分布式调用链条中的一个调用单元，主要为服务提供方内部两个独立片段服务之间的调用。一个span一般会记录这个调用单元内部的一些信息，比如日志信息,标签信息,开始/结束时间。调用链中通过spanId来标注一个Span,但是日志展示过程中，如果要将两个独立片段服务之间的调用完整的展示出来，必须还要通过ParentSpanId来标识两个服务之间调用的层级关系。对于ParentSpanId而言，首次请求的时候，父Span不存在，因此默认为-1，后续进行分析的时候只要遇到某个Trace节点的父Span为-1，则表示这个请求是首次请求，也就是Trace树形结构中的根节点。 　　●SpanContext(Span上下文) 　　表示一个Span对应的上下文，Span和SpanContext是一一对应的关系，上下文存储的是一些需要跨越边界的一些信息，比SpanId（当前这个Span的id）,traceId（这个Span所属的TraceId）即：该次调用链条的唯一id。SpanContext可以通过某些媒介和方式传递给调用链的下游来做一些处理（例如子Span的id生成、信息的继承打印日志等）。 　　●Carrier(承载器) 　　用来在Span过程中，将SpanContext上下文在多调用单元传递，包括Span的标识信息、Span中的深度计数器、时间戳等。

2)调用链日志采集与展示

　　海通日志平台是集日志存储、分析和可视化为一体的分布式日志平台，包括日志采集模块、存储模块和日志搜索等功能，采集模块通过FileBeat进行采集，之后通过Kafka推送至LogStash集群进行日志解析、打标，经过日志标准化解析后存储在ElasticSearch，并生成相应的指标结果，日志平台平台支持图形化展示指标趋势、日志内容模糊快速检索，其架构如下：

图6调用链日志采集框架

　　要实现调用链在日志平台图形化展示，需要对日志格式改造：

1.TraceId的生成和MDC埋点

　　TraceId的生成方式采用的是UUID的生成方式，保证了TraceId的唯一性。MDC是log4j和logback提供的一种方便在多线程条件下记录日志的功能，将TraceId放在MDC中,可以保证当前线程下所有的日志输出都有相同的TraceId，同时当前线程的子线程也和父线程共享相同的TraceId，从而保证了一次请求的所有调用TraceId的唯一性。

2.日志格式改造

　　要实现在日志输出时打印出生成的TraceId，需要对日志格式中增加对TraceId的日志配置支持，对PatternLayout进行配置，具体配置如下:

六、实际运用

　　日志平台支持traceId的快速检索，支持对日志的链状上下文快速过滤，串联整个调用过程，从而对整个调用进行跟踪。以海通集中运营管理系统为例，详细介绍调用链技术如何串联集中运营管理系统的前端请求和后端子系统，通过对基于request请求生成的链路ID进行统计，能够有效的监控系统的吞吐量。另一方面基于链路能够对系统的异常报错进行跟踪，从而快速定位到报错系统，大大减少了定位出错问题的时间。通过链路数据的耗时数据实现对系统接口的耗时监控，从而找出系统高耗时的应用接口，再结合整个链路中的各个部分耗时的统计数据，能够具体定位到应用哪个部分出现性能问题，从而进一步对系统的性能问题进行优化。 　　以集中运营管理系统开户为例，截取了部分开户的日志调用链展示，详细展示了调用链如何对系统的各组件(数据库、缓存以及外部系统)进行串联，其部分调用链图7如下所示：

图7系统开户调用链路图

　　从上图的链路图可以看出，该图完整的展示了系统连接DB2，Memcache的数据组件的完整过程，并且详细记录了查询DB2，Memcache的耗时，并且在执行业务代码发生报错，从报错信息能够看出完整的出错原因，减少了排错时间。 　　以下从线上问题排查,基于链路跟踪的流量监控、耗时监控来说明调用链给系统排障、性能分析所带来的的好处。 　　●线上问题排查 　　当线上应用出现问题，传统的模式下需要对各个服务节点的日志用开户的关键字进行日志搜索，如果线上服务节点众多时，难以排查出问题的节点或者找出相关报错信息，当用TraceId对各个调用系统进行串联，比如开户，通过资金号或者相关关键信息信息找出业务请求的TraceId，通过TraceId能够将完整的调用日志信息展示出来，找到异常报错日志，找出报错原因，大大提升了排查问题时间。通过集中运营管理系统排查报障的所花费的时间来看，排查报障的时间总体减少了70%。 　　●链路监控 　　通过调用链的拓扑图式链路监控，可以看到Span的有向环形图，并且能够每个Span的耗时、吞吐量等指标。

1.流量监控

　　根据接口请求进行流量监控，通过流量监控，能够对集中运营管理系统负载情况进行整体评估，从而根据流量情况对服务器进行扩容和预测一些流量峰值，从而提前防范由于流量突然冲高带来的系统风险，实现服务器的动态扩容。图8是接口的流量监控，从而图中能够清晰的看到请求的峰值在10点左右。

图8流量监控图

2.请求耗时统计以及性能优化

　　对接口请求耗时统计，能够发现慢的请求/响应，借助耗时统计分析，发现系统在复杂列表页面、报表页面等请求处存在性能优化空间。图9的Top接口耗时统计，通过Top接口耗时能够看出耗时慢的接口，从而定向优化接口性能。

图9接口耗时监控图

七、总结

　　针对证券系统分布式部署下难以快速定位出问题的系统的问题，引入了分布式调用链框架，通过在请求端生成TraceId的方式绑定请求，后将TraceId在各调用端透传，实现了各个调用服务端的串联，为快速定位线上问题提供了很好的分析手段。该系统具有低入侵性，而且接入方案简单，能够快速接入业务系统，实现了对调用请求的完整跟踪，并且将该框架接入海通集中运营管理系统，实现了对海通集中运营管理系统开户等全业务的调用请求追踪，实现了对集中运营管理系统流量跟踪和请求耗时跟踪，基于耗时跟踪，进一步对系统性能分析，从而为系统性能优化提供好的分析基础。

八、参考文献

[1]刘嘉裕.基于分布式微服务全链路实时监控系统设计与实现[D].北京交通大学,.[2]SIGELMANB,BARROSOL,BURROWSM,etal.Dapper,ALarge-scaleDistributedSystemsTracingInfrastructure[R].Google,

免责声明

本

转载请注明：http://www.shijichaoguyj.com/wxjs/11473.html