微服務設計學習（一）關於微服務和如何建模服務

前言

隨着互聯網在21世紀初被大規模接入，互聯網由基於流量點擊贏利的單方面信息發佈的Web 1.0業務模式，轉變爲由用戶主導而生成內容的Web 2.0業務模式。所以，互聯網應用系統所需處理的訪問量和數據量均疾速增加，後端技術架構也所以面臨着巨大的挑戰。

Web 2.0階段的互聯網後端架構大多經歷了由All in One的單體式應用架構漸漸轉爲更加靈活的分佈式應用架構的過程，互聯網開發架構開始追求更高的質量和效率。

隨着智能手機的出現以及4G標準的普及，互聯網應用由PC端迅速轉向更加自由的移動端。移動設備因爲攜帶方便且便於定位，所以在出行、網絡購物、支付等方面完全改變了現代人的生活方式。在技術方面，爲了應對更加龐大的集羣規模，單純的分佈式系統已經難於駕馭，所以技術圈開啓了一個概念爆發的時代——SOA、DevOps、容器、CI/CD、微服務、Service Mesh等概念層出不窮，而Docker、Kubernetes、Mesos、Spring Cloud、gRPC、Istio等一系列產品的出現，標誌着雲時代已真正到來。

本文（或者說本系列文章），是本人在閱讀完 Sam Newman 的《微服務設計》一書以後，與其餘的微服務設計相關文章、《從服務化到雲原生》等書籍進行關聯閱讀後作的筆記總結。

目的是構建分佈式、微服務、雲原生方面的體系化的知識結構樹。

但願鞏固學習的同時可以幫助到你。

1、關於微服務

1.1 什麼是微服務

微服務就是一些協同工做的小而自治的服務。

關鍵詞： 小而自治

「小」

「小」這個概念，一方面體如今微服務的內聚性上。

• 內聚性也能夠稱之爲單一職責原則：「把因相同緣由而變化的東西聚合到一塊兒，而把因不一樣緣由而變化的東西分離開來。」
• 也就是說，微服務應該專一於作好一件事情。
• 由業務邊界來肯定服務的邊界

另外一方面體如今代碼庫的大小，這裏有幾個參考的標準或者說原則

• 代碼庫小到團隊結構相匹配
• 代碼庫小到易於迅速重寫
• 辯證的看待。服務越小，微服務架構的優勢和缺點也就越明顯

自治

「自治」這個概念，強調的是，一個微服務就是一個獨立的實體。體如今服務之間的鬆耦合上。

• 黃金法則：你是否可以修改一個服務並對其進行部署，而不影響其餘任何服務？

---

關鍵點：要學會正確的建模服務，正確的設計服務API，才能作到上述兩點。

1.2 微服務的好處

微服務的大多好處都適用於分佈式系統架構，只不過微服務會將這些好處推向極致

• 技術異構性

  • 不一樣服務根據業務場景、性能要求、功能需求採用不一樣的技術架構
  • 新技術的快速實踐，技術團隊的快速成長

• 彈性/反脆弱性（anti-fragility）

  • 服務降級
  • 服務容災、服務熔斷

• 擴展

  • 傳統單體系統，沒法作到對局部功能進行擴展
  • 根據具體的業務需求，對特定的微服務進行擴展
  • 經過架構的手段，節省成本

• 簡化部署

  • 傳統單體應用，即便是一行代碼修改，也須要總體從新部署。風險太大。

  • 微服務架構，各個服務部署相互獨立

    • 靈活的發版方式
    • 快速回滾
    • 風險小

• 架構與組織結構相匹配

  • 關聯知識點：康威定律
• 服務的可重用、可組合
• 服務的可替代性，快速重寫

1.3 面向服務的架構

SOA（Service-Oriented Architecture，面向服務的架構）是一種設計方法，其中包含多個服務，而服務之間經過配合最終會提供一系列功能。一個服務一般以獨立的形式存在於操做系統進程中。服務之間經過網絡調用，而非採用進程內調用的方式進行通訊。

就像認爲 XP 或者 Scrum 是敏捷軟件開發的一種特定方法同樣，微服務架構是 SOA 的一種特定方法。

實施SOA會遇到的問題：

• 通訊協議（SOAP or REST）
• 第三方中間件選型
• 服務粒度劃分
• ......

思考與小結

微服務確實有許多優勢：「反脆弱性（anti-fragility）」、容錯、獨立部署與擴展、架構抽象、技術隔離。但並非說採用了微服務就天然地具有了這些特性。

