今天谈下服务链监控和端到端流程监控。对于服务链监控有开源的类似zipkin，skywalking开源工具可以实现完整的服务链监控功能，但是采用这些工具的一般都需要在JVM启动的时候注入探针Jar包，进行访问拦截。而本方法则是一个自己规约实现服务链监控，整体的思路和方法实际和我们常说的服务链监控是一致的。
服务链监控实现
SkyWalking监控图
服务链监控基本概念与场景说明
服务链监控APM（Application Performance Management）即应用性能管理，属于IT运维管理（ITOM）范畴。主要是针对企业关键业务的IT应用性能和用户体验的监测、优化，提高企业IT应用的可靠性和质量，保证用户得到良好的服务，降低IT总拥有成本（TCO）。
在网络环境下，一次独立的服务请求往往需要涉及到多个服务。由于应用或服务构建在不同的软件模块上，这些软件模块，有可能是由不同的团队开发、使用不同的编程语言来实现，而且有可能部署在不同的硬件环境中，横跨多个不同的数据中心。因此，就需要一些可以帮助理解系统行为、用于分析性能问题的工具，以便发生故障的时候，能够快速定位和解决问题。
服务链监控是通常应用于APM，即将实际应用性能和相关服务的调用关系以服务链方式串联起来，以便分析和定位实际影响到最终应用性能的关键服务，并进行后续处理。
分布式环境下的服务链监控基本模型如下：
图片
其中，在上图中有几个比较重要的概念。
- Span：基本工作单元，一次链路调用创建一个span，通过一个XX位ID标识它，一般是UUID较为方便。当然，Span中还可以有其他的数据，例如描述信息、时间戳等。
- Trace：类似于树结构的Span集合，表示一条调用链路，存在唯一标识。
服务链监控场景说明
如果需要在复杂的网络环境上下文中理解分布式系统的行为，就需要监控那些横跨了不同的应用、不同的服务器之间的关联动作。在多系统、多模块、多服务构成的架构系统中，几乎每一个前端请求都会形成一个复杂的分布式服务调用链路。
一个服务请求的完整调用链路可能如下图所示：
图片
即在前台功能页面，点击提交单据按钮的时候，需要调用业务内部多个服务接口，同时也需要调用到外部系统提交的服务接口，实现完整的业务功能逻辑。那就需要对整个服务调用链进行监控。
那么，在业务规模不断增大、服务不断增多以及频繁变更的情况下，面对复杂的调用链路就带来一系列问题：
- 如何快速发现问题？
- 如何判断故障影响范围？
- 如何梳理服务依赖以及依赖的合理性？
- 如何分析链路性能问题以及实时容量规划？
有了服务链监控，我们能够做到：
- 提供链路追踪，故障快速定位：可以通过结合业务日志快速定位错误信息。
- 可视化：各个阶段耗时，进行性能分析。
- 依赖优化：各个调用环节的可用性、梳理服务依赖关系以及优化。
- 数据分析，优化链路：可以得到用户的行为路径，汇总分析应用在很多业务场景。
业务场景验证和关键技术实现
在这里，我们举一个业务报账单单据提交功能来进行说明和验证。业务人员在报账平台填写报账申请单，填写完成后进行提交，具体涉及到如下操作步骤。
- 进行数据完整性校验（调用供应商有效性校验接口，调用账户有效性校验服务）
- 调用预算校验和扣减（调用预算校验服务，调用预算扣减子服务）
- 调用申请单保存服务，进行申请单保存
- 调用工作流平台提供的工作流启动服务接口进行流程启动
图片
服务链监控的使用规范
a.在接口服务调用中增加TRACE_ID信息
需要在接口服务调用的输入中增加TRACE_ID字段，作为服务链跟踪使用。
b. TRACE_ID组成说明
一个用于服务链监控的TRACE_ID的生成，由以下信息所构成。
概述：UUID+ SPANID +SPANID+SPANID 组成
说明：UUID为每一个服务调用链，生成一个独立唯一的UUID值
SPANID：SPANID为01、02顺序编码，服务调用每进一层增，即增加一层SPANID
图片
依据上述规则，生成的一个参考如下：
TRACE_ID：550e8400-e29b-41d4-a716-446655440000.01.01.02
c. 服务链监控参考实现伪代码
根据前述业务场景例证的说明，下面以报账服务的调用链路来说明，如何使用TRACE_ID来进行服务链的监控。
1. 业务系统所有的子方法调用都需要增加TRACE_ID参数进行传递，子方法调用下一级子方法的时候生成新的TRACE_ID值，即TRACE_ID的定义是递归的。
TRACE_ID = TRACE_ID + SPANID
2. SPANID按服务调用的顺序进行两位编码，每次步长增加1，诸如01、02、 …. 99
参考下述伪代码，描述了前述的监控实现过程：
public String ApplySubmit()
{
//通过工具类生成UUID
String uuid = utils.generateUUID();
//调用数据检查服务，通过UUID + SPANID 拼接出每次服务请求的TraceID
Boolean r1 = this.DataValidateSrv(params, uuid + ”.01”);
//调用预算检查服务
Boolean r2 = this.BudgetValidateSrv(params, uuid + “.02”);
//调用单据保存服务
Boolean r3 = this.BillSaveSrv(params, uuid + “.03”);
//调用启动工作流服务
Boolean r4 = this.StartWorkFlow(params, uuid + “.04”);
//结果返回处理
String result;
return result;
}对于需要进行跟踪的下一级服务，也需要依照同样的原则进行处理：
public String DataValidateSrv(params, TraceID)
{
//调用供应商检查服务，通过TRACEID + SPANID 拼接出每次服务请求的TraceID
this.VendorValidateSrv(params, TraceID + ”.01”);
//调用银行账户检查服务
this.BankAccountValidateSrv(params, TraceID + “.02”);
//结果返回处理
String result;
///
return result;
}d.监控日志的记录
由于在前台操作触发的后台服务调用操作中，有可能调用注册在集成平台上的服务，也可以调用业务系统内部的服务接口，因此，要做到全面的服务链监控需要对两部分的日志都进行记录。
- ESB总线服务：平台会记录服务日志，调用时间消耗；业务系统也可以同时记录。
- 业务系统内部服务：集成平台无法记录，必须由业务系统自己记录。
服务日志需要同时记录服务调用时间消耗、服务ID、服务名称、TRACE_ID、输入、输出信息。具体代码参考如下：
//数据检查服务方法
Void DataValidSrv(params, TRACE_ID);
{
//获取开始时间
Time StartTime = System.GetCurrentTime();
//获取入口参数
Map inputParams = this.method.getParams();
//供应商检查，实际为UUID.01.01
this.VendorValidSrv(params,TRACE_ID.01);
//银行账户检查
this.BankValidSrv(params,TRACE_ID.02);
Map outPutParamorData = this.method.getOutPutParams();
Time EndTime = System.GetCurrentTime();
LogSericeData(ServiceID, ‘DataValidSrv’, StartTime , EndTime, inputParams, outPutParams);
}注：业务系统也可以采用类似AOP模式进行调用信息拦截后统一记录。
服务链监控的展示
图片
对于服务链监控，集成平台可以根据记录的TRACE_ID信息进行关联，形成服务链展示树，业务系统提供UUID值，即可以查看到完整的服务调用链，并看到每个服务实例调用的时间。当然，对于服务链监控仍然可以参考上篇博文中谈到的进行可视化的图形树状结构展示。
当前为了展示方便，主流的服务链监控基本都是参与表格+树状展开的模式进行展示。
端到端流程监控
基于接口的跨系统流程概述
在这里的端到端流程监控特指跨系统交互业务流程，即一个完整的端到端流程跨越多个系统，多个系统之间通过接口交互来实现协同。一个完整的端到端流程如下：
图片
如上图，一个完整的企业内部自建电商平台，在完成一个B端客户的订单下达，执行和交付的时候，需要跨越电商平台，CRM系统，物流平台，SAP-ERP系统和第三方支付平台，第三方的物流平台来共同完成。
那么在下达一个订单后，当前的流程究竟走到了哪里？是否已经完成支付，订单是否已经传递到ERP系统，订单是否已经安排配送，订单当前的物流配送是否完成，订单是否已经被客户签收等，整合是上面端到端流程里面的关键接口交互点。
即：如果一个接口点正常执行完，那么说明业务流已经走到下个阶段。
而对于类似上图的跨多个系统的端到端流程，我们往往希望跟踪一个订单当前执行到哪个阶段，具体什么状态，那么核心的关键字就是订单编号，可以看到后续的支付，物流，配送，订单执行等相关接口，接口的输入信息中都会有订单编号这个关键字。
跨系统交互流程建模
可视化接口交互流程设计
从前面分析可以看到，可以通过接口交互分析来倒推流程。因此我们可以对接口交互流程进行可视化设计和建模。同时对所有的接入注册到ESB服务总线进行管理。
由于接口服务都通过ESB服务总线进行封装代理后接入，因此理论上说从实际业务服务调用实例数据和日志中是可以反推出来端到端的业务流程的，也就是可以通过服务实例和服务链的监控来间接的监控跨系统的业务流转是否正常。
简单来说，比如一个采购订单，基于一个采购订单号，我们实际上可以通过服务监控数据来分析到该订单是否已经从采购系统导入到ERP，是否已经进行了报账申请，是否已经进行了付款等，实际上这些信息从服务实例日志中都可以提取出来。
要完成这件事情，实际上有两个关键点要做，即首先要对服务链本身进行进行服务链流程建模，其次是能够对采集的日志的输入输出中能够抓取出结构化的关键业务字段信息。只要做到这两点，我们就很容易实现可视化的跨系统服务链监控功能。
在前面我们做ESB服务设计器的时候，已经已经剥离了原流程引擎中进行服务编排或可视化流程建模的能力。实际上这里的设计本身也就是一个多个服务编排设计的过程，将多个服务编排设计到一起。注意在这个过程中还需要允许有分支，也允许并行。服务链监控最终形成的也是一个完整的服务链监控树。只是这个监控树的形成是通过可视化的服务组合编排工具来实现的而已。
针对不同的跨系统业务监控，都需要针对不同场景设计不同的服务监控模型。
比如现在设计一个采购订单服务链监控模型，我们可以对该模型进行简化，具体如下通过建模工具形成如下模型树。合同导入服务-》采购订单导入服务-》采购接收服务-》报账申请服务-》应付发票导入服务-》付款服务。
我们完全可以采用流程设计和建模工具来完成上图的流程模型，当然如果采用类似支持BPMN标准的流程建模工具还可以进一步完成跨系统交互流程图。
在这个跨系统交互流程图中，衔接各个业务系统的仍然是相互之间的接口和服务，我们仍然是按照一个核心单据为基本元素来进行设计，比如项目编号，合同编号，采购订单编号等。以这个编号来完成整个跨系统端到端流程的分析。
在建模的过程中，两个系统间的连接线就是关键的接口服务，但是由于不是直接的服务间的连接，因此仍然需要建立服务之间的关联性。比如我们整体跨系统监控都是以采购订单号来进行跟踪的话，我们就需要定义采购订单这个元素在每一个接口服务中对应的XML-Element的位置，以确保这些服务之间本身能够关联起来。
整体我们看到实现的思路和服务链监控基本相同。
仍然是先根据业务关键字查询功能，精确查询出相关的服务实例数据。然后将服务实例数据映射到流程图上面，形成流程图实例。对于已经成功运行的服务标注为绿色，对于接口调用失败的服务标注为红色，对于还没有执行到的服务标注为灰色。
同时更加有意义的事情是，我们完全可以来动画效果模拟这个跨系统接口交互流程。即能够动态的看到各个接口被触发和调用的前后顺序。同时看到前后接口触发的大致时间间隔信息。通过这种实现能够很方便我们实现围绕核心业务对象的端到端流程监控能力。
当然这是一种变通的端到端流程监控实现思路，核心是先进行流程建模，然后再通过业务关键字检索功能动态搜索匹配的服务日志调用数据，再对流程图进行实例化解析。由于采用了Solr全文检索能力，这个比我们完全自顶向下的来进行端到端流程监控实现更加高效。
业务日志采集和监控查询
图片
在前面有篇文章我们专门谈到过基于Solr进行业务关键字查询和报文日志全文检索。而这个功能本身刚好用到服务链监控里面。即我们不再需要对服务运行报文数据全部进行结构化数据，而只需要对这些数据建立元数据索引信息，有了索引后Solr基本就可以快速的检索和定位到具体的服务。
对于当前的服务日志，我们已经完成了将Blob结构的数据准实时的采集并提取索引信息，进入到Solr库，实现了基于业务关键字的服务实例查询能力，而原来我们只能基于服务实例号进行服务日志的查询。
基于Solr查询速度相当快，基本都是10多毫秒就能快速完成服务日志的检索能力。在Solr实现了索引数据的创建，基于业务关键字的查询能力后，接下来分析如何和服务链监控进行整合。
举例来说，对于采购订单服务链监控，进入该功能后我们直接输入采购订单号，然后基于订单号我们做如下事情。
- 首先找到采购订单服务链监控流程模板，然后基于流程模板知道涉及哪些服务。
- 找到流程模板中维护的Xpath检索项
- 基于Xpath检索项找的信息，拼装Solr查询关键字，然后进行Solr查找到对应服务日志记录。
- 将服务日志记录提取出来对应到流程实例具体的活动节点上面。
- 完成流程实例图的显示。
当我们点击线条的时候可以查看到详细的每笔接口服务调用日志信息。具体参考图如下：
图片
以上即是一个完整的基于Solr和ESB总线结合来实现端到端流程监控的一个技术实现思路。该功能已经在我们自研的ESB服务总线和IPaaS管控治理平台得到实现，并得到很好的展现效果。
