剛開始進(jìn)入軟件行業(yè)時(shí)還是單體應(yīng)用的時(shí)代，前后端分離的概念都還沒普及，開發(fā)的時(shí)候需要花大量的時(shí)間在“強(qiáng)大”的JSP上面，那時(shí)候SOA已經(jīng)算是新技術(shù)了?，F(xiàn)在，微服務(wù)已經(jīng)大行其道，有哪個(gè)互聯(lián)網(wǎng)產(chǎn)品不說(shuō)自己是微服務(wù)架構(gòu)呢？
但是，對(duì)于微服務(wù)的理解每個(gè)人都不太一樣，這篇文章主要是聊一聊我對(duì)微服務(wù)的理解以及如何搭建經(jīng)典的微服務(wù)架構(gòu)，目的是梳理一下自己的一些想法，如果存在不同看法的歡迎指正！
首先，什么是微服務(wù)呢？
相對(duì)的，要理解什么是微服務(wù)，那么可以先理解什么是單體應(yīng)用，在沒有提出微服務(wù)的概念的“遠(yuǎn)古”年代，一個(gè)軟件應(yīng)用，往往會(huì)將應(yīng)用所有功能都開發(fā)和打包在一起，那時(shí)候的一個(gè)B/S應(yīng)用架構(gòu)往往是這樣的：
B/S
但是，當(dāng)用戶訪問量變大導(dǎo)致一臺(tái)服務(wù)器無(wú)法支撐時(shí)怎么辦呢？加服務(wù)器加負(fù)載均衡，架構(gòu)就變成這樣了：
B/S+負(fù)載均衡
后面發(fā)現(xiàn)把靜態(tài)文件獨(dú)立出來(lái)，通過CDN等手段進(jìn)行加速，可以提升應(yīng)用的整體相應(yīng)，單體應(yīng)用的架構(gòu)就變成：
B/S+前后端分離
上面3中架構(gòu)都還是單體應(yīng)用，只是在部署方面進(jìn)行了優(yōu)化，所以避免不了單體應(yīng)用的根本的缺點(diǎn)：
代碼臃腫，應(yīng)用啟動(dòng)時(shí)間長(zhǎng)；（代碼超過1G的項(xiàng)目都有?。?/p>
回歸測(cè)試周期長(zhǎng)，修復(fù)一個(gè)小小bug可能都需要對(duì)所有關(guān)鍵業(yè)務(wù)進(jìn)行回歸測(cè)試。
應(yīng)用容錯(cuò)性差，某個(gè)小小功能的程序錯(cuò)誤可能導(dǎo)致整個(gè)系統(tǒng)宕機(jī)；
伸縮困難，單體應(yīng)用擴(kuò)展性能時(shí)只能整個(gè)應(yīng)用進(jìn)行擴(kuò)展，造成計(jì)算資源浪費(fèi)。
開發(fā)協(xié)作困難，一個(gè)大型應(yīng)用系統(tǒng)，可能幾十個(gè)甚至上百個(gè)開發(fā)人員，大家都在維護(hù)一套代碼的話，代碼merge復(fù)雜度急劇增加。
我認(rèn)為任何技術(shù)的演進(jìn)都是有跡可循的，任何新技術(shù)的出現(xiàn)都是為了解決原有技術(shù)無(wú)法解決的需求，所以，微服務(wù)的出現(xiàn)就是因?yàn)樵瓉?lái)單體應(yīng)用架構(gòu)已經(jīng)無(wú)法滿足當(dāng)前互聯(lián)網(wǎng)產(chǎn)品的技術(shù)需求。
在微服務(wù)架構(gòu)之前還有一個(gè)概念：SOA（Service-Oriented Architecture）-面向服務(wù)的體系架構(gòu)。我認(rèn)為的SOA只是一個(gè)架構(gòu)模型的方法論，并不是一個(gè)明確而嚴(yán)謹(jǐn)?shù)募軜?gòu)標(biāo)準(zhǔn)，只是后面很多人將SOA與The Open Group的SOA參考模型等同了，認(rèn)為嚴(yán)格按照TOG-SOA標(biāo)準(zhǔn)的才算真正的SOA架構(gòu)。SOA就已經(jīng)提出的面向服務(wù)的架構(gòu)思想，所以微服務(wù)應(yīng)該算是SOA的一種演進(jìn)吧。
撇開架構(gòu)先不說(shuō)，什么樣的服務(wù)才算微服務(wù)呢？
單一職責(zé)的。一個(gè)微服務(wù)應(yīng)該都是單一職責(zé)的，這才是“微”的體現(xiàn)，一個(gè)微服務(wù)解決一個(gè)業(yè)務(wù)問題（注意是一個(gè)業(yè)務(wù)問題而不是一個(gè)接口）。
面向服務(wù)的。將自己的業(yè)務(wù)能力封裝并對(duì)外提供服務(wù)，這是繼承SOA的核心思想，一個(gè)微服務(wù)本身也可能使用到其它微服務(wù)的能力。 我覺得滿足以上兩點(diǎn)就可以認(rèn)為典型的微服務(wù)。
微服務(wù)架構(gòu)，核心是為了解決應(yīng)用微服務(wù)化之后的服務(wù)治理問題。
應(yīng)用微服務(wù)化之后，首先遇到的第一個(gè)問題就是服務(wù)發(fā)現(xiàn)問題，一個(gè)微服務(wù)如何發(fā)現(xiàn)其他微服務(wù)呢？最簡(jiǎn)單的方式就是每個(gè)微服務(wù)里面配置其他微服務(wù)的地址，但是當(dāng)微服務(wù)數(shù)量眾多的時(shí)候，這樣做明顯不現(xiàn)實(shí)。所以需要使用到微服務(wù)架構(gòu)中的一個(gè)最重要的組件：服務(wù)注冊(cè)中心，所有服務(wù)都注冊(cè)到服務(wù)注冊(cè)中心，同時(shí)也可以從服務(wù)注冊(cè)中心獲取當(dāng)前可用的服務(wù)清單：
服務(wù)注冊(cè)中心
解決服務(wù)發(fā)現(xiàn)問題后，接著需要解決微服務(wù)分布式部署帶來(lái)的第二個(gè)問題：服務(wù)配置管理的問題。當(dāng)服務(wù)數(shù)量超過一定程度之后，如果需要在每個(gè)服務(wù)里面分別維護(hù)每一個(gè)服務(wù)的配置文件，運(yùn)維人員估計(jì)要哭了。那么，就需要用到微服務(wù)架構(gòu)里面第二個(gè)重要的組件：配置中心，微服務(wù)架構(gòu)就變成下面這樣了：
配置中心
以上應(yīng)用內(nèi)部的服務(wù)治理，當(dāng)客戶端或外部應(yīng)用調(diào)用服務(wù)的時(shí)候怎么處理呢？服務(wù)A可能有多個(gè)節(jié)點(diǎn)，服務(wù)A、服務(wù)B和服務(wù)C的服務(wù)地址都不同，服務(wù)授權(quán)驗(yàn)證在哪里做？這時(shí)，就需要使用到服務(wù)網(wǎng)關(guān)提供統(tǒng)一的服務(wù)入口，最終形成典型微服務(wù)架構(gòu)：
典型微服務(wù)架構(gòu)
上面是一個(gè)典型的微服務(wù)架構(gòu)，當(dāng)然微服務(wù)的服務(wù)治理還涉及很多內(nèi)容，比如：
通過熔斷、限流等機(jī)制保證高可用；
微服務(wù)之間調(diào)用的負(fù)載均衡；
分布式事務(wù)（2PC、3PC、TCC、LCN等）；
服務(wù)調(diào)用鏈跟蹤等等。
決定技術(shù)框架。Spring Cloud全家桶提供了各種各樣的組件，基本可以覆蓋微服務(wù)的服務(wù)治理的方方面面，以下列出了Spring Cloud一些常用組件：
Spring Cloud常用組件
目前網(wǎng)上很多說(shuō)是下一代微服務(wù)架構(gòu)就是Service Mesh，Service Mesh主流框架有Linkerd和Istio，其中Istio有大廠加持所以呼聲更高。Service Mesh我接觸還不多，但是個(gè)人感覺并不一定能稱為下一代微服務(wù)架構(gòu)，可能認(rèn)為是服務(wù)治理的另外一種解決方案更合適，是否能夠取代當(dāng)前的微服務(wù)架構(gòu)還需要持續(xù)觀察。
聯(lián)系客服
