透過本篇文章您可以瞭解到以下內容：

  • 回顧
  • Snap-E簡介
  • Snap-E具體實作流程
  • Snap-E的具體實例
  • 總結

回顧

首先讓我們做一個簡單的回顧：

在上一篇文章中我們談到了Boris，我們瞭解到Boris是一個動手實作的過程，這個過程需要該領域的專家以及技術人員一同參與，使用簡單的工具（例如：貼紙、白板、筆等）

透過對微服務彼此以及微服務與外部系統交互的梳理，我們可以很清晰的瞭解到每個微服務間是如何交互作用以及交互方式。

至此，進一步思考，我們可能會面臨以下問題：

  • 怎麼展現每個微服務的具體資訊呢？（ 例如：有多少個APIs，資訊實際狀況為何？ )
  • 針對於第一點，這些資訊又是怎麼獲取的呢？

那麼帶著這些問題讓我們來開始今天的主題Snap-E。

Snap-E 簡介

Snap-E是英文的縮寫，全稱為： Snap Not Analysis Paralysis – Enhanced.

簡單的理解，我們可以透過Snap-E清楚的了解某個具體微服務內部結構資訊，比如這個微服務內部包含多少個APIs、資料實體，是否存在UI介面，是否與外部系統交互等。

（真實場景圖）

Snap-E 具體實作流程

WHEN 什麼時候才會進入Snap-E 階段？

透過Boris我們將微服務之間的交互進行建模和梳理。 在Boris過程中，我們可以同時進行Snap-E，從而實時的記錄下微服務的元素。

WHY 為什麼要進行Snap-E？

Boris只是從微服務這個層面進行系統梳理分析，那麼針對於每一個微服務內部的構造我們需要進行剖析，透過Snap-E可以使我們很清晰的看到每一個微服務內部的構造。

WHAT 想要完成Snap-E，我們需要進行哪些準備？

  • 在進行Boris的同時，Snap-E模版將被進行填寫。
  • 會議室（較大的開放空間）技術人員、領域專家等成員之間有充分討論。
  • 便條紙（各種顏色，用於代表不同意義，例如API、DATA等）。
  • 筆 （最好每個人一支），用於在便條紙上書寫。
  • 白板用於黏貼便條紙。

整個Snap-E階段就是根據Boris結果進行對每一個微服務分析，在Snap-E模版中包含了若干元素，那麼這些元素又代表了什麼意思呢？  接下會和大家詳細說明下， 如下圖所示：

Service A

對應的是Boris中微服務的名字，可以理解為，有一個service A的微服務，通常針對每一個微服務我們使用一頁Snap- E進行表示。

API

根據Boris中的約定，例如使用REST Call方式進行交互，此時APIs代表的是該服務對外露出的服務介面。

DATA

顧名思義，代表的是該服務所涉及到的數據資料Entity。

PUB/SUB

顧名思義，某些微服務可能會存在使用異步消息的情況，這裡面分別指的是接收亦或發送消息。

EXT

代表該微服務是否存在與週邊系統聯繫，這裡我們可以標註外圍系統的名字。

STORIES

來源於Boris中的命令（這個命令可以理解為GET、UPDATE、DELETE等操作），這裡將命令進行簡單的描述封裝。

UI

代表該服務是否存在UI介面。

RISK

代表可以遇見的一些風險。

至此，我們已經了解如何完成Snap-E需要的準備工作，以及Snap-E模版中元素具體的含意，那麼接下來我需要知道的是模版元素的來源，答案就是 Boris。

換而言之，在進行Boris過程中，會對微服務之間的調用關係，命令越來越清晰，在這個過程中，我們可以即時的快速記錄所需要的元素並將這些元素填充到Snap-E的模版當中。 如下圖所示：

Snap-E 的具體實例

透過上述的介紹，相信大家對Snap-E的概念，以及實施流程有較為清晰的理解。 接下來我們以用戶註冊為例子，再來回顧整個流程。 此處會結合之前文章Event Storming以及Boris中提及的部分內容。

