未来机构——观察分布式服务

本文节选自新书《未来架构：从服务化到云原生》。

互联网架构不断演化，经历了从集中式架构到分布式架构，再到云原生架构的过程。云原生因能解决传统应用升级缓慢、架构臃肿、无法快速迭代等问题而成了未来云端应用的目标。

本书首先介绍架构演化过程及云原生的概念，让读者对基础概念有一个准确的了解，接着阐述分布式、服务化、可观察性、容器调度、Service Mesh、云数据库等技术体系及原理，并介绍相关的SkyWalking、Dubbo、Spring Cloud、Kubernetes、Istio等开源解决方案，最后深度揭秘开源分布式数据库生态圈ShardingSphere的设计、实现，以及进入Apache基金会的历程，非常适合架构师、云计算从业人员阅读、学习。

 

服务化的发展，以及容器化编排、微服务框架、Service Mesh等各项技术的持续进化，为分布式服务化提供了技术层面的支持。但是，仅仅构建微服务是不够的，对于一套完整的技术体系而言，除了开发，还需要运维给予强力支持。随着微服务架构的持续演进，应用和服务数量不断增加，调用关系越来越复杂。所以，从运维的角度来看，首要任务便是保持可观察性（Observability）。

CNCF赋予了可观察性极高的地位，可观察性和由操作系统、底层网络提供商构成的平台层（Platform）一样，贯穿整个云原生体系。

变化是微服务的本质，也是应用系统设计和开发中唯一不变的准则。因此，无法通过一张静态的架构图来描述微服务架构下的系统部署情况。微服务集群的组成元素、依赖关系、流量分布以及外部边界等都会随着时间发生变化，虽然微服务技术降低了应对变化的难度，但运维团队却依然需要明确地了解系统的运行情况，这就是微服务系统对可观察性的诉求。

可观察性提供了穿越微服务边界的能力，它先对应用数据或管理平台数据进行观测及后台分析，然后通过高度可视化系统，直观地将系统当前的状态展现出来。

1.层次划分

根据观察层次的不同，谈论可观察性时一般涉及基础设施层、工具层和应用环境层。

• 基础设施层：对云主机、操作系统、云服务进行包括可用性在内的基础指标监控，提供云服务商的基础运维支撑能力。

• 工具层：编排工具的可观察性是微服务体系中的重要一环，随着容器化的不断推进，对Kubernetes和Mesos等容器编排生态工具的监控也越来越多样化。另外，由于DevOps体系的发展，相关工具链（如Git、SVN、CI/CD等）的可观察性也成为当今的关注焦点。

• 应用环境层：应用环境层的可观察性是指对应用服务器、数据库、消息队列、缓存等中间件组件进行观察。

由于基础设施层的监控和系统健康度观察大多由平台提供商直接负责，而工具层的解决方案基本是由其核心产品以及周边生态提供的，因此对于微服务和云原生应用开发者来说，关注点应集中在应用环境层。应用环境层因为涉及业务系统，所以场景变化也是最多的。下面我们将具体讲解如何进行应用环境层系统观察。

2.核心概念

日志（Logging）、指标（Metrics）和追踪（Tracing）是紧密相关的三个核心概念。通过图5-2所示的韦恩图，我们能够很清楚地了解这三者之间的关系。

图5-2  日志、指标和追踪的关系

• 日志描述的是一些不连续的离散事件。例如，有些业务系统采用ELK（Elasticsearch +Logstash + Kinaba）或类似技术栈的日志收集系统，它们是分布式监控系统的早期形态，借鉴了传统应用解决问题的方式，是最容易理解的解决方案。

• 指标是可累加的，它具有原子性。每个指标都是一个逻辑计量单元，体现了一段时间之内相关指标的状态。

例如，队列当前的深度可以被定义为一个计量单元，在写入或读取时更新；输入HTTP请求的数量可以被定义为一个计数器，用于进行简单累加；请求的执行时间可以被定义为一个柱状图，在指定时间片上更新和汇总。

CNCF生态中的Prometheus监控系统正是基于指标的典型系统，它通过定义和收集不同的指标数据，以及提供基于时间维度的查询能力，为分布式服务指标提供基础数据保障。

• 追踪在监控领域通常被称为分布式追踪，是指在单次请求范围内处理信息。任何的数据和元数据信息都被绑定到了系统中的单个事务上。追踪能力是近几年技术人员最为关注的需求，由Twitter开源的ZipKin是目前运用最为广泛的分布式追踪系统。

