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

一、服务可见性

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

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,可以定位请求性能问题和跨服务交互相关的问题。