實戰論壇：擊敗SOA的微服務架構為何會贏得人心？
微服務概念的由來
據說，早在 2011 年 5 月，在威尼斯附近的一個軟體架構師研討會上，就有人提出了微服務架構設計的概念，用它來描述與會者所看得見的一種通用的架構設計風格。時隔一年之後，在同一個研討會上，大家決定將這種架構設計風格用微服務架構來表示。
起初，對微服務的概念，也沒有一個明確的定義，大家只能從各自的角度說出了對微服務的理解和看法。
有人把微服務理解為一種細粒度的 SOA（Service-Oriented Architecture，面向服務架構），一種輕量的組件化的小型 SOA。
有人把微服務看作一種使用 HTTP 通信的自包含的輕量進程。
……
在這些看法中，比較統一的一點就是，大家都認為微服務是一種小型的應用程序，並且使用輕量級的設計方法和輕量級的 HTTP 通信。
在 2014 年 3 月，詹姆斯·劉易斯和馬丁·福勒所發表的一篇博客中，總結了微服務架構設計的一些共同特點，這應該是一個對微服務比較全面的描述。
這篇文章中認為：「簡而言之，微服務架構風格是將單個應用程序作為一組小型服務開發的方法，每個服務程序都在自己的進程中運行，並與輕量級機制（通常是 HTTP 資源API）進行通信。這些服務是圍繞業務功能構建的，可以通過全自動部署機器獨立部署。這些服務可以用不同的編程語言編寫，使用不同的數據存儲技術，並盡量不用集中式方式進行管理。」
從這個描述中可以看出，微服務可以是一個小型的服務組件，它使用輕量的 HTTP 協議進行通信。微服務也可以是一個獨立的應用程序，它可以具有獨立的資料庫、獨立部署和獨立運行。理想的想法是，微服務可以使用不同的語言來編寫，並且完全獨立自治。
微服務的定義
從上面對微服務概念形成過程的介紹之中，我們已經對微服務有一個大概的了解，但要說明什麼是微服務，很有可能一時也不能說得很清楚。這裡，有一點容易混淆的就是微服務架構和微服務，這應該是兩個不同的概念，而我們平時一說到微服務，可能已經包含了這兩個概念，所以要把它們說清楚難免就會有一種很糾結的感覺。微服務架構是一種設計方法，而微服務應該是指使用這種設計方法而設計的一個應用。所以我們很有必要對微服務的概念做出一個比較明確的定義。
微服務架構是將複雜系統使用組件化的方式進行拆分，並使用輕量通信方式進行整合的一種設計方法。微服務就是通過這種架構設計方法拆分出來的一個獨立的組件化小應用。
組件，通常是以代碼庫的形式，提供函數式調用；而微服務的組件，卻以應用的方式， 通過使用 HTTP 通信提供介面服務。
微服務架構定義的精髓，可以用一句話來描述，那就是「分而治之，合而用之」。將複雜系統進行拆分的方法，就是「分而治之」的方法。分而治之，可以讓複雜的事情變得簡單，這很符合我們平時處理問題的方法。使用輕量通信等方式進行整合的設計，就是「合而用之」的方法。合而用之，可以讓微小的力量變得強大。硬體設計中多線程和多任務的技術，可以成倍地提高其並發能力和執行性能。如果軟體設計還在使用單線程的方法，那是相當落後的。所以微服務設計中的整合，不但是多服務的整合，也是一種多實例、多副本的整合。通過這種整合，可以充分利用分散式環境的資源和低廉的機器組合成一個強大的服務系統。
微服務輕量級的 HTTP 通信，不同於傳統的做法，使用事先設定的 IP 和埠進行訪問，而是通過服務註冊與發現的機制，使用服務的實例名稱進行調用。在這個過程中，服務發現機制將協同路由代理服務和負載均衡器一起工作，當客戶端使用服務實例名稱發出請求時，將通過負載均衡器從服務註冊列表中選擇一個可用的服務實例，然後才通過實例註冊的 IP 和埠路由到相關的服務中。所以提供 API 的微服務，可以發布在任意主機之中，並且可以隨時更改主機和埠，也可以發布任意多個副本。
基於上面微服務的定義，我們可以總結出微服務架構設計的幾個顯著特點，具體如下。
小型化
微服務架構設計的突出之處就是進行服務組件化設計，組件化的結果最顯著的特點就是應用程序變小了。使用組件化方式來構建的應用程序，每個組件將只負責完成一定範圍的業務功能，更加專一地做好一件事情。因為小型化的特點，會讓問題變得更加簡單，也使開發變得更加容易。
自治化
使用去中心化的扁平化設計，將使每個服務都能夠進行獨立自治，這是對複雜功能的一種解耦設計。這種設計的特點也給每個微服務提供了更加自由的管理空間。
每個微服務都是一個獨立的應用，獨立使用資料庫，獨立部署，獨立運行，這種獨立性符合高內聚松耦合的設計原則。在微服務開發和維護中，每個微服務都是獨立自治的， 一個服務的更新和迭代將不存在對其他任何服務的依賴，同時也不會給其他服務造成影響，或者將這種影響減少到最小限度。
扁平化
獨立自治的微服務，可以更加自由地發揮每一個服務的優勢和長處。但是這種自由並不是指隨意的混搭和組合，而是使用了扁平化的服務治理，讓更多的微服務在發揮個性優勢的同時，處在一種雜而不亂的有序可控的狀態之中。雖然從整體上微服務已經沒有集中管理的概念了，但是微服務在整體上能夠發揮更佳的性能優勢。
輕量級設計
微服務的組件化特點，也是一種輕量級設計方法的體現，這種輕量級的設計同樣體現在微服務的通信設計之中。
微服務的通信設計通常用到兩種方式，即使用 API 的同步通信和使用消息通道的非同步通信，不管使用哪種通信方式，都沒有像 SOA 的 ESB（Enterprise Service Bus，企業服務匯流排）那樣的重量級設計，而是分別使用簡單的 REST 協議和輕量的消息匯流排來實現。
漸進式設計
一個產品從成型到成熟總是要經歷一個過程，這個過程就是漸進式設計的特點。由於微服務小型而獨立的特點，微服務設計可以使用業務驅動的方式進行，使用快速迭代進行不斷地修正和調整，以使產品趨於成熟。
微服務架構與整體式架構的區別
如果是一個小型項目，使用整體式架構來設計，其好處是明顯的，因為它的設計、開發、測試和部署，都在一個項目上就可以完成。
如果一個業務複雜的大型項目，也使用整體式架構來設計，就將存在很多問題。可能剛開始的階段，還感覺不到什麼，但是隨著時間的推移，加入的功能越來越多，一個項目就變成了一塊巨大的石頭，十分笨重。
面對一個如此巨大的項目，開發人員要弄清楚它的代碼邏輯，必須要花費很多的時間。而針對某一項功能的更改，極有可能動一線而牽全身，這會讓實施的人員變得很難應對。所以這種項目將會變得越來越難以維護，越來越不便更新。
整體式架構的穩定性也不能得到有效的保障，如果其中的一個模塊出現問題，將會影響到整個系統的正常運行，甚至造成整個系統的崩潰。而要進行問題的跟蹤，因為系統龐大，往往難上加難。
另外，一個巨大的應用項目，也不方便進行持續開發，它不能適應需求的變更，不能適應快速迭代的敏捷開發方法，所以這樣的項目最終就變成了業務發展的絆腳石。
相比之下，大型項目使用微服務架構就具有明顯的優勢。
微服務架構設計，就是將複雜事情進行簡單化處理的方法，它將一個複雜的系統，拆分成一些小型的應用來開發，起到了一種「大事化小，小事化無」的效果。因為簡單，代碼的邏輯會變得更加清晰，這無疑減輕了程序員繁重的勞動；因為簡單，所以能夠專註，能夠將每一件事情做好，做到極致。
微服務中獨立的小型應用，也非常適合使用敏捷開發方法，能夠快速響應需求的變化，進行快速更新，快速迭代，甚至將一個應用推倒重來也是很容易做到的。
因為每個微服務都是獨立自治的，一個服務的故障也不會影響到全局系統的正常運行，或者說可以將這種影響降到最低限度。況且，微服務架構的容錯設計可以避免這種情況發生。
微服務架構高可用的特點是系統穩定性的最好保障，而且微服務能夠支持高並發的調用，支持高流量的訪問，能夠持續保證平台規模化發展的要求，這是整體式架構所不能做到的。
如果我們使用一個六邊形結構來表示整體式架構的話，將可以繪製出如下圖所示的結構圖。
整體式架構六邊形結構圖
這個六邊形的核心是整體式架構的領域業務模型，它通過系統介面使用各種適配器，例如資料庫適配器、文件適配器等，與外部管理系統進行連接。然後通過介面使用諸如 Rest API 適配器、Web UI 適配器等對外部 App 和終端用戶提供介面調用和 Web 訪問等服務。
從上圖可以看出，整體式架構是一個大而全的系統。在微服務架構設計中，我們可以使用一個小六角形來表示每個微服務，它相當於將整體式架構進行拆分之後得到的結果。
微服務架構結構圖
小六角形的微服務同樣使用介面，通過各種適配器來連接外部管理系統，而微服務之間也可以通過介面，使用 Rest API 適配器進行通信，而對於 App 和終端用戶，將分別由不同的微服務提供相應的適配器及其服務。
從上面這兩種結構圖形的比較中，可以非常明顯地看出整體式架構與微服務架構的巨大區別。
有關這種圖形結構的表示方式，參考了克里斯·理查德森在 2015 年 5 月發表的系列文章，對這些文章感興趣的讀者可以在nginx網站中搜索查詢。
微服務架構與SOA的比較
SOA（Service-Oriented Architecture，面向服務架構），是一種粗粒度、松耦合的面向服務架構設計方法。SOA 可以看作 B/S 模型、XML（標準通用標記語言的子集）/Web Service 技術之後的自然延伸。
SOA 是一種企業級的架構設計方法，使用企業服務匯流排（ESB）的方式來構建一個更高效、更可靠、更具重用性的企業信息系統。相比於以往 C/S 和 B/S 等模式的設計，使用SOA 架構的系統已經取得了很大的進步，系統可以更加從容地面對業務的急劇變化。所以 SOA 曾經風靡一時，例如 Dubbo、Dubbox、Mule、WSO2、CXF 等都是一些比較優秀的 SOA 開源工具。
微服務架構與 SOA 在表面看來還是有一點相似的，以至於早期有人會認為微服務是一個細粒度的 SOA，其實它們的區別還是很大的。
微服務的輕量級設計與 SOA 重量級設計是這兩種架構的最大區別。微服務的通信設計使用簡單的 HTTP 協議，一般使用 Restful 實現。而 SOA 一般使用複雜的協議，如WebService 或 BPEL（Business Process Execution Language，業務流程執行語言）等，還需要使用服務描述性語言來定義標準介面。
微服務的自治性與 SOA 的集中式管理的區別：微服務架構使用去中心化的扁平化管理方式，每個服務都是一個獨立的應用程序，獨立管理，使用獨立的資料庫，獨立部署和獨立運行。SOA 是一種整體式架構，使用集中式的管理方式和統一的數據中心。所以微服務的開發和部署更加靈活和快速，可以更快地響應需求的變化和業務的更新。
微服務架構與 SOA 的另一個區別是應用的規模不同，SOA 是在企業計算領域中產生的一種架構設計方法，在應用規模上是一個有限的範圍，而微服務架構是產生於互聯網環境中的一種設計方法，它的設計更能適應無限廣闊的環境，更能適應互聯網高流量、高並發的規模擴張。
微服務架構的高可用設計、自由伸縮性、負載均衡、故障轉移等特性是 SOA 設計不夠重視的地方。微服務的高可用設計通過微服務治理，為每個微服務的管理和部署提供一個可以擴展的無限廣闊的空間，它可以表現為一個三維結構。
微服務治理的三維結構
在這個三維結構中，如果我們用 Y 軸表示微服務應用，用 X 軸表示微服務應用部署的多個副本，那麼用 Z 軸表示微服務治理，它將提供服務路由和負載均衡管理等功能，並且還可以提供分區管理的功能。
為什麼要使用微服務架構
整體式架構已經不再適合於一個大型項目或者一個應用平台的開發，而 SOA 架構雖然曾經風靡一時，但是其重量級的設計也已經成為快速開發的障礙，所以這兩種架構設計方法都將被微服務架構所取代。微服務架構輕量級的設計風格， 不管從理論上還是從技術實現上，已經越來越多地得到更多人們的肯定和認可，大家對它的未來發展趨勢都抱有一種樂觀的態度。使用微服務的好處如下。
開發簡單
微服務架構將複雜系統進行拆分之後，讓每個微服務應用開發都變得非常簡單，沒有太多的累贅。對於每一個開發者來說，這無疑是一種解脫，因為再也不用進行繁重的勞動了，每天都在一種輕鬆愉快的氛圍中工作，其效率將會成倍地提高。
快速響應需求變化
一般的需求變化都來自於局部功能的變更，這種變更將落實到每個微服務上，而每個微服務的功能相對來說都非常簡單，更改起來非常容易，所以微服務非常適合敏捷開發方法，能快速響應業務需求的變化。
隨時隨地更新
一方面，一個微服務的部署和更新並不會影響到全局系統的正常運行；另一方面，使用多實例的部署方法，可以做到一個服務的重啟和更新在不易被察覺的情況下進行。所以， 每個微服務任何時候都可以進行更新部署。
系統更加穩定可靠
微服務運行在一個高可用的分散式環境之中，有配套的監控和調度管理機制，並且還可以提供自由伸縮的管理，充分保障了系統的穩定可靠性。
規模可持續擴展
每個互聯網應用都具有巨大的市場潛力，一旦這種潛力被激發，就需要系統能支持大規模的高並發訪問機制，使用微服務架構設計的系統，將能適應業務的快速增長，並可持續支持規模化的擴展。
本文選自《Spring Cloud與Docker高並發微服務架構設計實施》，作者陳韶健，
TAG:3T趣課堂 |