雲原生時代下微服務架構演進之路 (5)

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

• 回顧
• Boris歷史、由來
• Boris具體實施流程
• Boris的具體例子
• 總結

回顧

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

在上一篇文章中我們談到了Event Storming，我們瞭解到，Event Storming是一個動手實踐的過程，這個過程需要我們的領域專家以及技術人員一同參與，使用簡單的工具（例如貼紙、白板、筆等） 透過對事件的描述，流程的梳理，我們逐步瞭解到了整個系統的業務流程（Business Flow），隨著Event Storming的完成，我們也初步知曉了整個系統包括多少個微服務。

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

• 每個微服務彼此交互的方式是怎樣的？
• 微服務與外部系統交互方式是怎樣的？
• 整個系統全域的拓撲圖是怎樣的？

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

Boris歷史、由來

首先我們來看下什麼是Boris

英文：

確定複雜系統中服務之間的關係，以揭示名義上的目標系統體系結構，並使用 SNAP 記錄它們

中文：

確定複雜系統中服務之間的關係，以揭示概念上的目標系統體系架構，並且使用SNAP進行記錄。 （這裡提到的SNAP我會在下一篇文章中向大家介紹）

如果用一句相對白話的方式去解釋Boris，可以理解為Boris描述了整個系統微服務以及微服務與外部系統的關係和交互方式。

Boris是由Pivotal（現已經回歸到VMware）的Shaun Anderson在2016年發明的，下圖向 您展示一個真實場景下Boris的樣子。

大家不難看出，Boris整個樣子和蜘蛛網很相似，這也是它名字的來源，其實Boris的名字是以一首歌曲的名字來進行命名的，歌曲的名字叫做“Boris the Spider”。

至此相信大家對Boris有了一個初步的瞭解，接下來讓我們來看看Boris具體實施的流程是怎樣的。

Boris具體實施流程

什麼時候才會進入Boris階段？

Event Storming的產出物即是若干個微服務，當我們完成Event Storming以後，可以採用Boris將這些微服務之間的交互進行建模和梳理。 從而可以對複雜的系統進行分析並且了解整個運作模式。

為什麼要進行Boris？

我們透過完成Event Storming，可以很好的拆分出微服務，但是此時對微服務之間的交互，關係等並沒有一個全域的視圖進行表達。 透過Boris（例如每個微服務之間是怎樣交互的，是同步還是異步，外部系統又有多少，它們與微服務之間的關係又是怎樣的等）可以幫助我們理解系統全域的拓撲。

想要完成Boris，我們需要進行哪些準備？

• Event Storming的產出物（若干個微服務）
• 會議室（較大的開放空間），用於技術人員、領域專家等成員之間的充分討論。
• 便條紙（各種顏色，用於代表不同意義，例如Service、Topic等）。
• 筆（最好每個人一支），用於在便條紙上書寫。
• 白板用於貼便條紙。
• 不同顏色的膠帶（用於展現微服務之間的交互方式，例如同步、異步）

此外在進行Boris過程中，我們需要使用不同顏色的貼紙以及膠帶，不同顏色代表的含義不同，如下圖所示：

服務

來源於Event Storming，當我們完成Event Storming後，產出了微服務（這裡的微服務並不一定是最終的微服務，我們可以在Boris或者SNAP 中對微服務進行再次拆分以及合併）。

主題

使用異步模式下的收發消息內容。

外部系統

Boris不僅僅展現了微服務之間的關係模型，同時也會包含微服務與外部系統關係。

同步

代表微服務之間交互的方式，這裡代表的是同步，例如REST Call。

異步

代表微服務之間交互方式，這裡代表的是異步，例如使用MQ進行消息的收發。

至此前期準備都已經完成，接下來讓我們看下整個流程是怎樣的。

首先是將Event Storming產出的微服務進行蒐集，把這些微服務以新的藍色貼紙方式進行蒐集，並且粘貼在事先準備好的白板上。