上面介绍的三个概念并不是相互独立的，往往会有一定的重叠，复杂和完善的监控系统一般是跨越多个维度的，下面我们具体来介绍一下。

• 追踪+日志：这是多数分布式追踪系统的早期形态，通过简单的上下文传递，可以将请求的上下文ID输出到日志，让日志具备时间维度之外的另一个关键维度——上下文关联。通过时间和上下文关联这两个维度的组合，用户可以快速感受到分布式追踪带来的强大优势。

• 日志+指标：这是日志分析系统的常规架构，可通过解析系统现有的业务日志获取相关的指标数据。

•  追踪+指标：用于指明基于分布式追踪的数据分析指标、应用间的关系以及数据流向等。

日志、指标、追踪可以看作功能全集中的元素，一些商业级别的APM（Application Performance Management，应用性能管理）系统便采用“追踪+指标”的方式提供一体化的解决方案。充分理解这三个概念，能够更好定位目前市面上的各种开源和商业监控体系工具，理解它们的核心优势。

下面我们重点介绍一下与分布式追踪系统相关的内容。

3.分布式追踪

分布式追踪的概念源自最早面对超大规模分布式场景的Google公司于2010年发表的论文——Dapper, a Large-Scale Distributed SystemsTracing Infrastructure。论文中详细地介绍了Google的Dapper系统及其实现原理，此处我们不再介绍论文中的内容，感兴趣的读者可以自行阅读、学习。

Dapper的核心实现方法是在分布式请求的上下文中加入span id以及parent id，用于记录请求的上下级关系。分布式追踪的示意图如图5-3所示。

阿里巴巴公司曾经分享过鹰眼系统的实现方案，也是国内早期的分布式追踪系统实现方案。鹰眼系统使用类似书签索引的方法，简化了parent id和span id的表达方式，其请求流程如图5-4所示。

图5-3  分布式追踪的示意图

图5-4  鹰眼系统的请求流程

鹰眼系统与Dapper在原理上没有本质区别。之所以在此刻意提及，是因为鹰眼系统的编码方案可以帮助读者理解Trace树形结构。但是，需要强调的是，Trace并非只有树形结构，对于消息消费、异步处理等批量模型，会出现一条Trace关联多个TraceId的情况。

4.常见的分布是追踪开源解决方案

Apache ZipKin是起步最早、社区体系最为完备的分布式追踪解决方案。它借助稳定的API库及广泛的集成，几乎覆盖了从开源到商业级的分布式系统的各个角落。其覆盖的语言包括Java、C#、Go、JavaScript、Ruby、Scala、C++、PHP、Elixir、Lua等，甚至为每种语言都提供了不止一种API库，更好地适应了各种不同的应用场景。

OpenTracing是CNCF托管的分布式追踪项目，它的官方定位是针对分布式系统追踪的API标准库，与厂商无关，旨在为不同的分布式追踪系统提供统一的对外API接入层。所以OpenTracing并不包含任何实现，可以将它理解为接口协议，类似于Java的数据库访问接口JDBC。

这里要强调的是，OpenTracing只是一套可选的接口API库，并非分布式追踪的实现标准，其原生支持者同样是CNCF托管的项目——Jaeger。另外，前面提到的运用最为广泛的分布式追踪系统ZipKin并不是OpenTracing的主要支持者，ZipKin具有完全独立的规范、协议和API接口。所以截止到目前，还不能承认OpenTracing是分布式追踪领域的API标准。

OpenCensus来自于Google，是2017年才崭露头角的新兴项目。它的定位介于OpenTracing和ZipKin之间，提供了统一的API层，同时提供了部分实现逻辑。工程师只需在OpenCensus的基础上自定义实现最小范围的逻辑（如上下文传递和数据格式上行）即可。OpenCensus目前支持发送ZipKin、Jeager、Stackdriver和SignalFx格式的数据。OpenCensus在Google的大力支持下，已经成了OpenTracing的有力竞争者，同时，它很有可能在不久的将来开源部分后端功能，成为ZipKin的挑战者。

总之，分布式追踪的API之间竞争十分激烈，而且会愈加激烈。因此，在选择和使用API时，需要特别注意。如果团队需要自创一套API，也可以从现有方案中学到不少的设计理念。

 

要想了解更多精彩内容，，毫不犹豫地与《未来架构》相见吧！为了感谢大家的支持，我们将在留言评论的读者中抽取一人，赠送本书。