微服務(wù)架構(gòu)與Spring Cloud

近幾年大家都在談?wù)撛圃臀⒎?wù)，例如

? 云原生技術(shù)能夠幫助公司和機構(gòu)在私有云、公有云和混有云等新型動態(tài)環(huán)境中，構(gòu)建和運行可彈性擴展的應(yīng)用。

微服務(wù)架構(gòu)是一項在云端部署應(yīng)用和服務(wù)的新技術(shù)。

諸如此類，不一而足。

而在實際中，我們也同樣可以看到，越來越多的企業(yè)和機構(gòu)都使用了基于 Spring Cloud架的技術(shù)開發(fā)微服務(wù)，組建基于云端服務(wù)器的應(yīng)用平臺。

那么對于一個企業(yè)、一個系統(tǒng)架師，或者從事 IT 行業(yè)的人員來說，對這些技術(shù)應(yīng)該如何選擇，架構(gòu)設(shè)計應(yīng)該如何定位，才能順應(yīng)技術(shù)潮流，處于技術(shù)的領(lǐng)先水平。

在這些新概念、新技術(shù)“滿天飛”的環(huán)境中，我們需要理清思維，才能確定方向，從而在我們的企業(yè)應(yīng)用開發(fā)中發(fā)揮更好的效能。

微服務(wù)架構(gòu)的特點

在介紹微服務(wù)架構(gòu)之前，我們先來看看云原生的概念。

云原生的概念，最早由 Pivotal 團隊的 Matt Stine 2013 年提出。這個概念提出之后，在各大社區(qū)掀起了討論的熱潮，并得到了社區(qū)的不斷完善。顧名思義，云原生是指專門為云平臺部署和運行而設(shè)計的應(yīng)用。云原生包含的內(nèi)容非常多，包括DevOps （開發(fā)運維一體化〉、持續(xù)交付、微服務(wù)、敏捷基礎(chǔ)設(shè)施和12要素等幾大主題。

2015 年， Linux 基金會領(lǐng)頭成立了云原生應(yīng)用基金會（ Cloud Native Computing Foundation,CNC凹，它致力于云原生技術(shù)的普及和可持續(xù)發(fā)展。CNCF 認(rèn)為云原生系統(tǒng)必須包含的屬性有容器化封裝、自動化管理和面向微服務(wù)。

現(xiàn)在我們來看看微服務(wù)架構(gòu)的概念。

據(jù)說早在 2011 月，在威尼斯附近的一個軟件架構(gòu)師研討會上，就有人提出了微服務(wù)架構(gòu)設(shè)計的概念，用它來描述與會者所看見的一種通用的架構(gòu)設(shè)計風(fēng)格。時隔一年之后，在同一個研討會上，大家決定將這種架構(gòu)設(shè)計風(fēng)格用微服務(wù)架構(gòu)來表示。

剛開始，對于微服務(wù)架構(gòu)是沒有一個完整的描述的，其可以看到的主要特征就是小型化、細粒度，以及使用輕量的 HTTP 通信等。

2014 月，在 James Lewis Martin Fowler 發(fā)表的一篇博客文章中，總結(jié)了微服務(wù)架構(gòu)設(shè)計的一些共同特點。下面摘錄的一段描述，被普遍認(rèn)為可以作為微服務(wù)架構(gòu)的定義：“簡而言之，微服務(wù)架構(gòu)是將單個應(yīng)用程序作為一組小型服務(wù)開發(fā)的方法，每個服務(wù)程序都在自己的進程中運行，并與輕量級機制（通常是 Hπ？資源 API) 進行通信。這些服務(wù)是圍繞業(yè)務(wù)功能構(gòu)建的，可以通過全自動部署機器獨立部署。這些服務(wù)可能用不同的編程語言編寫，使用不同的數(shù)據(jù)存儲技術(shù)，并盡量不用集中式方式進行管理。

上面提到的單個應(yīng)用程序是指傳統(tǒng)設(shè)計中的一個應(yīng)用系統(tǒng)，或者一個大型應(yīng)用，現(xiàn)在大家流行把它叫作單體應(yīng)用。

