服务可见可观测性

可见可观测是服务治理反馈机制的第一步，只有获取到足够多有价值的数据，才能对服务的运行状态进行分析和控制。

一、服务可见性

服务元数据平台负责维护服务相关的元数据信息，主要包括服务层面、接口层面、拓扑层面这几个维度的元数据信息，通过服务元数据平台，可以对系统提供全方位的可见性。为了增强服务查询的灵活性，可以支持多种服务查询方式，比如按照服务所属部门查询、按照服务属性查询等，服务基本信息平台化等。服务基本信息如下。

1）服务描述：简要描述服务提供的基本能力，服务的适用场景等，供潜在服务使用者参考，必要时可以加上服务的详细描述信息 wiki，以及服务对应的邮件组和沟通群。

2）服务所有权：服务当前所属部门、服务当前的 owner 等。

3）服务对外接口：服务接口定义，使用说明和注意事项等。

4）服务 SLA：服务对外的 SLA 承诺。

5）服务的上下游拓扑：服务商城中维护了每个服务的上下游依赖，基于上下游依赖，不仅可以查询上下游服务的使用方式和使用情况，同时也可以进行服务重大变更时的上下游服务通知。

6）服务变更：服务商城中维护服务每个重要变更的变更日志，重要变更时会通过相应机制知会上下游依赖，上下游会评估是否需要适配升级等，这样服务使用者可以从变更历史中了解到服务的整个发展脉络。7）服务接入和资源配额管理：服务如何接入，资源配额如何申请等。

8）服务线上部署和线下测试环境信息：描述了服务线上和线下的部署信息，使用者直接基于平台给定的环境使用。

二、变更可见性

变更是引发系统故障的主要因素，通过对各个维度的变更进行系统的梳理和记录，不仅方便出现故障时的追溯和定位，后续还可以基于完善的变更事件库，对这些变更的原因、质量以及影响进行全面的审计和分析，从中找到规律性的东西，建立相应的改进反馈闭环。

服务变更是变更的最重要来源，常见的服务变更方式有应用变更、配置变更、数据变更以及预案变更等。对于微服务架构来说，除了关注当前服务的变更之外，还需要关注上下游依赖服务的变更，以及部署层面关联服务的变更，比如和当前服务混部在同一台物理机上的其他服务变更。

除了服务变更，还需要对服务周边的各个环境变更进行记录，比如网络变更、机器变更、机房变更、交换机变更，这些变更都可能对服务的正常运行产生影响。

三、观测可见性

微服务架构下，各个微服务采用分布式部署，并且通过网络进行分布式通信，随着微服务个数和集群规模的扩大，系统中会产生各种形式的故障，并且很多故障是无法事先预测的。因此需要微服务观测可见性，具体分为 Logging（日志系统）、Metrics（度量系统）和 Tracing（分布式跟踪系统）3 个层次。

• Logging 系统日志

用于对系统中离散的事件进行记录，比如服务的调试信息和错误信息，日志是系统监控的基石，也是服务状态监控和问题诊断的第一个抓手，通过日志可以大体判断系统的运行状态是否正常。日志是最常见、最通用的监控手段，但服务的日志监控和告警一般都需要人工添加，不仅效率低，也很容易遗漏。同时不同服务的日志格式和日志信息可能都会有差异，不太方便进行标准化，不仅日志收集、处理和展示比较麻烦，有太多个性化的需求，而且每个服务的日志都不统一，基于日志的全系统问题定位也非常麻烦。

• Metric 系统

为了提高日志和监控的标准化，引入了 Metric 的概念，Metric 就是将日志中可以聚合的部分通过标准化的协议进行处理，Metric 定义一套完善的日志收集、传输和处理标准，通过 Metric 可以实现日志和监控的标准化，同时基于 Metric 的日志聚合特性，聚合后的日志会小很多，减少日志系统的成本开销。

• Tracing 系统

Tracing 用于记录请求级别的信息，它会跟踪请求整个链路的执行过程和各阶段耗时信息，基于 Tracing，可以定位请求性能问题和跨服务交互相关的问题。