劃分微服務邊界的5個特徵

當咱們討論微服務時，更多的是學習技術上怎麼實現，而當你掌握了微服務技術以後，你會發現微服務的劃分也是個難點。在微服務劃分時，通常狀況下都會考慮按業務功能劃分、確保服務和服務之間要解偶等等，而實際在設計微服務系統時這些方法可能依然會存在不少問題。那麼到底如何正確的劃分微服務，如下文章能夠提供很好的參考。

你的微服務是否過小？或者太緊密耦合？本設計指南能夠提供幫助。

設計微服務每每更像是一門藝術而不是科學。本文提出五個建議：

1. 它不會與其餘服務共享數據庫表
2. 它擁有最少許的數據庫表
3. 它設計爲有狀態的或無狀態的
4. 其數據可用性需求
5. 這是真相的惟一來源

避免任意規則

在設計和建立微服務時，不要陷入使用任意規則的陷阱。若是你閱讀了足夠多的建議，你會遇到下面的一些規則。雖然吸引人，但這些並不都是劃分微服務邊界的正確方法。以下：

1. 「微服務應該有X行代碼」

讓咱們弄清楚一件事。對於微服務中有多少行代碼沒有限制。微服務不會由於你寫了幾行額外的代碼而忽然變成單體巨石。關鍵是確保服務中的代碼具備很高的凝聚力（稍後會詳細介紹）。

2. 「將每一個函數變成微服務」

若是一個函數是根據三個輸入值計算出某些東西，並返回一個結果，那麼這個函數就是一個微服務嗎？這個函數是不是一個可單獨部署的應用程序嗎？其實真的取決於函數是什麼以及它如何服務於整個系統。

其餘任意規則包括那些不考慮整個上下文的規則，例如團隊的經驗，DevOps容量，服務在作什麼以及數據的可用性需求等。

精心設計的服務的特色

若是您已閱讀過有關微服務的文章，毫無疑問，您會發現有關設計良好的服務的建議。簡而言之：高凝聚力和鬆散耦合。若是你不熟悉這些概念，有不少關於這些概念的文章。雖然合理的建議，但這些概念是至關抽象的。

我已經和數十位CTO就這個話題進行了交流，向他們學習他們如何劃分微服務界限，下面爲大家提供了一些潛在的特性。

特性＃1：它不會與其餘服務共享數據庫表

當設計一個微服務時，若是你有多個引用同一個表的服務，這是一個紅色警告，由於它可能意味着你的數據庫是耦合的來源。

「每一個服務都應該有本身的表[而且]不該共享數據庫表。」 - Darby Frey，Lead Honestly共同創始人

這其實是關於服務與數據的關係，這正是Elastic Swiftype SRE的負責人Oleksiy Kovrin告訴個人：

「咱們在開發新服務時使用的主要基本原則之一是它們不該該跨越數據庫邊界。每項服務都應該依靠本身的一套底層數據存儲。這使咱們可以集中訪問控制，審計日誌記錄，緩存邏輯等等，「他說。

Kovyrin繼續解釋說，若是數據庫表的一部分「與數據集的其他部分沒有或不多有關係，這是一個強烈的信號，即組件可能能夠被隔離到一個單獨的API或單獨的服務中。」

特性＃2：它具備最少許的數據庫表

正如第1章所提到的，微服務的理想尺寸應該足夠小，但不能太小一點。每一個服務的數據庫表的數量也是同樣。

Scaylr工程負責人Steven Czerwinski在接受採訪時向我解釋說，Scaylr的甜蜜點是「一個服務 + 一個或兩個數據庫表」。

特色＃3：它有設計爲有狀態或無狀態

在設計微服務時，您須要問本身是否須要訪問數據庫，或者它是否將成爲處理TB數據（如電子郵件或日誌）的無狀態服務。

「咱們經過定義服務的輸入和輸出來定義服務的邊界。有時服務是網絡API，但它也多是一個處理輸入文件並在數據庫中生成記錄的過程（這是咱們的日誌處理服務的狀況）「 - Julien Lemoine

