《微服務設計》第 3 章　如何建模服務

• 2019 年 10 月 8 日
• 筆記

3.1　MusicCorp簡介

3.2　什麼樣的服務是好服務

• 我希望你專註在兩個重要的概念上：松耦合和高內聚
• 如果這兩點做不到，那麼微服務也就沒什麼價值了

3.2.1　松耦合

• 使用微服務最重要的一點是，能夠獨立修改及部署單個服務而不需要修改系統的其他部分，這真的非常重要
• 一個松耦合的服務應該儘可能少地知道與之協作的那些服務的信息

3.2.2　高內聚

• 最好能夠只在一個地方進行修改，然後就可以儘快地發佈
• 在多個不同的地方進行修改會很慢，同時部署多個服務風險也很高，這兩者都是我們想要避免的

3.3　限界上下文

• 限界上下文的定義是：「一個由顯式邊界限定的特定職責。」（http://blog.sapiensworks.com/post/2012/04/17/DDD-The-Bounded-Context-Explained.aspx）如果你想要從一個限界上下文中獲取信息，或者向其發起請求，需要使用模型和它的顯式邊界進行通信。在這

3.3.1　共享的隱藏模型

• 對於 MusicCorp 來說，財務部門和倉庫就可以是兩個獨立的限界上下文。它們都有明確的對外接口（在存貨報告、工資單等方面），也都有着只需要自己知道的一些細節（鏟車、計算器）

3.3.2　模塊和服務

• 然而對於一個新系統而言，可以先使用一段時間的單塊系統，因為如果服務之間的邊界搞錯了，後面修復的代價會很大。所以最好能夠等到系統穩定下來之後，再確定把哪些東西作為一個服務劃分出去

3.3.3　過早劃分

• 過早劃分導致很多跨服務修改，這些修改的代價相當高

3.4　業務功能

• 當你在思考組織內的限界上下文時，不應該從共享數據的角度來考慮，而應該從這些上下文能夠提供的功能來考慮

3.5　逐步劃分上下文

• 首先考慮比較大的、粗粒度的那些上下文，然後當發現合適的縫隙後，再進一步劃分出那些嵌套的上下文
• 我見過有一種做法是，使這些嵌套的上下文不直接對外可見。對於外界來說，它們用的還是倉庫的功能，但發出的請求其實被透明地映射到了兩個或者更多的服務上

3.6　關於業務概念的溝通

• 微服務之間如何就同一個業務概念進行通信，也是一件很重要的事情
• 事實上，通信形式在整個組織範圍內都非常重要

3.7　技術邊界

• 洋蔥架構，因為它有很多層，而且當縱切這些層次時，我只想哭

3.8　小結

• 限界上下文是尋找這些接縫的一個非常重要的工具，通過將微服務與這些邊界相匹配，可以保證最終的系統能夠得到微服務提供的所有好處

書

• 《領域驅動設計》
• 《實現領域驅動設計》

工具

• SnapCI
• Go-CD