透過本篇文章您可以瞭解到以下內容：

  • 微服務架構的由來、歷史
  • 微服務架構相比傳統單體應用的優勢
  • 微服務拆分原則概述

微服務架構的由來、歷史

從軟體架構的發展趨勢來看，整體分為四個階段：

前三個階段分別是單體應用、3-Tier架構、SOA架構：

  • 單體應用：顧名思義是將所有的業務邏輯用一個工程進行表示。 （在上一篇文章中我們進行了詳細的介紹）
  • 3-Tier架構：一種軟體設計的思想。 不同於單體應用的模式，它將整個業務應用進行了層次劃分。 總共分為三層，自上而下分別是展示層、業務邏輯層、資料存取層。 另一方面，這種層次的區分也體現了「高內聚低耦合」的思想。
  • SOA架構，一種軟體設計的思想，按照實際業務需要，拆分成粗粒度、鬆耦合的服務架構。

第四個階段也就是我們今天的主角，微服務架構。 在談到微服務架構的歷史，我們就不得不想到了以下幾位大師：

  • Adrain Cockcroft，Netflix架構師。 主導了Netflix從2009年到2016年單體應用到微服務架構演進的工作。 並使得Netflix成為首批成功從單體應用遷移到基於雲的微服務架構的公司之一。
  • Fred George，在2012年的一次技術大會上，詳細介紹了他和他的團隊如何將百萬級代碼的傳統應用進行改造拆分，並利用消息中間件（MQ）進行服務之間解耦的過程。

另外，對於雲原生概念最早的提出者Pivotal（已經回歸到了VMware）對於微服務也給出了相關解釋和說明：

（部分截取，詳細內容可參見官網： https://tanzu.vmware.com/microservices ）

以上就是關於微服務架構歷史的介紹，接下來讓我們看看微服務架構相比傳統單體應用的優勢又有哪些？

微服務架構相比傳統單體應用的優勢

在上一篇文章中我們闡述了傳統單體應用在專案早期階段的優勢，以及在隨著專案不斷發展、擴大後顯現出的弊端。 那麼相對於傳統單體應用，微服務架構的優勢又有哪些呢？

  • 應用程式擴展性：相比傳統單體應用架構，微服務架構下，每個微服務具備自主運行的能力，這使得添加、刪除、更新、擴展單個具體服務變得相對容易。 這種改變並不會影響到其他服務。
  • Two-Pizza團隊：每個微服務的擁有權分配給一個小團隊，團隊與團隊之間緊密合作。 從而大大提高了工作效率，也使得團隊易於管理。
  • 資料安全性：在微服務架構中，每一個服務具有自己獨立的數據。 當微服務之間建立數據連接時，資訊安全就會成為一個問題。 幸運的是，大多數通訊使用的是安全API。 安全的API通過確保只有經過專門授權的應用程式、使用者和伺服器才能存取數據，從而保證了資料的安全性。
  • 快速反覆運算、交付、驗證：微服務最重要的優勢是靈活性，能夠快速反覆運算一個小的、集中的功能，並看到結果。 由於企業可以快速開發和部署新功能，用戶可以在幾周內看到他們的回饋，而不是幾個月或幾年。 這大大促進了使用者、開發人員和工程師之間的協作。
  • 技術多樣化：不同的團隊可以使用不同的程式設計語言以及技術來實現他們的服務。 服務與服務之間透過聲明式的API進行交互，大大增加了技術的靈活性。
  • 容錯性：在微服務架構中，一個服務的故障不太可能對其他服務產生太大的影響，因為服務與服務之間是彼此獨立運行的。 然而大型分散式微服務體系結構往往具有許多依賴關係，因此需要避免的是當某個服務出現故障，因為依賴關係所導致的其他服務不可用的情況，即容錯性。

微服務拆分原則概述

透過上面一章節的介紹，相信我們清楚的瞭解了微服務架構的優勢。 當某一個新業務需求到來或者說對現有老舊的單體應用進行改造時，我們是否可以直接透過某種已經選定的技術框架，就能夠進行業務開發了呢？  答案是否定的。 相比技術框架的確定以及具體的開發工作，更前置一步需要我們進行解決的就是微服務的拆分。

這裡可以把它歸結為“三步驟”方式：

  • 第一步（微服務拆分）此步驟可以分為兩種情況。 第一種情況即新的業務從0到1的建構。 第二種情況即對已有的「單體」應用進行改造，改造成微服務架構。
  • 第二步（技術選型）此步驟相對比較好理解，根據不同的業務模組的特點以及需要，可以使用不同的技術框架。 這裡不同於單體應用，因為每一個微服務是獨立開發、部署的，所以在技術選型上面會更加靈活多樣化。 例如針對JAVA技術棧，我們可以使用Spring框架模組，在已經拆分好微服務的前提下，幫助我們從技術框架的角度快速搭建微服務架構。
  • 第三步（業務開發）相關的開發人員根據業務需求，在相應技術框架的基礎上進行業務的開發、測試、部署等操作。

從上面的介紹不難看出，微服務拆分在整個流程中是尤為重要的，但是只要談到微服務拆分，相信大家都會聽說一個名詞，它就是Domain Driven Design（領域驅動設計，簡稱DDD ）。 Domain Driven Design 起源於Eric Evans發表的書籍《DOMAIN-DRIVEN DESIGN TACKLING COMPLEXITY IN THE HEART OF SOFTWARE》（中文譯名《領域驅動設計— 軟體核心複雜性應對之道》。 在此書中的一些概念，例如領域、限界上下文等概念和微服務宣導的高內聚、低耦合有著完美的契合，進而越來越多的人把Domain Driven Design作為微服務拆分的一種指導原則。

如上圖所示，我們可以看到包含了眾多概念，想要理解掌握這些概念並做到靈活運用並不是一件容易的事情，同時Domain Driven Design是一種軟體系統設計和開發的方法論，是一種指導思想。 如何根據這種指導思想並結合有效的分析工具進行實際落地，成為了大家普遍關注的問題。

那麼作為雲原生概念的提出者Pivotal（VMware）在微服務拆分上的最佳實踐是什麼？ 最佳實踐過程中又會結合使用哪些工具？

在下期的文章中會繼續和大家進行交流分享，敬請期待！  如您有任何建議，歡迎隨時聯繫我們！

參考連結：

作者簡介

李剛，VMware 大中華區應用現代化部門高級系統架構師，資深企業級軟體開發和軟體系統架構師。 Spring Cloud開源社區項目貢獻者、Netflix開源社區貢獻者。 近幾年，參與並主導了許多大型企業客戶的應用現代化數位轉型專案，涉及物流、製造、金融等諸多領域。 特別對微服務實現方法、現代化應用架構設計、雲原生實施落地、開源軟體技術等方面有著豐富經驗。