當我們討論微服務時，更多的是學習技術上怎麼實現，而當你掌握了微服務技術之後，你會發現微服務的劃分也是個難點。在微服務劃分時，一般情況下都會考慮按業務功能劃分、確保服務和服務之間要解偶等等，而實際在設計微服務系統時這些方法可能依然會存在很多問題。那麼到底如何正確的劃分微服務，以下文章可以提供很好的參考。
你的微服務是否太小？或者太緊密耦合？本設計指南可以提供幫助。
設計微服務往往更像是一門藝術而不是科學。本文提出五個建議：
- 它不會與其他服務共享數據庫表
- 它擁有最少量的數據庫表
- 它設計爲有狀態的或無狀態的
- 其數據可用性需求
- 這是真相的唯一來源
避免任意規則
在設計和創建微服務時，不要陷入使用任意規則的陷阱。如果你閱讀了足夠多的建議，你會遇到下面的一些規則。雖然吸引人，但這些並不都是劃分微服務邊界的正確方法。如下：
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的訪問權限。爲了讓應用程序正常運行，必須準備大量基礎設施支持。“