在蒐集完所有微服務之後，我們可以在此基礎上進一步探索。 接下來要考慮的是每個微服務之間亦或微服務與外部系統的交互方式（同步的REST Call還是異步的MQ消息通知），並且用不同顏色的膠帶進行連接。

在確定微服務之間的交互方式後，例如服務A和服務B的交互方式為REST Call即同步，我們還需要在此方式上添加對應的命令， 對於命令的理解可以認為是GET、UPDATE、DELETE等操作，比如服務A想從服務B獲取訂單資訊， 那麼對應的命令就是Get Order，我們可以用貼紙記錄下來。 需要注意的是，這種命令是存在方向的，因為是服務A從服務B獲取，所以對應箭頭的方式應該是從A到B。

當我們完成了上面的三個步驟後，最終形成Boris的樣子如下圖所示：

Boris的具體例子

透過上一章節的介紹，相信大家對Boris中的概念，以及實施流程有了較為清晰的理解。

可能有些概念較為隱晦抽象，同時Boris本身是以動手實踐為主的形式，所以為了更好的加深我們對整個流程的理解和認知，接下來我們以上一篇文章中介紹Event Storming例子為基礎，即用戶註冊， 再次來回顧下整個流程。

第一步，通過Event Storming的產出我們得到了有關使用者的所有Event，並且聚合成了對應的微服務，結合例子此時微服務我們可以稱之為USER。 此外我們把有關訂單的Event聚合成另外一個微服務，我們這裡稱之為ORDER。 我們把這兩個微服務重新書寫到新的藍色貼紙上，並貼在事先準備好的白板上。

第二步，按照業務流程，USER微服務會在使用者註冊的時候向外部系統發起使用者資訊的校驗，比如姓名和有效證件是否真實有效，所以這裡我們增加一個黃色的貼紙，它代表著外部系統即身份校驗，同理，在完成用戶註冊後，我們可能會向相關使用者發起簡訊通知，這裡會存在另外一個外部系統，我們稱之為簡訊通知服務。

第三步，按照實際業務情況，USER服務會發起同步的一個請求給身份校驗外部系統，這個請求附帶著用戶對應的相關訊息，所以我們用藍色的膠帶代表著這是一個同步請求（REST Call），這次請求我們會得到 驗證通過或者不通過的資訊，所以箭頭的方向是USER服務到身份驗證服務。

第四步，同理第三步，當驗證通過後，我們需要向簡訊通知的外部服務發送一次請求，用來給對應使用者發送使用者註冊成功的簡訊提示，此時可以是異步的操作，即將對應簡訊的內容，模版等資訊以消息佇列MQ的方式發送出去，所以我們可以採用紅色的膠帶進行表示，同時箭頭的方向是 USER服務到簡訊通知服務。

第五步，用於訂單系統在處理訂單的時候需要用到對應客戶的相關訊息，即訂單服務會向USER發起一個同步調用（REST Call） ，所以我們用藍色膠帶進行表示，同時箭頭的方式是從ORDER服務到USER服務。

以此類推我們用這種方式，就可以完成整個系統微服務之間的交互模型。
 
 
總結
·       回顧全篇內容，整體包括以下內容：
·       首先在開篇我們瞭解到了Boris的定義，以及Boris的歷史、由來。
·       其次介紹了Boris的整個實施流程，在實施流程的章節中，闡述了為什麼要進行Boris、Boris的準備工作等內容，以及 Boris過程中使用不同貼紙、膠帶代表的含義，同時宏觀的闡述了整個Boris的流程。
·       最後結合例子進行再次說明Boris整個實施過程。
 
當我們完成Event Storming以及Boris，微服務拆分的三把利器已經完成了三分之二，作為最後一步的Snap-E也應該登場了， 那麼什麼是Snap-E？  它是實踐流程又是怎樣的？  對於上述問題，在下期的文章中會繼續和大家進行交流分享，敬請期待！
 
參考連結
https://tanzu.vmware.com/developer/practices/boris/

作者簡介