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

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

10年積累的網(wǎng)站制作、網(wǎng)站建設(shè)經(jīng)驗(yàn),可以快速應(yīng)對(duì)客戶對(duì)網(wǎng)站的新想法和需求。提供各種問(wèn)題對(duì)應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認(rèn)識(shí)你,你也不認(rèn)識(shí)我。但先網(wǎng)站制作后付款的網(wǎng)站建設(shè)流程,更有安龍免費(fèi)網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。

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

前言;

今年有人提出了2019年微服務(wù)將瘋狂至死,可見(jiàn)微服務(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公司,開(kāi)源了一些好的微服務(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)看。公司一開(kā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)橐婚_(kāi)始對(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)

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

如上圖左邊,傳統(tǒng)的企業(yè)中,團(tuán)隊(duì)是按職能劃分的。開(kāi)發(fā)一個(gè)項(xiàng)目時(shí),會(huì)從不同的職能團(tuán)隊(duì)找人進(jìn)行開(kāi)發(fā),開(kāi)發(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ì)一樣離開(kāi)。這樣開(kāi)發(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ī)模很小,但是開(kāi)發(fā)效率很高。他們就是采用中臺(tái)戰(zhàn)略。馬云感觸很深,回國(guó)后就在集團(tuán)內(nèi)部推出了中臺(tái)戰(zhàn)略。

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

簡(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)。

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

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)體系:

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

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,性能也不是太好

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

第二種:也叫客戶端發(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ù)(上)

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

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

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

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

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

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

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

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

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

核心就是一個(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ò)濾器。

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

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

上圖從左變http Request開(kāi)始經(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ù)(上)

微服務(wù)配置中心

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

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

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

配置中心就是一個(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)圖。

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

RPC遇到了REST

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

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

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

?

本文名稱:深入理解分析微服務(wù)(上)
本文路徑:http://bm7419.com/article6/jcioig.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供網(wǎng)站策劃、品牌網(wǎng)站建設(shè)關(guān)鍵詞優(yōu)化、網(wǎng)站內(nèi)鏈、App開(kāi)發(fā)、面包屑導(dǎo)航

廣告

聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請(qǐng)盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如需處理請(qǐng)聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來(lái)源: 創(chuàng)新互聯(lián)

成都網(wǎng)頁(yè)設(shè)計(jì)公司