58集团RPC框架SCF的设计与实践( 三 ) _RPC框架

五、监控数据采集与存储服务在生产环境运行是否正常？当前服务流量是多少？有没有出现调用异常或超时的情况？这些都是服务的负责人需要关注的问题。
5.1数据采集
对于服务方来说，一个服务有多个方法，同时部署在多个节点上，同时会被不同的调用方调用不同的方法。同样一个调用方也会同时调用多个服务的不同的方法。导致整体的收集维度是服务方和调用方的乘积量级，应该如何有效采集数据呢？
下面给大家介绍一下针对 58RPC 框架的调用数据的采集方案。

文章插图
image
从总的架构图中可以看到，为了避免流量数据收集的压力，尽可能充分利用各层的计算能力分摊统一汇总的压力。

收集插件充分利用服务节点的计算能力，先进行本地数据聚合，以分钟为单位进行数据上报。
插件上报根据服务名 hash ，尽可能保证相同服务不同节点的数据发送到同一个收集服务器，收集服务器再进行一次聚合，进一步减少 Cache 统一计数的压力。

5.2数据存储
首先针对服务的调用信息，我们来看一下针对一个调用需要存储的数据情况。

文章插图
image
对于同一个维度的监控数据，以上字段中只有时间戳、次数和耗时数据是和实际的流量相关的，服务名 + 服务节点 + 函数名称 + 调用者 + 类型标识对同一个维度是相同的，因此为了减少数据的存储，我们定义一个映射的规则（S[demo]SN[10.0.0.1]SF[Service.get()]C[callerdemo] 表示服务方 demo 的 10.0.0.1 机器上的 Service.get() 方法被调用方 callerdemo 调用），将以上 5 个收集元信息映射成唯一的维度字符串，再把所有的维度字符串分别生成一个唯一的 cid ，实际存储的监控数据中使用 cid 替换以上 5 个收集元信息。

文章插图
image
在实际的应用中，最开始版本只存储调用的元数据，在展示的时候根据展示的维度进行数据查询聚合导致监控数据展示特别慢，因为需要经过大量的数据查询和合并，为了调高监控数据的查询速度，使用了写扩散的方式，针对一个调用元数据，做如下图所示的扩散：

文章插图
image
从上图可以看出，实际存储的时候将未来经常需要展示的数据先计算好直接存入库中，展示的时候只需要直接根据维度的 cid 直接查询结果即可，有效提高了查询速度。
六、总结SCF 框架作为 58 分布式架构的基础组件，支撑了 58 集团内部万级别节点的网络调用。本文主要介绍基本调用和监控相关内容。还有很多负载均衡、网络管理、故障节点剔除、服务鉴权、服务限流等模块没有展开。SCF 框架经过多次的迭代，从最初的最简单的远程调用到现在服务治理周边功能的完善，后续也将不断优化，欢迎感兴趣的同学一起沟通交流。