深入理解分析微服務(wù)(上)

深入理解分析微服務(wù)(上)

前言;

今年有人提出了2019年微服務(wù)將瘋狂至死，可見微服務(wù)的爭(zhēng)論從未停止過(guò)。在這我將自己對(duì)微服務(wù)的理解整理了一下，希望對(duì)大家有所幫助。由于篇幅太長(zhǎng)，小編把他分為了上下篇，記得關(guān)注我哦

什么是微服務(wù)

1）一組小的服務(wù)（大小沒(méi)有特別的標(biāo)準(zhǔn)，只要同一團(tuán)隊(duì)的工程師理解服務(wù)的標(biāo)識(shí)一致即可）

2）獨(dú)立的進(jìn)程（java的tomcat，nodejs等）

3）輕量級(jí)的通信（不是soap，是http協(xié)議）

4）基于業(yè)務(wù)能力（類似用戶服務(wù)，商品服務(wù)等等）

5）獨(dú)立部署（迭代速度快）

6）無(wú)集中式管理（無(wú)須統(tǒng)一技術(shù)棧，可以根據(jù)不同的服務(wù)或者團(tuán)隊(duì)進(jìn)行靈活選擇）

ps：微服務(wù)的先行者Netflix公司，開源了一些好的微服務(wù)框架，后續(xù)會(huì)有介紹。

怎么權(quán)衡微服務(wù)的利于弊

利：

強(qiáng)模塊邊界 。（模塊化的演化過(guò)程：類-->組件/類庫(kù)（sdk）-->服務(wù)(service)，方式越來(lái)越靈活）

可獨(dú)立部署。

技術(shù)多樣性。

弊：

分布式復(fù)雜性。

最終一致性。（各個(gè)服務(wù)的團(tuán)隊(duì)，數(shù)據(jù)也是分散式治理，會(huì)出現(xiàn)不一致的問(wèn)題）

運(yùn)維復(fù)雜性。

測(cè)試復(fù)雜性。

企業(yè)在什么時(shí)候考慮引入微服務(wù)

從生產(chǎn)力和系統(tǒng)的復(fù)雜性這兩個(gè)方面來(lái)看。公司一開始的時(shí)候，業(yè)務(wù)復(fù)雜性不高，這時(shí)候是驗(yàn)證商業(yè)模式的時(shí)候，業(yè)務(wù)簡(jiǎn)單，用單體服務(wù)反而生產(chǎn)力很高。隨著公司的發(fā)展，業(yè)務(wù)復(fù)雜性慢慢提高，這時(shí)候就可以采用微服務(wù)來(lái)提升生產(chǎn)力了。至于這個(gè)轉(zhuǎn)化的點(diǎn)，需要團(tuán)隊(duì)的架構(gòu)師來(lái)進(jìn)行各方面衡量，就個(gè)人經(jīng)驗(yàn)而言，團(tuán)隊(duì)發(fā)展到百人以上，采用微服務(wù)就很有必要了。

有些架構(gòu)師是具有微服務(wù)架構(gòu)能力，所以設(shè)計(jì)系統(tǒng)時(shí)就直接設(shè)計(jì)成了微服務(wù)，而不是通過(guò)單服務(wù)慢慢演化發(fā)展成微服務(wù)。在這里我并不推薦這種做法，因?yàn)橐婚_始對(duì)業(yè)務(wù)領(lǐng)域并不是很了解，并且業(yè)務(wù)模式還沒(méi)有得到驗(yàn)證，這時(shí)候上微服務(wù)風(fēng)險(xiǎn)比較高，很有可能失敗。所以建議大家在單服務(wù)的應(yīng)用成熟時(shí)，并且對(duì)業(yè)務(wù)領(lǐng)域比較熟悉的時(shí)候，如果發(fā)現(xiàn)單服務(wù)無(wú)法適應(yīng)業(yè)務(wù)發(fā)展時(shí)，再考慮微服務(wù)的設(shè)計(jì)和架構(gòu)。

微服務(wù)的組織架構(gòu)

如上圖左邊，傳統(tǒng)的企業(yè)中，團(tuán)隊(duì)是按職能劃分的。開發(fā)一個(gè)項(xiàng)目時(shí)，會(huì)從不同的職能團(tuán)隊(duì)找人進(jìn)行開發(fā)，開發(fā)完成后，再各自回到自己的職能團(tuán)隊(duì)，這種模式實(shí)踐證明，效率還是比較低的。