可以看出，微服務(wù)架構(gòu)是將一個大型系統(tǒng)使用小型化分割的方法，按業(yè)務(wù)功能拆分成各種獨立的小應(yīng)用。在各個小應(yīng)用之間，可以使用輕量機制，即基于 RESTful HTTP 進行通信，并以這種通信方式替換原來在程序之間直接調(diào)用的方式。微服務(wù)就是通過這種架構(gòu)設(shè)計方法拆分出來的一個個獨立的小型應(yīng)用。

將一個大型系統(tǒng)分割成一些小型應(yīng)用，而小型應(yīng)用之間通過 Hη？進行整合，這就是微服務(wù)架構(gòu)的精髓所在。我們可以用一句通俗易懂的話來概括，那就是“分而治之，合而用之”。

從上面微服務(wù)架構(gòu)的描述中，我們可以概括出微服務(wù)架構(gòu)的幾個顯著特點。

1. 小型化

微服務(wù)架構(gòu)的的突出之處就是小型化應(yīng)用設(shè)計、最顯著的特點就是應(yīng)用程序變小了，以小為美。小型化的方式，使每個程序只負(fù)責(zé)完成一定范圍內(nèi)的業(yè)務(wù)功能，可以更加專一地做好一件事情。這是我們?nèi)粘＝鉀Q復(fù)雜問題的常用手法，即“大事化小，小事化無”。

2.自治化

每個微服務(wù)都是一個獨立的應(yīng)用，獨立使用數(shù)據(jù)庫，獨立部署，獨立運行。這種獨立性符合高內(nèi)聚松搞合的設(shè)計原則。在微服務(wù)開發(fā)和維護過程中，每個微服務(wù)都是獨立自治的，一個服務(wù)的更新和迭代不會依賴于其他服務(wù)，同時也可以盡可能做到不對其他服務(wù)造成影響，或者可以將這種影響降到最小。

3. 扁平化

去中心化的扁平化管理，可以更加自由地發(fā)揮每一個微服務(wù)的優(yōu)勢。但是這種自由并不是隨意的混搭和組合，而是使用智能化的服務(wù)治理，讓更多的微服務(wù)在發(fā)揮個性優(yōu)勢的同時，處在一種雜而不亂的有序可控的范圍之內(nèi)。雖然從整體上微服務(wù)已 沒有 中管理的概念，但是微服務(wù)可以從全局范圍出發(fā)，發(fā)揮更佳的性能優(yōu)勢。

4. 輕量級設(shè)計

微服務(wù)小型化的特點，就是輕 級設(shè)計方法的最好體現(xiàn)。這種輕量級的設(shè)計同樣體現(xiàn)在微服務(wù)的通信設(shè)計之中。微服務(wù)之間的常用通 方式有兩種，一種是使用輕 REST 協(xié)議進行API 式的同步通信，另一種是使用輕量的異步消息通信

5. 漸進式設(shè)計

一個產(chǎn)品從成型到成熟是要經(jīng)歷 個過程的，這個過程是漸進式設(shè)計的。由于微服務(wù)小型而獨立的特點，使得微服務(wù)設(shè)計可以以業(yè)務(wù)驅(qū)動的方式進行快速迭代，從而不斷 正和調(diào)整，使產(chǎn)品趨于成熟。所以，微服務(wù)非常適合敏捷開發(fā)。

微服務(wù)架構(gòu)與整體式架構(gòu)的區(qū)別

如果是一個小型項目，則使用整體式（單體式）架構(gòu)設(shè)計，其好處非常明顯，因為它的設(shè)計和開發(fā)，以及測試和部署，都可以在一個項目上完成。

如果一個業(yè)務(wù)復(fù)雜的大型項目也使用整體式架構(gòu)設(shè)計，就會存在很多問題。可能剛開始的時候，還感覺不到什么，但是隨著時間的推移，加入的功能越來越多了，一個項目就變成了一塊巨大的石頭，笨重而丑陋。

面對一個巨大的項目，開發(fā)人員想要弄清楚它的代碼邏輯，就必須花費很多的時間。而針對某一項功能的更改，極有可能“牽一發(fā)而動全身”，這會讓實施人員變得舉步維艱。所以這種項目將會變得越來越難以維護，越來越不便更新。

