微服務(wù)架構(gòu)與SOA的比較

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

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

微服務(wù)架構(gòu)與 SOA 從表面上看是有一點(diǎn)相似的，以至于早期有人認(rèn)為微服務(wù)就是一個細(xì)粒度的 SOA。實際上，它們的區(qū)別還是很大的。

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

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

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

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

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

微服務(wù)架構(gòu)的優(yōu)勢

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

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

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

第二，快速響應(yīng)需求變化。

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

第三，隨時隨地更新。

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

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

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

第五，規(guī)?？沙掷m(xù)擴(kuò)展。

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

為實施微服務(wù)架構(gòu)做好準(zhǔn)備

微服務(wù)架構(gòu) 不是 種新技術(shù)，它只是一種全新的設(shè)計理念，所以，為了能夠更好地實施微服務(wù)架構(gòu)設(shè)計，我們必須做好前期準(zhǔn)備，從思想觀念、團(tuán)隊管理和自動化基礎(chǔ)設(shè)施上進(jìn)行相應(yīng)的變革。

思想觀念

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

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

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

團(tuán)隊管理

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

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

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

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

自動化基礎(chǔ)設(shè)施

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

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

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

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

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

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

3. 感謝大家的支持！