我們公司落地微服務架構已多年，而我也接觸開發了一段時間了。恰好，最近又抽空把《微服務設計》一書隨手翻了一遍，便有了抒寫此文的念頭，雖然文中所述並非具有很強的普適性，倒也權當自己近來的總結和思考罷了。
我想對於許多初始接觸微服務開發的人員來說，都會或多或少有這樣的疑問
微服務應該如何劃分？
我的服務粒度應該如何評定？
在探討這些問題之前，我們不妨先問自己：什麼才算是好的服務？
坦率地講，這個問題與微服務無關，我們不妨抽象在一個更高層面去思考：什麼程式碼才算好的程式碼？我想很多人都會脫口而出：高內聚、低耦合。
沒錯，而這兩個原則也是微服務的根基，如果做不到這兩點，那麼微服務的價值也就無從體現了。
試想一下，服務提供者對於有多少服務消費者在使用是無感知的（雖然我們可以通過註冊中心得知，但是意義不大，我們也並不關心），假設服務提供者的某個服務要做調整導致所有的消費者都需要連帶調整，這是一件非常麻煩，也非常讓人難以接受的事情。
低耦合
在微服務架構中，很重要的一點就是，在設計的時候，應儘可能的少知道協作者的資訊，獨立修改和部署服務而不需要其他服務同步修改。
高內聚
把相關的行為都聚集在一個地方，不相關的放在別處。多處修改一方面比較麻煩，另一方面，多處修改多處部署風險也會相對更高。
在謹記兩條原則的基礎上，我們便可以帶著疑惑進入到我們的下一個問題中去，也就是前文所提到的，「微服務應該如何劃分」？
限定上下文
在《領域驅動設計》中，有一個比較重要的概念—-限定上下文。
在初次看到這個概念時，覺得非常的晦澀，但是隨著在業務中的思考，這種概念變得清晰起來。我們不妨將限定上下文拆分成兩個單詞來看，「限定」+「上下文」。
限定指的是某個範圍或者環境中，比如在商品這個系統中。而上下文可以理解為語境。總結起來似乎可以這麼理解：針對共同定義的某個模型，在不同的系統中有不同範圍的屬性；或者這麼說，在對內和對外而言，雖然服務提供者需要暴露某些資料（共享模型），但是針對不同的業務，並非需要將所有的資料都暴露出去。
舉個更加清晰的例子而言，比如我們需要將商品作為一個服務劃分出去，那麼服務消費者所看到和我們內部系統所使用的是不同的，或者說，我們只會向外部共享他們所需要的，而我們內部表示並不共享，否則如果有朝一日內部有所調整，那麼就必然影響到了服務消費者。
因此，我們需要思考的點在於，共享特定模型，而不要共享內部表示，避免高耦合。
值得一提的是，當我們在劃分服務時，需要注意的是我們面臨的是什麼功能，而不是單純的只考慮共享資料出去，否則極容易陷入貧血的誤區。
粒度
當我們在劃分設計時，有時候也會陷入過早劃分的誤區。一開始就把微服務劃分的比較明細雖然並不是一件壞事，但是總會造成前期開發成本大的局面。
我們在設計時，我更傾向於由粗到細的過程，然而，在這個過程中也會出現兩種情況，比如巢狀式和完全分離的區別
這兩種劃分方式的選擇更多的取決於你公司的架構，如果說它們是不同團隊在維護，那麼完全分離更合適，如果是一個團隊維護，那麼巢狀式更為合適。
歡迎關注我的公眾號，每週至少一篇比較有深度的原創文章：
本作品採用《CC 協議》，轉載必須註明作者和本文連結