请关注于进程,而非单独的微服务

  • Jan Stenberg
  • 刘嘉洋

2016 年 12 月 27 日

话题:语言 & 开发架构

当使用基于分布式系统的微服务时,成功的关键是关注于分布式进程作为一个整体,而不是关注于微服务本身。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

语言 & 开发架构