微服务的监控追踪和治理
微服务的监控
把单体应用拆分为微服务之后，各种不同的服务相互调用，关系变得复杂，就需要对各个服务进行监控。主要就是监控以下三个问题：监控对象、监控指标和监控的维度
监控对象
监控对象可以分为四个层次，由上到下分别为：
- 用户端监控。通常是指业务直接对用户提供的功能进行监控。
- 接口监控。通常是指业务提供的功能所依赖的具体RPC接口的监控。
- 资源监控。通常是指某个接口依赖的资源的监控。
- 基础监控。通常是指对服务器本身的健康状况的监控。
监控指标
- 请求量。主要分为：实时请求量，用QPS表示，每秒查询次数来衡量。统计请求量，用PV表示，一段时间内用户的访问量来衡量。
- 响应时间。一段时间内所有调用的平均耗时来反应请求的响应时间。
- 错误率。一段时间内调用失败的次数占用总次数的比率来衡量。
监控维度
- 全局维度
- 分机房维度
- 单机维度
- 时间维度
- 核心维度
监控系统环节
监控系统主要包括四个环节：数据采集、数据传输、数据处理以及数据展示。
数据采集
- 服务主动上报，这种处理方式通过在业务代码或者服务框架里加入数据收集代码逻辑，在每一次服务调用完成后，主动上报服务的调用信息。
- 代理收集，这种处理方式通过服务调用后把调用的详细信息记录到本地日志文件中，然后再通过代理去解析本地日志文件，然后再上报服务的调用信息。
数据传输
- UDP 传输，这种处理方式是数据处理单元提供服务器的请求地址，数据采集后通过 UDP 协议与服务器建立连接，然后把数据发送过去。
- Kafka 传输，这种处理方式是数据采集后发送到指定的 Topic，然后数据处理单元再订阅对应的 Topic，就可以从 Kafka 消息队列中读取到对应的数据。
无论采用哪种传输方式，数据格式都十分重要，尤其是对带宽敏感以及解析性能要求比较高的场景，一般数据传输时采用的数据格式有两种：
- 二进制协议，最常用的就是 PB 对象，它的优点是高压缩比和高性能，可以减少传输带宽并且序列化和反序列化效率特别高。
- 文本协议，最常用的就是 JSON 字符串，它的优点是可读性好，但相比于 PB 对象，传输占用带宽高，并且解析性能也要差一些。
数据处理
- 接口维度聚合，这个维度是把实时收到的数据按照接口名维度实时聚合在一起，这样就可以得到每个接口的实时请求量、平均耗时等信息。
- 机器维度聚合，这个维度是把实时收到的数据按照调用的节点维度聚合在一起，这样就可以从单机维度去查看每个接口的实时请求量、平均耗时等信息。
聚合后的数据需要持久化到数据库中存储，所选用的数据库一般分为两种：
- 索引数据库，比如 Elasticsearch，以倒排索引的数据结构存储，需要查询的时候，根据索引来查询。
- 时序数据库，比如 OpenTSDB，以时序序列数据的方式存储，查询的时候按照时序如 1min、5min 等维度来查询。
数据展示
数据展示是把处理后的数据以 Dashboard 的方式展示给用户。
- 曲线图。一般是用来监控变化趋势的。
- 饼状图。一般是用来监控占比分布的。
- 格子图。主要做一些细粒度的监控。
微服务的追踪
一个系统拆分为微服务后，把各个微服务进行监控，但是一旦发现监控的服务出现异常，如何快速定位问题呢？比如有一个系统，专门跟踪记录用户请求都发起了那些调用，经过那些服务处理，并且记录每一次调用的详细情况，如果出现异常失败，就可以快速定位问题。微服务追踪系统的就是来专门搞定这个问题，除此之外，还有那些用途呢？
微服务追踪系统的作用
- 优化系统瓶颈
- 优化链路调整
- 生成网络拓扑
- 透明传输数据
微服务追踪系统的原理
核心理念是调用链：：通过一个全局唯一的 ID 将分布在各个服务节点上的同一次请求串联起来，从而还原原有的调用关系，可以追踪系统问题、分析调用数据并统计各种系统指标。
- traceId，用于标识某一次具体的请求 ID。当用户的请求进入系统后，会在 RPC 调用网络的第一层生成一个全局唯一的 traceId，并且会随着每一层的 RPC 调用，不断往后传递，这样的话通过 traceId 就可以把一次用户请求在系统中调用的路径串联起来。
- spanId，用于标识一次 RPC 调用在分布式请求中的位置。当用户的请求进入系统后，处在 RPC 调用网络的第一层 A 时 spanId 初始值是 0，进入下一层 RPC 调用 B 的时候 spanId 是 0.1，继续进入下一层 RPC 调用 C 时 spanId 是 0.1.1，而与 B 处在同一层的 RPC 调用 E 的 spanId 是 0.2，这样的话通过 spanId 就可以定位某一次 RPC 请求在系统调用中所处的位置，以及它的上下游依赖分别是谁。
- annotation，用于业务自定义埋点数据，可以是业务感兴趣的想上传到后端的数据，比如一次请求的用户 UID。
微服务追踪系统的实现
- 数据采集层，负责数据埋点并上报。
- 数据处理层，实时计算需求，离线计算需求。负责数据的存储与计算。
- 数据展示层，调用链路图，调用拓扑图。负责数据的图形化展示。
微服务追踪系统的治理
微服务在运行的时候好，经过实时监控和追踪能够及时的查询和追踪微服务，但是一旦要是出现问题了。能不能把问题的造成的影响降低到最小，能不能体现监控到问题的出现，就及时处理，不至于到后边一发不可收拾。这个时候就该需要服务治理出现了。
常用的服务治理手段有以下集中情况
节点管理
服务调用失败一般有两类原因引起。一类是服务提供者自身出现问题，如服务器宕机、进程意外退出等；一类是网络问题，如服务提供者、注册中心、服务消费者这三者任意两者之间的网络出现问题。这类问题有两种节点管理手段
- 注册中心主动摘除机制
- 服务消费者摘除机制
负载均衡
一般情况下，服务提供者节点不是唯一的，多是以集群的方式存在，对于大规模的服务调用来说，如何把这一批中每个请求，分散而均衡的分配到每个服务器。这就需要负载均衡算法来进行一些调整。常用的包括以下几种：
- 随机算法
- 轮询算法
- 最少活跃调用算法
- 一致性Hash算法
服务路由
服务路由，就是通过一定的规则，如条件表达式或正则表达式来限定服务节点的选择。定制路由的规则原因如下：该业务存在灰度发布的需求或者多机房的就近访问需求。路由的配置规则一般有两种配置方式
- 静态配置
- 动态配置
服务容错
服务调用发生异常，需要一些手段自动恢复，来保证调用成功。超用的手段有以下几种。
- FailOver，失败自动切换。
- FailBack,失败通知。
- FailCache,失败缓存。
- FailFast，快速失败。