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