劃分微服務邊界的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的訪問許可權。為了讓應用程式正常執行，必須準備大量基礎設施支援。“

Microservices for Startups: Microservice Boundarie