当使用基于分布式系统的微服务时，成功的关键是关注于分布式进程作为一个整体，而不是关注于微服务本身。Eric Ess在最近的微服务伦敦大会上发表了有关如何在jet.com监控分布式进程的演说，他指出这些服务是最不重要的部分。

在Jet，由用户发起的进程至少需要几个微服务来完成，这被称为是分布式进程。工程总监Ess解释说这是他们在查看系统如何执行用户请求时的一个重要术语。

Jet如今的生产中有大约800个微服务，这是非常复杂的通信拓扑。由于这种复杂性，任何团队都不知道在其范围之外发生了什么，任何个人都不能完全理解系统架构。尽管有这样的复杂性，对于生产中碰到的问题也必须要弄清楚是什么原因导致的，以及它起源于哪个服务之上。

为了克服这个挑战，他们需要完成两个关键任务：

• 了解单个进程的行为，了解它使用了什么微服务，了解它正在做什么。通过相互交互的微服务，实现对于在系统中不同类型的进程的追踪。
• 通过明确某个进程的预期工作流来验证进程，然后验证它在执行的时候是否遵循该路径。Ess注意到即使一个进程没有产生任何错误,仍然不能正确地执行。举个例子来说就是A/B测试中的错误，导致进程以错误的方式路由，从而引起了测试数据的缺陷。

Ess注意到如果关注于分布式进程作为一个整体，而不是关注于微服务本身，他们可以忽略服务。这是将进程推向下一服务，并进一步完成进程的一种方式。他们关注的是进程的当前状态和进程发生了什么。

要实现这个必须要改变心态，工程师需要专注于系统中进程的表现，而不是微服务以及当接收消息时应该做出什么反应。团队不应该构建单独的微服务，而是能与其他服务交互的微服务。

有很多可以评估微服务和系统的工具，但不会评估执行的进程或是进程的行为。此外，Jet正在使用F#，由于很难找到合适的针对F#的工具，他们创建了自己的工具箱。

为了提供正在运行的系统及其进程的视图，他们创建了一个通信协议（Dr Orpheus），它提供了一组会进入每条消息的头部元数据，以及当接收到带有元数据消息的时候微服务必须遵守的一些规范。他们还在搭建遥感处理/数据流引擎（XRay），处理一些基本的复杂事件处理（CEP），收集每个微服务在处理消息时发出的数据。工程师和商务人士现在可以监视所有的进程，并且当其偏离设定，不遵循预定义流程，进展过慢或是在某些服务中阻塞的时候做出恰当处理。

明年的微服务伦敦大会预计会在2017年11月6日、7日召开。

查看英文原文：Focus on the Process, Not on Individual Microservices