InfoQ 近期采访了 Ben Sigelman，探讨在“深层系统”（deep system）中管理微服务所面对的挑战性问题。在“深层系统”中，服务的拥有者需要与大量不属于该服务拥有者的其他服务进行交互。Sigelman 是 LightStep 的 CEO，也是 OpenTracing 和 OpenTelemetry 项目的创始人。
Sigelman 最近在 Systems@Scale 大会上做主题演讲时指出，问题主要在于如何区分控制和责任，以及团队如何准确地判定每个服务内部及相互之间的作用情况。开发团队通常控制着多个服务，这些服务需要调用其他的服务，或是被其他服务调用。尽管相互关联的服务通常并不属于同一团队，但是它们为连接的服务继承责任。随着服务间的相互调用，调用关系链趋向于更加深入，团队难以快速诊断导致故障或运行性能降低等问题的原因。
不同于标准的性能监控，微服务间通信模式的变化会潜在地影响微服务的性能。例如，监控显示某个服务使用设定参数运行时，性能发生了降低，但是问题的根源却可能是由不同的服务调用方式使得服务需求显著增加而导致的。
解决微服务问题的关键，是需要在服务内部启用可观察性（observability）和控制，快速定位存在性能问题之处，是位于微服务内部，还是位于微服务之间，消除一切的不确定性。Sigelman 指出，“数据不明晰，责任就会互相推诿。对于出现的问题，可使用一种称为MTTI（即平均解决问题时间， Mean-Time-To-Innocence ）的度量指标。数据明晰，MTTI 值就会很低。如果数据缺失，或是不明晰，那么 MTTI 值就会变大”。MTTI 值变大，就需要相关人员做长时间的协商，分析导致问题和故障的根本原因，进而导致运维代价增大。
“可观察性”指无需更改服务就能快速发现服务内部及相互之间存在问题的能力，“控制”指对所发现问题的处理能力。可观察性的目标是获取控制。OpenTelemetry 项目为实现可观察性和控制提供了标准化工具。该项目支持多种工具，以正确的方式抽取正确的度量和 KPI，由此每个团队可采取相应的行动。
下面给出 InfoQ 与 Ben Sigelman 的访谈记录：
InfoQ：OpenTracing 和 OpenTelementry 项目两者间是什么关系？
Ben Sigelman: OpenTelemetry 提供了一个标准，定义了遥测数据和结构及其要采集的内容。可以说 OpenTelemetry 为此打开了一扇大门。OpenTracing 的功能类似，但针对更细分的领域，专门设计为一种分布式追踪工具。对于新上手的用户，我推荐关注 OpenTelemetry。其功能更为丰富，并推动着 OpenTracing 向前发展。
InfoQ：您在主题演讲中提出了“深层系统”（deep system）这一概念。为什么系统会演化为“深层”的？深层系统解决了哪些问题，又会引入哪些新问题？
Sigelman：当人们谈及微服务时，通常考虑的是服务本身，而非整个大系统的全貌。系统中如果存在大量的微服务，那么就会演变为一种深层系统。系统不仅是多个服务，而且存在多个层面。对于 500 个服务，问题不仅仅是一个路由或 API 网关需要与其它 499 个服务通信，而是 500 个服务相互之间的通信。服务的性能，取决于依赖关系中性能最低的服务。每增加一个层面，出错的方式也会相应地增加。
业界转向微服务，究其根本是为了促进各开发团队相互间的自治性和独立性。但事与愿违，系统通常会在深层领域产生摩擦和低效，导致整体性能降低。这是因为微服务相互间的问题难以追踪，相互间的复杂依赖方式难以为人所理解，并且难以确定恢复 SLO（服务等级目标，Service Level Objective）所需调整的服务。
InfoQ：控制和责任应如何纳入到微服务中？
Sigelman：在任一系统中，都需要掌控层层嵌套的依赖调用关系，但开发人员只能掌控自身可构建和部署的服务。在深层的系统中，随着系统深度的增加，依赖关系树的规模会呈几何级别增长，同时度量标准和日志记录数据多到无法使用常规工具筛选。解决此问题的唯一方法，就是利用作为可观察性系统核心功能的数据追踪特性。追踪数据是唯一能够提供系统各层相关上下文的数据。
InfoQ：对于 Java，OpenJDK 团队近期开源了 Flight Recorder/ Mission Control ，它们实现了低开销的 JVM 性能监控。与之相比，OpenTelemetry 具有哪些过人之处？
Sigelman：Flight Recorder/Mission Control 非常适合查看单个给定的 JVM。但对于微服务，问题则有所不同。大多数企业内部发生的技术灾难（technical fires），都是由代码或配置推送所导致的。例如，上游团队会将服务调用方式从 1 次提高到 100 次（尽管他们不应该这样做）。这时，性能剖析工具会给出显示，代码正处于频繁运行状态。但此类性能剖析工具无法给出导致代码频繁运行的原因，以及这段代码与其它服务的关联关系。但如果用户的确只需分析单个 JVM，那么此类工具完全胜任。
InfoQ：OpenTelemetry 在深层服务中获取可观察性方面，团队需要注意哪些关键方面？
Sigelman：服务的成功与否，判定权应在服务的消费者。这意味着，需要建立衡量成功的 SLI/SLO ，例如响应时间、错误预算等度量。服务开发者应该了解服务消费者的关注点，并据此制定准确的目标。如果从 SLI/SLO 着手开展调查，那么一个可观察性系统就能知悉开发人员需要去解决的问题。这将大大缩减查找潜在问题根源的规模和范围。
InfoQ：如果由团队去定义消费者的需求，那么存在哪些听上去很诱人的但实际上会带来麻烦的概念？
Sigelman：首先，追踪 CPU、RAM 等系统基础指标，通常无法指示问题根源所在。其次，微服务团队常认为松耦合意味着完全独立和自治，可做出完全不同的决策。例如， Netflix 提供了运行良好的工具和框架，为此“铺平了道路”。一旦人们选择这些现成工具时，就将获得受支持的编程语言、软件库、安全检查等一系列帮助。如果采取完全自主开发这条路，另辟蹊径会增加控制难度，因为其他团队难以立刻提供帮助。
InfoQ：对于需要分析复杂微服务的人而言，您可否推荐一些特定的工具？
Sigelman：OpenTelemetry 是推进现代可观测性的先行者，它支持集成到已有系统中，收集高质量的遥测数据。团队可借助 Auto Instrumentation Agent ，无需更改任何代码实现上述功能。该 Agent 支持数据访问，但不提供任何分析工具。对于需要遥测数据分析和可视化的用户，我个人推荐使用免费的 LightStep tier 。
我和Honeycomb 的 Liz Fong-Jones 都会定期在 Twitter 上深度探讨微服务管理相关的话题。
原文链接：
评论