隨着互聯網在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 的《微服務設計》一書以後,與其餘的微服務設計相關文章、《從服務化到雲原生》等書籍進行關聯閱讀後作的筆記總結。架構
目的是構建分佈式、微服務、雲原生方面的體系化的知識結構樹。異步
但願鞏固學習的同時可以幫助到你。分佈式
微服務就是一些協同工做的小而自治的服務。關鍵詞: 小而自治微服務
「小」這個概念,一方面體如今微服務的內聚性上。工具
另外一方面體如今代碼庫的大小,這裏有幾個參考的標準或者說原則性能
「自治」這個概念,強調的是,一個微服務就是一個獨立的實體。體如今服務之間的鬆耦合上。學習
關鍵點:要學會正確的建模服務,正確的設計服務API,才能作到上述兩點。
微服務的大多好處都適用於分佈式系統架構,只不過微服務會將這些好處推向極致
技術異構性
彈性/反脆弱性(anti-fragility)
擴展
簡化部署
微服務架構,各個服務部署相互獨立
架構與組織結構相匹配
SOA(Service-Oriented Architecture,面向服務的架構)是一種設計方法,其中包含多個服務,而服務之間經過配合最終會提供一系列功能。一個服務一般以獨立的形式存在於操做系統進程中。服務之間經過網絡調用,而非採用進程內調用的方式進行通訊。
就像認爲 XP 或者 Scrum 是敏捷軟件開發的一種特定方法同樣,微服務架構是 SOA 的一種特定方法。
實施SOA會遇到的問題:
微服務確實有許多優勢:「反脆弱性(anti-fragility)」、容錯、獨立部署與擴展、架構抽象、技術隔離。但並非說採用了微服務就天然地具有了這些特性。
好比,要具有反脆弱性,須要充分考慮分佈式系統的不肯定性,清楚異步、網絡劃分、節點故障、平衡可用性與數據一致性等問題。
一樣地,要具有可維護性和可擴展性,首先要有恰當的基礎設施和組織結構。
理論上講,微服務能夠提升開發速度,但在建立組織依賴時,「微服務佣金(MicroservicePremium)」可能會下降開發速度。
因此,採用微服務架構須要具有一些先決條件,包括恰當的持續發佈管道、能勝任的DevOps 和Ops 團隊、審慎的服務邊界等等。此外,周密的測試和集成模式也很重要。
就書中這章最後一講說的:微服務不是銀彈,你須要在部署、測試和監控等方面作不少的工做。你還須要考慮如何擴展系統、而且保證他們的彈性,甚至還須要處理相似分佈式事務、CAP相關的問題。
我以爲,這也是爲何服務化到雲原生是大勢所趨,由於只有結合「容器 +編排調度」的雲平臺,微服務才能將本身的優勢發揮到最大。至於雲原生的知識,又是後面的內容了。
引伸閱讀 Martin Fowler大神的文章
仍是要重申兩個重要概念,高內聚和鬆耦合,對應前面的關鍵詞:小而自治。
此處做者引用了 Eric Evans 的著做《領域驅動設計》中的概念(這本書強烈建議閱讀):限界上下文。
任何一個給定的領域都包含多個限界上下文,每一個限界上下文中的東西(Eric 更常使用模型這個詞,應該比「東西」好得多)分紅兩部分,一部分不須要與外部通訊,另外一部分則須要。每一個上下文都有明確的接口,該接口決定了它會暴露哪些模型給其餘的上下文。
使用細胞做爲比喻: 「細胞之因此會存在,是由於細胞膜定義了什麼在細胞內,什麼在細胞外,而且肯定了什麼物質能夠經過細胞膜。」
同時又提到共享模型和隱藏模型的概念。
共享模型就是上述比喻中上下文之間交互的模型,隱藏模型就是不須要與外部進行交互的模型。
關於如何開始微服務,做者在書中的觀點和同在TW的Martin Fowler是一個觀點:"MonolithFirst" - 單體應用先行。
主要出於如下考慮:
引伸閱讀 https://www.martinfowler.com/...
固然這和他們所處的公司業務環境確定有很大的關係,ThoughtWorks 是一家幫助其餘公司解決問題的顧問公司,也就是說,他們會在某個公司的單體應用出現問題時提供幫助,將其重構爲微服務架構。得出這樣的結論也無可厚非。業界關於這個也有其餘的聲音,好比直接就從微服務開始。
我本人是比較傾向於這種方式,因此對這種方式進行了摘錄和學習。
過早將一個系統劃分紅爲微服務的代價很是高,尤爲是在面對新領域時。不少時候,將一個已有的代碼庫劃分紅微服務,要比從頭開始構建微服務簡單得多。
使用模塊對限界上下文進行建模,同時使用共享和隱藏模型。
思考限界上下文的時候,應該從業務功能入手,首先要問本身「這個上下文是作什麼用的」,而後再考慮「它須要什麼樣的數據」。
逐步劃分上下文
當考慮微服務的邊界時,首先考慮比較大的、粗粒度的那些上下文,而後當發現合適的縫隙後,再進一步劃分出那些嵌套的上下文。
如何在問題空間中尋找能達到高內聚低耦合的接縫。限界上下文是尋找這些接縫的一個很是重要的工具,經過將微服務與這些邊界相匹配,能夠保證最終的系統可以獲得微服務提供的全部好處。
這一部分能夠關聯學習DDD理念相關書籍。