微服務邊界

banq發表於2016-12-07
微服務
在這篇文章中，作者討論了他最近學到的關於從不同的角度識別微服務邊界的一個教訓。

微服務架構是當今的熱門話題。 儘管它的複雜性（分散式事務，最終的一致性，操作開銷），這些都是不可避免的，但是它提供了許多好處（多邊形架構，選擇性可擴充套件性，強模組化，容錯，實驗，敏捷等）。

微服務可能不是新東西。 我仍然記得，回到2011，我研究了一個SaaS產品，其中我們試圖構建包含不同有界上下文的類似架構，包括敏捷專案管理，問題跟蹤和協作。當時我們不熟悉這種奇特的微服務術語，但我們試圖實現的好處有助於微服務架構的實現。

最初，在各種模組中分發應用程式的設計工作得很好，但我們在整合期間搞砸了。並不是透過採用事件驅動架構在不同模組之間共享資訊，而是直接同步呼叫。這使我們遠離了獨立部署，開發和執行時的原始動機。

本文討論的是從我最近的一個專案中學到的另一個教訓，幫助您從不同的角度識別微服務邊界。

背景
下一代邊境（NGB）系統是護照控制系統的改進版本。NGB的主要目標是加快機場移民櫃檯接待處理乘客的過程。 透過將處理時間從平均56秒減少到10秒來改善乘客體驗。下面是一個上下文對映流程。

航空公司旅客銷售服務系統(PSS) --> 高階旅客資訊系統 --->自動入境預檢上下文 --->旅客邊境控制上下文 --->通知上下文

NGB系統的核心是入境預檢處理（preclearance process）。入境預檢過程通常在乘客登機前72小時開始。 航空公司將預訂資訊傳送到入境預檢旅客資訊系統，該資訊系統將資訊轉發給NGB系統進行入境檢查。 在入檢期間，NGB在移民系統的幫助下對旅客的資料執行各種檢查，並將結果傳送到後臺進行審查，以便在乘客因任何問題（即黑名單）被認定有罪時進行審查。 發現無罪的乘客標記為綠色，在入境櫃檯處理此類乘客需要幾秒鐘。


什麼是好？
由於大多數文獻指出在根據語言邊界作為有界上下文來定義微服務邊界，NGB被劃分為自動入境預檢，乘客邊境控制和通知有界上下文。 自動入境預檢上下文在後臺處理預留資料流，並將其傳遞到用於永續性和人工干預的乘客邊境控制上下文。 該上下文具有兩個主要類別的使用者：前臺使用者，其是面向乘客的使用者，以及後臺使用者，其在沒有任何問題的情況下處理乘客。通知上下文，如其名稱所暗示的，用於向系統使用者傳送通知。

什麼地方出了錯？
雖然通用語言在旅客邊境控制上下文中是顯而易見的，但是這仍然不夠。 隨著時間的推移，旅客邊境管制的情況不僅開始變成鐵板一塊monolithic，而且進入生產運作變更時開始出現麻煩。 我們對後臺運營所做的任何更改都必須仔細進行，以避免對前臺運營造成任何影響。此外，任何影響後勤辦公操作的更改都不能在不影響前線操作前提下單獨部署，反之亦然。

我們能做點什麼？
在討論我們可以做點什麼之前，讓我們快速看一下NGB系統的業務流程檢視，如下所示：

後臺處理：自動入境預檢 ---> 後臺辦公處理：乘客名單審查 ---->前臺處理：旅客邊境控制

箭頭表示業務流程發生在不同的時間線。 例如，入境預檢資訊通常在航班起飛前72小時收到，後臺辦公室使用者在出發前幾個小時審查乘客，而乘客到達櫃檯時將進行乘客護照控制。

如果您注意到前面的上下文對映，後臺處理：自動入境預檢過程已經被劃出一個單獨的有界上下文中，而後臺程式和前臺過程被捕獲在單一的旅客邊境控制上下文中。他們被放入同一有界上下文的原因是因為語言邊界。

現在讓我們做點不同的，將旅客邊境控制上下文進一步分為三個不同的上下文，後臺辦公室和前臺邊境控制上下文將保持乘客領域模型作為上下文共享核心的最小結構，而完整的旅客領域模型將在旅客出行上下文中作為event-sourced。 三個上下文將在各種時間點傳送事件，例如自動入境的開始，後臺的審查，前臺的乘客旅行記錄等等，這些事件傳送到旅客出行上下文。這樣旅客出行上下文將像一個無頭的微服務。 此外，這也將分離的讀取和寫入的責任（ CQRS NGB系統內）。

在這種分配方式中，旅客邊境控制上下文不僅會降低因後臺和前臺的變更影響，而且還將有助於獨立地發生自己的變更。 這種方法的唯一權衡是我們必須在多個上下文中保留旅客領域模型的多個副本。 為實現凝聚這是不可避免的。

最後的想法
從有界上下文視點確定微服務邊界可能是一個好的開始。僅依賴有界上下文視點可能不總是足夠的。 其他觀點對於確定微服務邊界也是至關重要的。像選擇擴充套件性，可更改性，可部署性，可測性，業務流程和組織結構的通訊（康威定律 ）也影響微服務邊界。

A Retrospective on Microservice Boundaries - DZone

相關文章