如上圖右邊，圍繞每個(gè)業(yè)務(wù)線或產(chǎn)品，按服務(wù)劃分團(tuán)隊(duì)。團(tuán)隊(duì)成員從架構(gòu)到運(yùn)維，形成一個(gè)完整的閉環(huán)。一直圍繞在產(chǎn)品周圍，進(jìn)行不斷的迭代。不會(huì)像傳統(tǒng)的團(tuán)隊(duì)一樣離開。這樣開發(fā)效率會(huì)比較高。至于這種團(tuán)隊(duì)的規(guī)模，建議按照亞馬遜的兩個(gè)披薩原則，大概10人左右比較好。

怎么理解中臺(tái)戰(zhàn)略和微服務(wù)

中臺(tái)戰(zhàn)略的由來(lái)：馬云2015年去歐洲的一家公司supersell參觀，發(fā)現(xiàn)這個(gè)公司的創(chuàng)新能力非常強(qiáng)，團(tuán)隊(duì)的規(guī)模很小，但是開發(fā)效率很高。他們就是采用中臺(tái)戰(zhàn)略。馬云感觸很深，回國(guó)后就在集團(tuán)內(nèi)部推出了中臺(tái)戰(zhàn)略。

簡(jiǎn)單的理解就是把傳統(tǒng)的前后臺(tái)體系中的后臺(tái)進(jìn)行了細(xì)分。阿里巴巴提出了大中臺(tái)小前臺(tái)的戰(zhàn)略。就是強(qiáng)化業(yè)務(wù)和技術(shù)中臺(tái)，把前端的應(yīng)用變得更小更靈活。當(dāng)中臺(tái)越強(qiáng)大，能力就越強(qiáng)，越能更好的快速響應(yīng)前臺(tái)的業(yè)務(wù)需求。打個(gè)比喻，就是土壤越肥沃，越適合生長(zhǎng)不同的生物，打造好的生態(tài)系統(tǒng)。

服務(wù)分層

每個(gè)公司的服務(wù)分層都不相同，有的公司服務(wù)沒(méi)有分層，有的怎分層很多。目前業(yè)界沒(méi)有統(tǒng)一的標(biāo)準(zhǔn)。

下面推薦一個(gè)比較容易理解的兩層結(jié)構(gòu)。

1：基礎(chǔ)服務(wù)： 比如一個(gè)電商網(wǎng)站，商品服務(wù)和訂單服務(wù)就屬于基礎(chǔ)服務(wù)（核心領(lǐng)域服務(wù)）。緩存服務(wù)，監(jiān)控服務(wù)，消息隊(duì)列等也屬于基礎(chǔ)服務(wù)（公共服務(wù)）

2：聚合服務(wù) ：例如網(wǎng)關(guān)服務(wù)就算一種聚合服務(wù)（適配服務(wù)）。

這是一種邏輯劃分，不是物理劃分，實(shí)際設(shè)計(jì)的東西很多很復(fù)雜。

微服務(wù)的技術(shù)架構(gòu)體系

下圖是一個(gè)成型的互聯(lián)網(wǎng)微服務(wù)的架構(gòu)體系：

1：接入層 負(fù)載均衡作用，運(yùn)維團(tuán)隊(duì)負(fù)責(zé)

2：網(wǎng)關(guān)層 反向路由，安全驗(yàn)證，限流等

3：業(yè)務(wù)服務(wù)層 基礎(chǔ)服務(wù)和領(lǐng)域服務(wù)

4：支撐服務(wù)層

5：平臺(tái)服務(wù)

6：基礎(chǔ)設(shè)施層 運(yùn)維團(tuán)隊(duì)負(fù)責(zé)。（或者阿里云）

微服務(wù)的服務(wù)發(fā)現(xiàn)的三種方式

第一種：如下圖所示，傳統(tǒng)的服務(wù)發(fā)現(xiàn)（大部分公司的做法）。服務(wù)上線后，通知運(yùn)維，申請(qǐng)域名，配置路由。調(diào)用方通過(guò)dns域名解析，經(jīng)過(guò)負(fù)載均衡路由，進(jìn)行服務(wù)訪問(wèn)。缺點(diǎn)： LB的單點(diǎn)風(fēng)險(xiǎn)，服務(wù)穿透LB，性能也不是太好

第二種：也叫客戶端發(fā)現(xiàn)方式。如下圖所示。通過(guò)服務(wù)注冊(cè)的方式，服務(wù)提供者先注冊(cè)服務(wù)。消費(fèi)者通過(guò)注冊(cè)中心獲取相應(yīng)服務(wù)。

