微服務架構與SOA的比較

SOA (Service-Oriented Architecture ）即面向服務架構，是一種粗粒度、松藕合的面向服務架構設計方法。SOA 可以看作 BIS 模型、 XML/Web Service 技術之后的自然延伸。

SOA 是一種企業(yè)級的架構設計方法，使用企業(yè)服務總線 (ESB ）的方式，構建一個能夠更高效、更可靠、更具重用性的企業(yè)信息系統(tǒng)。相比于 C/S BIS 等模式的設計，使用 SOA 架構的系統(tǒng)已經(jīng)取得了很大的進步，系統(tǒng)可以更加從容地面對業(yè)務的急劇變化，所以 SOA 曾經(jīng)風靡一時，例如 Dubbo Dubbox Mule WS02 CXF 等都是較為優(yōu)秀的 SOA 開源工具。

微服務架構與 SOA 從表面上看是有一點相似的，以至于早期有人認為微服務就是一個細粒度的 SOA。實際上，它們的區(qū)別還是很大的。

區(qū)別之一：微服務通信的輕量級設計與 SOA 重量級設計。這也是兩種架構的最大區(qū)別。微服務的通信設計使用簡單的 HT霄，一般基于 REST 協(xié)議實現(xiàn)。而 SOA 一般使用復雜的協(xié)議，如WebService BPEL (Business Process Execution Language ，業(yè)務流程執(zhí)行語言〉等，還需要使用服務描述性語言來定義標準接口。

區(qū)別之二：微服務的自治性與 SOA 的集中式管理。微服務架構使用去中心化的扁平化管理方式，每個服務都是一個獨立的應用程序 獨立管理、使用獨立的數(shù)據(jù)庫、獨立部署和獨立運行。SOA 是一種整體式架構，使用集中式的管理方式和統(tǒng)一的數(shù)據(jù)中心。所以微服務的開發(fā)和部署更加靈活和快速，可以更快地響應需求的變化和業(yè)務的更新。

區(qū)別之三：SOA 與微服務架構的應用的規(guī)模不同， SOA 是在企業(yè)計算領域中產(chǎn)生的一種架構設計方法，在應用規(guī)模上的范圍有限。而微服務架構是產(chǎn)生于互聯(lián)網(wǎng)環(huán)境中的一種設計方法，它更能適應無限廣闊的環(huán)境，以及互聯(lián)網(wǎng)高流量、高并發(fā)的規(guī)模擴展。

微服務架構的高可用設計、自由伸縮、負載均衡、故障轉移等特性是 SOA 設計不夠重視的地方。微服務的高可用設計通過微服務治理，為每個微服務的管理和部署提供了一個可以擴展的無限廣闊的空間，它可以表現(xiàn)為一個三維結構，如圖 1-3 所示。

在這個三維結構中，如果我們用Y 軸表示微服務應用，用X 軸表示微服務應用副本，用Z軸表示微服務治理，那么它將提供服務路由和負載均衡管理等功能。如果有需要，它還可以提供分區(qū)管理的功能。這種三維結構讓微服務天生就具備了自由伸縮的條件，以及可以進行無限擴展的能力。

微服務架構的優(yōu)勢

從前面的比較可以看出，整體式架構已經(jīng)不適合于一個大型項目或者一個互聯(lián)網(wǎng)應用平臺的開發(fā)了，而 SOA 架構雖然曾經(jīng)風靡一時，但是其重量級的設計成為快速開發(fā)的障礙，所以這兩種架構都將被微服務架構取代。微服務架構輕量級的設計風格，不管是從理論上，還是從技術實現(xiàn)上，已經(jīng)越來越多地得到人們的肯定和認可，大家對它的未來發(fā)展趨勢都抱有一種樂觀的態(tài)度。微服務的優(yōu)勢如下

第一，開發(fā)簡單。

微服務架構把復雜系統(tǒng)進行拆分之后，讓每個微服務應用的開發(fā)都變得非常簡單。對于開發(fā)者來說，因為不用針對很多代碼進行分析，所以效率會成倍地提高。

第二，快速響應需求變化。

一般的需求變化都來自局部功能的變更，這種變更將落實到每個微服務上，而每個微服務的功能相對來說都非常簡單，更改起來非常容易，所以微服務非常適合使用敏捷開發(fā)方法，能快速響應業(yè)務需求的變化。

第三，隨時隨地更新。

一方面，一個微服務的部署和更新并不會影響全局系統(tǒng)的正常運行，另一方面 使用多實例的部署方式可以做到一個服務的重啟和更新在不被察覺的情況下進行。所以，每個微服務在任何時候都可以進行部署和更新

第四，系統(tǒng)更加穩(wěn)定可靠。

微服務運行在一個高可用的分布式環(huán)境之中，有配套的監(jiān)控和調度管理機制，并且還可以提供自由伸縮的管理，充分保障了系統(tǒng)的穩(wěn)定性和可靠性。

第五，規(guī)模可持續(xù)擴展。

每個互聯(lián)網(wǎng)應用都具有巨大的市場潛力，一旦這種潛力被激發(fā)，就需要系統(tǒng)能支持大規(guī)模的高并發(fā)訪問。使用微服務架構設計的系統(tǒng)，可以適應業(yè)務的快速增長，并且可持續(xù)支持規(guī)模化的擴展。

為實施微服務架構做好準備

微服務架構 不是 種新技術，它只是一種全新的設計理念，所以，為了能夠更好地實施微服務架構設計，我們必須做好前期準備，從思想觀念、團隊管理和自動化基礎設施上進行相應的變革。

思想觀念

在進入微服務領域之前，必須從做項目的觀念轉變成做產(chǎn)品的觀念。如果是一個軟件項目，在完成了業(yè)務需求的設計之后，最終交付使用，其項目開發(fā)的生命周期就宣告結束。而做產(chǎn)品則完全不一樣，只要產(chǎn)品成型上線，產(chǎn)品有存在的價值，開發(fā)就永遠沒有終結。隨著產(chǎn)品的更新?lián)Q代，其中的應用程序和組件也要跟 不斷地進行更新和迭代。

微服務架構的漸進式設計的特 ，就是一種做產(chǎn)品的觀念的 實體現(xiàn)。一方面，一個產(chǎn)品的最初成型設計，由于種種原因并不可能把所有功能都考慮得很周到，這需要一定的時間進行慢慢的磨合與創(chuàng)新。另一方面，市場總是處于變化之中，所以產(chǎn)品的業(yè)務功能也會隨著時間的推移而發(fā)生 定的變化。

做產(chǎn)品的觀念將貫穿于一個系統(tǒng)平臺的整個生命周期之中，并隨著平臺的發(fā)展和演化，最終將產(chǎn)品打造成一個充滿活力的生態(tài)體系。

團隊管理

傳統(tǒng)的團隊管理，是按技術進行分組的。在一個開發(fā)團隊中，可能有 設計組、前端開發(fā)組、后端開發(fā)組、測試組和運維組等。

在微服務架構實施中，開發(fā)時是按業(yè)務功能進行劃分的，所以對團隊的管理，最好也以業(yè)務進行分組，將產(chǎn)品設計、前端開發(fā)、后端開發(fā)、測試和運維等人員圍繞業(yè)務功能分配在同組中，這樣不但可以增強團隊的凝聚力，還可以避免將大量的時間浪費在不同組別的溝通和工作協(xié)調上。

在實際操作中，因為前端開發(fā)和運維管理的消耗不是很大，所以對這兩部分人員可以進行機動的調整。但這種調整最好是在業(yè)務相近的領域中進行的，并保持一定的連貫性，即原來由誰負責的工作，在更新和維護時還是由他來負責。

為了減少資源的浪費和增加每個人員的工作飽和度，一個業(yè)務小組往往并不只負責一個微服務，有可能負責兩三個微服務的開發(fā)，這主要由微服務劃分的粗細粒度來定。

自動化基礎設施

從整體式架構向微服務架構轉變之后，項目數(shù)量會增加，迭代的周期會變短，對測試和運維人員也會提出更高的要求，并且其工作量會越來越大，所以單純依靠人力來完成這兩部分的工作是遠遠不夠的，這就要求必須有自動化基礎設施的支持，來完成自動集成、自動測試，以及持續(xù)交付、持續(xù)部署的工作。

一個原來由幾個項目支撐起來的應用平臺，在使用微服務架構進行拆分之后，可能會變成幾十個項目，甚至上百個項目。如果還像原來那樣分配測試和運維工作，則勢必要增加更多的人員。

在服務器資源的使用上，也會相應的有所增加。因為每個微服務應用所占用的資源并不是很大，所以可以在原來的服務器中使用虛擬機技術擴展服務器群組。對于微服務的部署，我們將主要以 Docker 容器為主導，使用虛擬化技術實施自動化建設，這樣可以非常自由地將微服務分散部署在分布式環(huán)境之中。而對于中小型企業(yè)來說，更好的實施方案是使用云計算服務商提供的資源，這樣能更有效地利用服務器的資源。

本文給大家講解的內容是微服務架構與SpringCloud：微服務架構與SOA 的比較、微服務架構的優(yōu)勢、為實施微服務架構做好準備

1. 下篇文章給大家講解的是Spring Cloud 的優(yōu)勢、Spring Cloud 工具套件介紹、Spring Cloud 的版本說明；

2. 覺得文章不錯的朋友可以轉發(fā)此文關注小編；

3. 感謝大家的支持！