第一步，我們需要進行Event Storming，也就是對於有關使用者的Event進行結合，並形成了對應的微服務，我們稱之為USER。 另外將所有關於訂單的Event進行結合，形成另一個微服務ORDER。

第二步，我們利用Boris對USER和ORDER這兩個微服務之間的調用關係進行分析，建模。 同時這裡面會涉及到外部系統。 結合業務流程，比如USER可能會發起一些驗證消息，用於客戶註冊時的驗證、訂單服務獲取用戶資訊等。 從而進一步我們會逐步發現若干個命令（此處的命令可以理解為服務之間的GET、UPDATE、DELETE等操作）。

第三步，Snap-E模版的填寫，以USER微服務為例，此時我們根據上一步驟Boris產出的結果作為輸入，我們知道的是ORDER微服務會向 USER微服務發起一個REST Call，所以此時USER微服務應該對外提供一個服務，也就是暴露出一個API，另外，ORDER 需要從USER中獲取使用者資訊，那麼USER服務中應該保存一個關於用戶數據的實體。 映射到Snap-E中就是API以及DATA元素。

第四步，另一方面，我們可以看到，USER服務在完成使用者資訊註冊的業務流程中，需要和外部系統進行交互，這裡面指的分別是身份校驗系統以及簡訊通知系統。 所以映射到Snap-E中就是Ext元素。

第五步結合第四步，我們知道USER服務與兩個外部系統進行了交互，而且與簡訊通知服務採用的是異步操作，即可以理解為USER向外部系統發送了一個註冊成功的簡訊通知消息，與身份校驗服務採用的是同步調用，即獲取身份資訊校驗結果。 而對於異步發送消息的操作映射到Snap-E中就是PUB元素。

第六步，在上述Boris中存在三個命令，分別是獲取使用者資訊、身份資訊獲取驗證結果、註冊成功發送簡訊。 我們可以將這三個命令進行相對較為詳細的描述，例如，針對於獲取使用者資訊，我們可以描述成，USER服務接收到了一個獲取User資訊的請求，來自於ORDER 服務。 而對於這種命令的描述封裝，就是STORIES元素。

以此類推我們用這種方式，就可以完成整個系統微服務的Snap-E建模。

總結

回顧全篇內容，整體包括以下內容：

  • 首先在開篇我們瞭解到了Snap-E的含意。
  • 其次介紹了Snap-E的整個實作流程，在實作流程的章節中，闡述了為什麼要進行Snap-E、Snap-E的準備工作等內容， 同時宏觀的闡述了整個Snap-E的流程。
  • 最後結合例子進行再次說明Snap-E整個過程。

至此微服務拆分的三把利器Event Storming、Boris、Snap-E已經全部向大家介紹完了，我們可以看出，Event Storming 是將現有的業務流程進行梳理，也可以說它的輸入就是業務流程，輸出是微服務;  Boris是將微服務之間的交互進行建模，形成全域的拓撲圖，這裡的輸入是Event Storming，輸出即是微服務，而Boris的輸出是全域系統交互方式， 微服務彼此交互（這裡的交互指的是Boris中的command）。 Snap-E則更進一步，是將每一個微服務具體化（包括哪些API、DATA、UI等），它的輸入正是 Boris的輸出。

雖然我們使用了這三把拆分的利器完成微服務的拆分，但是接下來我們需要的是有一個強有力的、高效並且開箱即用的技術框架支援我們開發落地工作，作為JAVA世界最受歡迎的Spring這時候登場了，在下期的文章中我會繼續和大家就Spring進行交流分享，敬請期待！

參考連結：

  1. https://tanzu.vmware.com/developer/practices/swift-method/

作者簡介

李剛，VMware 大中華區應用現代化部門高級系統架構師，資深企業級軟體開發和軟體系統架構師。 Spring Cloud開源社區項目貢獻者、Netflix開源社區貢獻者。 近幾年，參與並主導了許多大型企業客戶的應用現代化數位轉型專案，涉及物流、製造、金融等諸多領域。 特別對微服務實現方法、現代化應用架構設計、雲原生實施落地、開源軟體技術等方面有著豐富經驗。