當使用基于分布式系統的微服務時，成功的關鍵是關注于分布式進程作為一個整體，而不是關注于微服務本身。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
京公網安備 11010502049343號