可观察性和微服务

InfoQ 最近报道了 Ben Linders 与 Poppulo 的 SRE（站可靠工程，Site Reliablity Engineering）经理 Pierre Vincent 就“可观察性和分布式系统”问题的访谈。近几年，InfoQ 针对“可观察性”推出了多篇文章，特别是对“无服务器”和“微服务”的关注。在该方向上，已具有一些为开发人员提供帮助的开源项目，其中包括 Prometheus、OpenTracing 和 Envoy ，以及最近推出的 Kiali 。

来自 Aspen Mesh 的 Zach Jor 最近撰文，进一步阐述了他对此问题的看法。在文章开篇，他给出了自己数年中对多个人做事情况的一个观察，即尽管将单体应用分解为微服务或许是有必要的，但是这种做法并非一定会自动形成一个更易实现的系统，系统中一些行为甚至会变得更以实现：

一个复杂性明显增加的方面就是服务间的通信。服务间通信的可见性将难以实现，而这种可见性对于构建优化灵活的架构是至关重要的。

Zach 指出，监控技术业已存在多年，目的在于给出系统整体健康状况的一个概览。而对于基于云的分布式系统（这在微服务中是十分常见的），意在提供系统行为数据的可观察性理念正变得日益重要。

可观察性主要涉及如何提供数据，以及如何使关键信息易于访问。这些关键信息是人们在通信失败时希望能查看的，但它们有时并非按人们所希望的情况给出，有时也会在不应该出现时提供。人们需要监控、管理和控制运行时服务间的相互交互方式，因而提出了可观察性以及理解微服务架构行为的问题。

Zach 认为， Istio 等服务网格（Sevice Mesh）技术的出现，使得可观察性已成为那些寻求使用服务网格或依此做开发的人们的首要需求（尽管 Zach 所在的企业具有自身的服务网格实现，但文中所给出的观点是与具体实现无关的，因此值得一读）。进而，他继续提出了可由服务网格提供的两个主要可观察性特性。第一个特性是“追踪”，用于厘清各个事务分别涉及了哪些微服务：

对于调试并理解应用的行为，分布式追踪非常有用。了解所有追踪数据的关键，就是能够关联多个与单个客户端请求相关的不同微服务。要实现追踪，应用中的所有微服务应该发布可追踪的头部信息。

第二个特性是“度量”。度量基于跨服务网格自动采集的遥测数据。应收集的重要度量包括请求量、请求时长、请求延迟和请求大小等。

微服务中的大部分故障都发生在服务间的交互过程中。因此，洞悉这些事务的内部情况，有助于团队更好地管理架构，以免发生失败。使用由服务网格提供的可观察性，人们更易于查看服务在彼此交互期间所发生的情况，从而更易于构建更为高效、灵活且安全的微服务架构。

值得关注的是，Zach 文中所谈及的一些观点，也是 2017 年底 InfoQ 在对 2018 年预测中提出的观点，即监控和可观察将成为开发人员的关键因素之一。当时， RisingStack 的 CTO Péter Márton 提出了如下看法：

要使微服务监控和可观察性更上一层楼，进而进入下一代 APM 工具的新时代，我们需要的是 OpenTracing 这样的开放、独立于软件提供商的监管（instrmentation）标准。这样的新标准还需要得到 APM 厂商、服务提供商和开源软件库维护者的采纳。

回顾近八个月期间，我们肯定能看到一些项目的出现。无论是否基于服务网格技术，这些项目正使可观察性成为微服务体系结构关键组成部分。同时，我们也看到开发人员正蓄势待发。例如，Eclipse MicroProfile 中添加了对 OpenTracing 的支持。

查看英文原文： Observability and Microservices