整體式架構(gòu)的穩(wěn)定性也不能得到有效的保障，如果其中的一個模塊出現(xiàn)問題，將會影響整個系統(tǒng)的正常運行，甚至造成整個系統(tǒng)的崩潰。而在對問題進行跟蹤時，因為系統(tǒng)龐大，往往難上加難。

另外，一個巨大的項目，也不方便進行持續(xù)開發(fā)，它不能適應(yīng)需求的快速變更，無法使用快速迭代的敏捷開發(fā)方法，也不便在某些方面進行新技術(shù)的更替，所以這樣的項目最終就變成了業(yè)務(wù)發(fā)展的絆腳石。

相比之下，大型項目使用微服務(wù)架構(gòu)的優(yōu)勢非常明顯。

微服務(wù)架構(gòu)設(shè)計，就是把復(fù)雜事情進行簡單化處理。它將一個復(fù)雜的系統(tǒng)，拆分成一些小型的應(yīng)用來開發(fā)，首先就將問題進行了分層和簡化。因為小型而變得簡單，代碼的邏輯會變得更加清晰，這無疑解放了程序員繁重的勞動：因為簡單，所以能夠?qū)Ｗ?，能夠?qū)⒚恳患虑槎甲龊?，做到極致。

微服務(wù)架構(gòu)中獨立的小型應(yīng)用，非常適合使用敏捷開發(fā)方法，即快速響應(yīng)需求的變化，進行快速的更新、迭代。

因為每個微服務(wù)都是獨立自治的，即一個服務(wù)的故障不會影響全局系統(tǒng)的正常運行，或者說可以將這種影響降到最低。并且，微服務(wù)架構(gòu)的容錯設(shè)計，可以避免這種情況的發(fā)生。

微服務(wù)架構(gòu)高可用的特點，是系統(tǒng)穩(wěn)定性的最好保障。微服務(wù)能夠支持高并發(fā)的調(diào)用、高流量的訪問，能夠持續(xù)滿足平臺規(guī)?；l(fā)展的要求，可以很容易地使用彈性化設(shè)計，所有這些是整體式架構(gòu)無法做到的。

如果我們用一個六邊形結(jié)構(gòu)來表示整體式架構(gòu)，則可以繪制出如圖 1-1 所示的結(jié)構(gòu)圖。

這個六邊形的核心是整體式架構(gòu)的領(lǐng)域業(yè)務(wù)模型，它通過系統(tǒng)接口使用各種適配器，如數(shù)據(jù)庫適配器、文件適配器等，與外部管理系統(tǒng)進行連接：然后又通過接口，使用諸如 RESTAPI適配器、 WebUI 適配器等給外部 App 和終端用戶提供接口調(diào)用和 Web 訪問等服務(wù)。

從圖1-1中可以看出，整體式架構(gòu)是一個大而全的系統(tǒng)。在微服務(wù)架構(gòu)設(shè)計中，我們可以使用一個小正方體來表示每個微服務(wù)，它相當(dāng)于對整體式架構(gòu)進行拆分之后得到的結(jié)果，如圖1-2所示。

小正方體的微服務(wù)同樣使用接口，同樣通過各種適配器連接外部管理系統(tǒng)，而微服務(wù)之間也可以通過接口，使用阻?API 適配器進行通信。對于?App 和終端用戶，將分別由不同的微服務(wù)提供相應(yīng)的適配器及服務(wù)。

通過對上面這兩種結(jié)構(gòu)圖形的比較可以非常明顯地看出整體式架構(gòu)與微服務(wù)架構(gòu)的區(qū)別。

本文給大家講解的內(nèi)容是微服務(wù)架構(gòu)與SpringCloud：微服務(wù)架構(gòu)的特點、微服務(wù)架構(gòu)與整體式架構(gòu)的區(qū)別

1. 下篇文章給大家講解的是微服務(wù)架構(gòu)與 SOA 的比較、微服務(wù)架構(gòu)的優(yōu)勢；

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

3. 感謝大家的支持！