要清楚這個前沿，它會致使更好的設計服務。

特色＃4：它的數據可用性需求被考慮在內

在設計微服務時，您須要記住哪些服務將依賴於這項新服務，以及若是數據不可用，對系統的影響是什麼。考慮到這一點，您能夠爲此服務正確設計數據備份和恢復系統。

當與Steven Czerwinski談話時，他提到他們的關鍵客戶行空間映射數據因爲其重要性而以不一樣方式複製和分離到不一樣分區。

「而每一個分片信息，都是在本身的小分區中。 若是所在分區宕機，那麼就沒有備份可用，但它隻影響5％的客戶，而不是100％的客戶，「Czerwinski解釋說。

特色＃5：這是一個真理的單一來源

要牢記的最後一個特色是設計一個服務，使其成爲系統中某件事情的惟一真理來源。

舉例來講，當您從電子商務網站訂購某物品時，會生成訂單ID。此訂單ID可供其餘服務用於查詢訂單服務以獲取有關訂單的完整信息。使用pub / sub概念，在服務之間傳遞的數據應該是訂單ID，而不是訂單自己的屬性/信息。只有訂單服務具備完整的信息，而且是給定訂單的惟一真實來源。

考慮更大的團隊

對於大型系統而言，在肯定服務邊界時，組織架構考慮將發揮做用。有兩點須要注意：獨立發佈時間表和不一樣的上線時間的重要性。

Cloud66首席執行官Khash Sajadi表示：「咱們所見過的最成功的微服務實施要麼基於軟件設計原則，例如基於領域驅動設計、面向服務架構SOA或反映組織方式的架構。

「因此對於支付團隊來講，」Sajadi繼續說道，「他們有支付服務或信用卡驗證服務，這是他們向外界提供的服務。這主要是關於向外界提供更多服務的業務部門。「

「[亞馬遜CEO:傑夫貝佐斯]提出了'兩個比薩餅'的規則 - 一個團隊不能多到兩個披薩餅還不夠他們吃的地步。」 - Iron.io首席技術官Travis Reeder

亞馬遜是擁有多個團隊的大型組織的完美典範。正如在API推薦人發表的一篇文章中提到的，傑夫貝佐斯向全部員工發佈了一份受權通知他們，公司內的每一個團隊都必須經過API進行溝通。任何不會的人將被解僱。

這樣，全部的數據和功能都經過接口暴露出來。貝佐斯還設法讓每一個團隊解耦，定義他們的資源，並經過API使其可用。亞馬遜老是自底而上從頭開始創建一個系統。這可讓公司內的每一個團隊成爲彼此的合做夥伴。

我與Iron.io的首席技術官Travis Reeder談到了貝佐斯的內部計劃。

「傑夫貝佐斯強制全部team都必須創建API來與其餘team進行溝通，他也提出了'兩個披薩'規則，一個團隊不能多到兩個披薩餅還不夠他們吃的地步。」他說。

「我認爲這一樣適用於這樣狀況：當一個小團隊在開發、管理和生產方面開始變得笨拙或開始變慢，這說明這個團隊可能已經太大了，「Reeder告訴我。

如何判斷服務是否過小，或許沒有正肯定義

在微服務系統的測試和實施階段，須要牢記下面兩條出現現象。

要注意的第一個現象是服務之間的任何過分依賴。 若是兩個服務不斷地互相調用，那麼這已是一個強烈的耦合信號，他們若是併成一個服務可能更好。

第二個現象：創建服務的開銷超過了讓其獨立的好處。 在這種狀況下不如合併成一個服務。

Darby Frey解釋說：「每一個應用程序須要將其日誌彙總到某處並須要進行監控。您須要設置報警。而後須要有標準的響應操做程序，並在事情中斷時運行。你必須管理SSH的訪問權限。爲了讓應用程序正常運行，必須準備大量基礎設施支持。「

參考

原文
譯文