当使用基于分布式系统的微服务时，成功的关键是关注于分布式进程作为一个整体，而不是关注于微服务本身。 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
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论