微服務設計學習(一)關於微服務和如何建模服務

undefined

前言

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

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 更常使用模型這個詞,應該比「東西」好得多)分紅兩部分,一部分不須要與外部通訊,另外一部分則須要。每一個上下文都有明確的接口,該接口決定了它會暴露哪些模型給其餘的上下文。
使用細胞做爲比喻: 「細胞之因此會存在,是由於細胞膜定義了什麼在細胞內,什麼在細胞外,而且肯定了什麼物質能夠經過細胞膜。」

共享模型和隱藏模型

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

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

image.png


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

undefined

主要出於如下考慮:

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

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

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

2.2 建模要點

  • 切忌過早劃分

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

  • 肯定限界上下文

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

  • 從業務功能入手

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

  • 逐步劃分上下文

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

    • 嵌套上下文

      image.png

    • 頂層上下文

      image.png

思考與總結

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

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

相關文章
相關標籤/搜索