并且把LB的功能移動(dòng)到了消費(fèi)者的進(jìn)程內(nèi)，消費(fèi)者根據(jù)自身路由去獲取相應(yīng)服務(wù)。優(yōu)點(diǎn)是，沒(méi)有了LB單點(diǎn)問(wèn)題，也沒(méi)有了LB的中間一跳，性能也比較好。但是這種方式有一個(gè)非常明顯的缺點(diǎn)就是具有非常強(qiáng)的耦合性。針對(duì)不同的語(yǔ)言，每個(gè)服務(wù)的客戶端都得實(shí)現(xiàn)一套服務(wù)發(fā)現(xiàn)的功能。

第三種：也叫服務(wù)端發(fā)現(xiàn)方式，如下圖所示。和第二種很相似。但是LB功能獨(dú)立進(jìn)程單獨(dú)部署，所以解決了客戶端多語(yǔ)言開發(fā)的問(wèn)題。唯一的缺點(diǎn)就是運(yùn)維成比較高，每個(gè)節(jié)點(diǎn)都得部署一個(gè)LB的代理，例如nginx。

微服務(wù)網(wǎng)關(guān)

網(wǎng)關(guān)就好比一個(gè)公司的門衛(wèi)。屏蔽內(nèi)部細(xì)節(jié)，統(tǒng)一對(duì)外服務(wù)接口。

下圖是一個(gè)網(wǎng)關(guān)所處位置的示例圖。

Netflix Zuul網(wǎng)關(guān)介紹

核心就是一個(gè)servlet，通過(guò)filter機(jī)制實(shí)現(xiàn)的。主要分為三類過(guò)濾器：前置過(guò)濾器，過(guò)濾器和后置過(guò)濾器。

主要特色是，這些過(guò)濾器可以動(dòng)態(tài)插拔，就是如果需要增加減少過(guò)濾器，可以不用重啟，直接生效。原理就是：通過(guò)一個(gè)db維護(hù)過(guò)濾器（上圖藍(lán)色部分），如果增加過(guò)濾器，就將新過(guò)濾器編譯完成后push到db中，有線程會(huì)定期掃描db，發(fā)現(xiàn)新的過(guò)濾器后，會(huì)上傳到網(wǎng)關(guān)的相應(yīng)文件目錄下，并通知過(guò)濾器loader進(jìn)行加載相應(yīng)的過(guò)濾器。

整個(gè)網(wǎng)關(guān)調(diào)用的流程

上圖從左變http Request開始經(jīng)過(guò)三類過(guò)濾器，最終到最右邊的Http Response，這就是Zull網(wǎng)關(guān)的整個(gè)調(diào)用流程。

微服務(wù)的路由發(fā)現(xiàn)體系

整個(gè)微服務(wù)的路由發(fā)現(xiàn)體系，一般由服務(wù)注冊(cè)中心和網(wǎng)關(guān)兩部分組成。以NetFlix為例子，Eureka和Zull這兩個(gè)組件支撐了netFlix整個(gè)的路由發(fā)現(xiàn)體系。如下圖所示，首先外部請(qǐng)求發(fā)送到網(wǎng)關(guān)，網(wǎng)關(guān)去服務(wù)注冊(cè)中心獲取相應(yīng)的服務(wù)，進(jìn)行調(diào)用。其次內(nèi)部服務(wù)間的調(diào)用，也通過(guò)服務(wù)注冊(cè)中心進(jìn)行的

微服務(wù)配置中心

目前大部分公司都是把配置寫到配置文件中，遇到修改配置的情況，成本很高。并且沒(méi)有修改配置的記錄，出問(wèn)題很難追溯。配置中心就接解決了以上的問(wèn)題。

可配置內(nèi)容：數(shù)據(jù)庫(kù)連接，業(yè)務(wù)參數(shù)等等

配置中心就是一個(gè)web服務(wù)，配置人員通過(guò)后臺(tái)頁(yè)面修改配置，各個(gè)服務(wù)就會(huì)得到新的配置參數(shù)。實(shí)現(xiàn)方式主要有兩種，一種是push，另一種是pull。兩張方式各有優(yōu)缺點(diǎn)。push實(shí)時(shí)性較好，但是遇到網(wǎng)絡(luò)抖動(dòng)，會(huì)丟失消息。pull不會(huì)丟失消息但是實(shí)時(shí)性差一些。大家可以同時(shí)兩種方式使用，實(shí)現(xiàn)一個(gè)比較好的效果。如下圖所示，這是一個(gè)國(guó)內(nèi)知名互聯(lián)網(wǎng)公司的配置中心架構(gòu)圖。

RPC遇到了REST

內(nèi)部一些核心服務(wù)，性能要求比較高的可以采用RPC，對(duì)外服務(wù)的一般可以采用rest。

上半部分先分享到這里，記得關(guān)注我哦，每天都會(huì)分享java有關(guān)的文章

?