好比，要具有反脆弱性，須要充分考慮分佈式系統的不肯定性，清楚異步、網絡劃分、節點故障、平衡可用性與數據一致性等問題。

一樣地，要具有可維護性和可擴展性，首先要有恰當的基礎設施和組織結構。

理論上講，微服務能夠提升開發速度，但在建立組織依賴時，「微服務佣金（MicroservicePremium）」可能會下降開發速度。

因此，採用微服務架構須要具有一些先決條件，包括恰當的持續發佈管道、能勝任的DevOps 和Ops 團隊、審慎的服務邊界等等。此外，周密的測試和集成模式也很重要。

就書中這章最後一講說的：微服務不是銀彈，你須要在部署、測試和監控等方面作不少的工做。你還須要考慮如何擴展系統、而且保證他們的彈性，甚至還須要處理相似分佈式事務、CAP相關的問題。

我以爲，這也是爲何服務化到雲原生是大勢所趨，由於只有結合「容器 +編排調度」的雲平臺，微服務才能將本身的優勢發揮到最大。至於雲原生的知識，又是後面的內容了。

引伸閱讀 Martin Fowler大神的文章

微服務佣金 https://www.martinfowler.com/...

2、如何建模服務

仍是要重申兩個重要概念，高內聚和鬆耦合，對應前面的關鍵詞：小而自治。

2.1 幾個概念

限界上下文

此處做者引用了 Eric Evans 的著做《領域驅動設計》中的概念（這本書強烈建議閱讀）：限界上下文。

任何一個給定的領域都包含多個限界上下文，每一個限界上下文中的東西（Eric 更常使用模型這個詞，應該比「東西」好得多）分紅兩部分，一部分不須要與外部通訊，另外一部分則須要。每一個上下文都有明確的接口，該接口決定了它會暴露哪些模型給其餘的上下文。
使用細胞做爲比喻： 「細胞之因此會存在，是由於細胞膜定義了什麼在細胞內，什麼在細胞外，而且肯定了什麼物質能夠經過細胞膜。」

共享模型和隱藏模型

同時又提到共享模型和隱藏模型的概念。

共享模型就是上述比喻中上下文之間交互的模型，隱藏模型就是不須要與外部進行交互的模型。

---

關於如何開始微服務，做者在書中的觀點和同在TW的Martin Fowler是一個觀點："MonolithFirst" - 單體應用先行。

主要出於如下考慮：

• Yagni 原則——肯定軟件思路是否有用，最好的方法是建立一個簡化版本，而後看它的使用效果。在這個階段，最重要的是速度，而該原則可縮短反饋週期，避免微服務佣金。
• 明確的有界上下文集合——只有服務存在良好且穩定的邊界，微服務纔能有效地發揮做用。可是，任何微服務間的功能重構都比在單體架構中難度大，即便是經驗豐富的架構師在本身熟悉的領域裏，也很難在一開始就恰當地定義出邊界，而首先構建一個單體應用有利於明確功能邊界。

引伸閱讀 https://www.martinfowler.com/...

固然這和他們所處的公司業務環境確定有很大的關係，ThoughtWorks 是一家幫助其餘公司解決問題的顧問公司，也就是說，他們會在某個公司的單體應用出現問題時提供幫助，將其重構爲微服務架構。得出這樣的結論也無可厚非。業界關於這個也有其餘的聲音，好比直接就從微服務開始。

我本人是比較傾向於這種方式，因此對這種方式進行了摘錄和學習。

2.2 建模要點

• 切忌過早劃分

  過早將一個系統劃分紅爲微服務的代價很是高，尤爲是在面對新領域時。不少時候，將一個已有的代碼庫劃分紅微服務，要比從頭開始構建微服務簡單得多。

• 肯定限界上下文

  使用模塊對限界上下文進行建模，同時使用共享和隱藏模型。

• 從業務功能入手

  思考限界上下文的時候，應該從業務功能入手，首先要問本身「這個上下文是作什麼用的」，而後再考慮「它須要什麼樣的數據」。

• 逐步劃分上下文

  當考慮微服務的邊界時，首先考慮比較大的、粗粒度的那些上下文，而後當發現合適的縫隙後，再進一步劃分出那些嵌套的上下文。

  • 嵌套上下文

    

  • 頂層上下文

    

思考與總結

如何在問題空間中尋找能達到高內聚低耦合的接縫。限界上下文是尋找這些接縫的一個很是重要的工具，經過將微服務與這些邊界相匹配，能夠保證最終的系統可以獲得微服務提供的全部好處。

這一部分能夠關聯學習DDD理念相關書籍。