原创文章，欢迎转载。转载请注明：转载自IT人故事会，谢谢！
原文链接地址：『互联网架构』dubbo 调用埋点（114）
上边几次都是说的单体的拦截埋点，应用的内部进行的，很多的情况系统都是分布式的，怎么去监听RPC（远程过程调用），dubbo，RMI，springcloud，http。只要远程调用，跨进程调用都属于RPC，也不可能所有的能都涉及到，很多公司都有自己的封装，例如阿里的HFS，这次只针对dubbo这种RPC进行调用。
源码：https://github.com/limingios/netFuture/tree/master/源码/『互联网架构』调⽤链系统工程结构（111）
（一）Dubbo执行过程
对于dubbo的埋点，首先要了解dubbo的执行过程
| 节点 | 角色说明 |
|---|---|
| Provider | 暴露服务的服务提供方 |
| Consumer | 调用远程服务的服务消费方 |
| Registry | 服务注册与发现的注册中心 |
| Monitor | 统计服务的调用次数和调用时间的监控中心 |
| Container | 服务运行容器 |
-
Dubbo调用过程
-
消费者调用过程
（二）调用端埋点实现
埋点目的
1.捕捉消费者调用信息（远程接口、URL、参数、用时、返回结果、异常）
2.传递TraceRequest调用信息模型表结构
| 名称 | 类型 | 描述 |
|---|---|---|
| servicePath | string | 服务路径 |
| serviceName | string | 服务 |
| inParam | json | 返回结果 |
| outParam | json | 返回结果 |
| ErrorMessage | string | 异常信息 |
| ErrorStack | text | 异常堆栈 |
| ResultState | string | 执行状态 |
| beginTime | date | 开始时间 |
| endTime | date | 结束时间 |
| addressIp | string | 远程IP |
| fromIp | string | 调用者IP |
- 埋点位置
如何才能完整的捕捉到以上信息呢？那么就需要了解Dubbo内部的调用
1.分解调用过程为多个步骤。
2.这些步骤分别是在哪些协作线程上完成的？
3.经过了哪些方法？
4.经过了哪些过滤器？
-
调用过程分解&线程协作
- 选择断点位置Debug调试调用过程
-
消费者调用线程源码分析：
- 经过对源码的分析，埋点的位置如下:
DubboInvoker.doInvoke()
FutureFilter.invoke()
DubboInvoker.doInvoke() 方法最靠近调用方，异常捕捉范围较大，但是该位置无法通过Attachment 向下传递TraceRequest 参数，所以需要FutureFilter.invoke() 进行补充，其具体分工如下：
·1.DubboInvoker.doInvoke捕获如下信息： 1、开始时间 2、服务路径 3、服务方法 4、输入参数 5、异常信息 6、本地地址
2.FutureFilter.invoke 基于Attachment 向下传递参数 2、异常信息与堆栈 3、返回结果
DubboInvoker.doInvoke拦截源码参见 ：com.cbt.agent.collects.dubbo.DubboConsumerRpcExceptionMonitorHandle#invokerBefore
FutureFilter.invoke拦截源码参见 ：
com.cbt.agent.collects.dubbo.DubboConsumerMonitorHandle#invokerBefore
（三）调用端埋点实现
- 埋点目的
接收TraceRequest信息 ，并创建会话
- 埋点位置：
相对调用广方接收方埋点目的较简单，但同样需分析源码找准埋点位置
-
提供者处理线程分析
经分析埋点位置选在离实际调用方法较远的EchoFilter过滤器理由是捕捉的信息更全面。
具体会话开启过程：
- 基于Attachment获取TraceId、ParentId、TraceProperties。
- 封装TraceRequest ，并此为参数开启会话。
- 在调用结束时关闭会话。
具体源码参见：com.cbt.agent.collects.dubbo.DubboProviderMonitorHandle#invokerBefore
（二）Servlet处理埋点
Servlet埋点目的
1.生成TraceId
2.开启关闭监控会话
3.捕捉Http请求（url、客户端IP、参数、响应时长、响应状态码）埋点埋在哪？
1.每一个Control方法
2.DispatcherServlet.doDispatch方法
3.HttpServlet.service 方法方案对比
| 方案 | 优点 | 缺点 |
|---|---|---|
| 应用层Control类 | 简单，风险因素低 | 判别成本高，有局限性，只能根据 HttpServlet 子类或@RequestMapping进行识别。 |
| DispatcherServlet.doDispatch | 简单，适应性强 | 1、只能针对spring mvc 项目 2、spring boot 项目不支持 |
| HttpServlet.service | 适应性强，与应用层和框架无关 | 1、不同的容器ClassPath不一样，存在兼容性问题。 2、存在风险，几乎所有请求都会经过此方法 3、业务异常无法捕获 |
总合比较还是选择 HttpServlet.service 会更好些。
HttpServlet.service 埋点需要做的工作：
1.字节码插桩
2.请求拦截并获取请求信息字节码插桩流程
字节码插是指在数据装载前在HttpServlet.service 插入监控指令，以拦截Http请求，其插桩的过程。
请求拦截是指具体Http请求过来时进行拦截过滤，这么做主要是为了完成两个目的
1.开启监控会话
2.开启对Servlet响应过程的监控
（三）Redis 调用埋点
- 埋点可选方案
| 方案 | 优点 | 缺点 |
|---|---|---|
| 埋点jedis 类Get、Set等API方法 | 简单直接 | 工作量大，方法较多、需要了解每个方法特性 |
| 埋点 Connection sendCommand方法 | 全面、所有命令都会经过此方法 | 存在未知风险、不方便计算执行时间、和返回结果 |
| 埋点 Protocol | 全面、所有命令都会经过此方法 | 存在未知风险、不方便计算执行时间、和返回结果 |
PS：源码中可以查看DevelopBootMain类，我看这代码也看了2天，原来老写业务代码，看看这确实很容易懵X，确实这才是有技术含量的代码。其实有没有技术含量不太重要，重要是的有没有商业价值。
