開篇

剛開始進入軟件行業(yè)時還是單體應(yīng)用的時代，前后端分離的概念都還沒普及，開發(fā)的時候需要花大量的時間在“強大”的JSP上面，那時候SOA已經(jīng)算是新技術(shù)了?，F(xiàn)在，微服務(wù)已經(jīng)大行其道，有哪個互聯(lián)網(wǎng)產(chǎn)品不說自己是微服務(wù)架構(gòu)呢？

但是，對于微服務(wù)的理解每個人都不太一樣，這篇文章主要是聊一聊我對微服務(wù)的理解以及如何搭建經(jīng)典的微服務(wù)架構(gòu)，目的是梳理一下自己的一些想法，如果存在不同看法的歡迎指正！

什么是微服務(wù)

首先，什么是微服務(wù)呢？

單體應(yīng)用

相對的，要理解什么是微服務(wù)，那么可以先理解什么是單體應(yīng)用，在沒有提出微服務(wù)的概念的“遠古”年代，一個軟件應(yīng)用，往往會將應(yīng)用所有功能都開發(fā)和打包在一起，那時候的一個B/S應(yīng)用架構(gòu)往往是這樣的：

B/S

但是，當(dāng)用戶訪問量變大導(dǎo)致一臺服務(wù)器無法支撐時怎么辦呢？加服務(wù)器加負載均衡，架構(gòu)就變成這樣了：

B/S+負載均衡

后面發(fā)現(xiàn)把靜態(tài)文件獨立出來，通過CDN等手段進行加速，可以提升應(yīng)用的整體相應(yīng)，單體應(yīng)用的架構(gòu)就變成：

B/S+前后端分離

上面3中架構(gòu)都還是單體應(yīng)用，只是在部署方面進行了優(yōu)化，所以避免不了單體應(yīng)用的根本的缺點：

• 代碼臃腫，應(yīng)用啟動時間長；（代碼超過1G的項目都有?。?/p>

• 回歸測試周期長，修復(fù)一個小小bug可能都需要對所有關(guān)鍵業(yè)務(wù)進行回歸測試。

• 應(yīng)用容錯性差，某個小小功能的程序錯誤可能導(dǎo)致整個系統(tǒng)宕機；

• 伸縮困難，單體應(yīng)用擴展性能時只能整個應(yīng)用進行擴展，造成計算資源浪費。

• 開發(fā)協(xié)作困難，一個大型應(yīng)用系統(tǒng)，可能幾十個甚至上百個開發(fā)人員，大家都在維護一套代碼的話，代碼merge復(fù)雜度急劇增加。

微服務(wù)

我認為任何技術(shù)的演進都是有跡可循的，任何新技術(shù)的出現(xiàn)都是為了解決原有技術(shù)無法解決的需求，所以，微服務(wù)的出現(xiàn)就是因為原來單體應(yīng)用架構(gòu)已經(jīng)無法滿足當(dāng)前互聯(lián)網(wǎng)產(chǎn)品的技術(shù)需求。

在微服務(wù)架構(gòu)之前還有一個概念：SOA（Service-Oriented Architecture）-面向服務(wù)的體系架構(gòu)。我認為的SOA只是一個架構(gòu)模型的方法論，并不是一個明確而嚴謹?shù)募軜?gòu)標準，只是后面很多人將SOA與The Open Group的SOA參考模型等同了，認為嚴格按照TOG-SOA標準的才算真正的SOA架構(gòu)。SOA就已經(jīng)提出的面向服務(wù)的架構(gòu)思想，所以微服務(wù)應(yīng)該算是SOA的一種演進吧。

撇開架構(gòu)先不說，什么樣的服務(wù)才算微服務(wù)呢？

• 單一職責(zé)的。一個微服務(wù)應(yīng)該都是單一職責(zé)的，這才是“微”的體現(xiàn)，一個微服務(wù)解決一個業(yè)務(wù)問題（注意是一個業(yè)務(wù)問題而不是一個接口）。

• 面向服務(wù)的。將自己的業(yè)務(wù)能力封裝并對外提供服務(wù)，這是繼承SOA的核心思想，一個微服務(wù)本身也可能使用到其它微服務(wù)的能力。 我覺得滿足以上兩點就可以認為典型的微服務(wù)。

微服務(wù)典型架構(gòu)

微服務(wù)架構(gòu)，核心是為了解決應(yīng)用微服務(wù)化之后的服務(wù)治理問題。

應(yīng)用微服務(wù)化之后，首先遇到的第一個問題就是服務(wù)發(fā)現(xiàn)問題，一個微服務(wù)如何發(fā)現(xiàn)其他微服務(wù)呢？最簡單的方式就是每個微服務(wù)里面配置其他微服務(wù)的地址，但是當(dāng)微服務(wù)數(shù)量眾多的時候，這樣做明顯不現(xiàn)實。所以需要使用到微服務(wù)架構(gòu)中的一個最重要的組件：服務(wù)注冊中心，所有服務(wù)都注冊到服務(wù)注冊中心，同時也可以從服務(wù)注冊中心獲取當(dāng)前可用的服務(wù)清單：

服務(wù)注冊中心

解決服務(wù)發(fā)現(xiàn)問題后，接著需要解決微服務(wù)分布式部署帶來的第二個問題：服務(wù)配置管理的問題。當(dāng)服務(wù)數(shù)量超過一定程度之后，如果需要在每個服務(wù)里面分別維護每一個服務(wù)的配置文件，運維人員估計要哭了。那么，就需要用到微服務(wù)架構(gòu)里面第二個重要的組件：配置中心，微服務(wù)架構(gòu)就變成下面這樣了：

配置中心

以上應(yīng)用內(nèi)部的服務(wù)治理，當(dāng)客戶端或外部應(yīng)用調(diào)用服務(wù)的時候怎么處理呢？服務(wù)A可能有多個節(jié)點，服務(wù)A、服務(wù)B和服務(wù)C的服務(wù)地址都不同，服務(wù)授權(quán)驗證在哪里做？這時，就需要使用到服務(wù)網(wǎng)關(guān)提供統(tǒng)一的服務(wù)入口，最終形成典型微服務(wù)架構(gòu)：

典型微服務(wù)架構(gòu)

上面是一個典型的微服務(wù)架構(gòu)，當(dāng)然微服務(wù)的服務(wù)治理還涉及很多內(nèi)容，比如：

• 通過熔斷、限流等機制保證高可用；

• 微服務(wù)之間調(diào)用的負載均衡；

• 分布式事務(wù)（2PC、3PC、TCC、LCN等）；

• 服務(wù)調(diào)用鏈跟蹤等等。

微服務(wù)框架

決定技術(shù)框架。Spring Cloud全家桶提供了各種各樣的組件，基本可以覆蓋微服務(wù)的服務(wù)治理的方方面面，以下列出了Spring Cloud一些常用組件：

Spring Cloud常用組件

下一代微服務(wù)

目前網(wǎng)上很多說是下一代微服務(wù)架構(gòu)就是Service Mesh，Service Mesh主流框架有Linkerd和Istio，其中Istio有大廠加持所以呼聲更高。Service Mesh我接觸還不多，但是個人感覺并不一定能稱為下一代微服務(wù)架構(gòu)，可能認為是服務(wù)治理的另外一種解決方案更合適，是否能夠取代當(dāng)前的微服務(wù)架構(gòu)還需要持續(xù)觀察。