關(guān)于微服務(wù)的一些問(wèn)題的解答
大小:0.4 MB 人氣: 2017-10-11 需要積分:1
推薦 + 挑錯(cuò) + 收藏(0) + 用戶評(píng)論(0)
標(biāo)簽:微服務(wù)(7167)
微服務(wù)確實(shí)很受歡迎,但是對(duì)于微服務(wù)的誤解也是事實(shí),本文對(duì)這些誤解一一來(lái)介紹下:
一、微服務(wù)不夠“微”?
盡管微服務(wù)定義的很明確,但是開(kāi)發(fā)者社區(qū)對(duì)它的解釋卻頗有爭(zhēng)議,主要的一些問(wèn)題如下:
1.它是否是單體架構(gòu)的代表?
2.它是否是單體服務(wù)的代表?
3.它是否是邏輯功能的組合?
下面讓我們以銀行應(yīng)用為例來(lái)討論一下:三層架構(gòu)解決了技術(shù)組件之間的緊耦合問(wèn)題,允許它們各自獨(dú)立改變而不相互依賴。例如: Web端的改變不會(huì)影響到后端服務(wù)。 但是三層架構(gòu)沒(méi)有把基于組件分組的功能和特性考慮進(jìn)去,為此我想出了一個(gè)“功能型”架構(gòu)的名稱,以表明架構(gòu)需要通過(guò)產(chǎn)品的特征來(lái)劃分。這對(duì)于現(xiàn)代應(yīng)用的性能和吞吐量是至關(guān)重要的,我會(huì)在文章中對(duì)細(xì)節(jié)做進(jìn)一步的解釋。
二、 微服務(wù)可伸縮性
微服務(wù)是一種架構(gòu)風(fēng)格,它允許你向規(guī)模化的宏偉系統(tǒng)進(jìn)攻,這是怎么做到的呢?傳統(tǒng)的三層架構(gòu)服務(wù)能伸縮可被擴(kuò)展,那微服務(wù)有啥特別之處呢?例如:在線旅行預(yù)定,購(gòu)買請(qǐng)求和預(yù)定請(qǐng)求比例是100:1
1.這意味著什么呢, 101個(gè)請(qǐng)求中,購(gòu)買請(qǐng)求能達(dá)到100個(gè),而預(yù)定請(qǐng)求只有1個(gè);
2.這就敲響了警鐘!預(yù)定需要的資源遠(yuǎn)遠(yuǎn)小于購(gòu)買所占用的資源,為何不將整個(gè)系統(tǒng)按照期望比例縮放成100:1呢?
三、 微服務(wù)幫助維護(hù)和運(yùn)行
“滾動(dòng)式重啟”, “熱部署”, “輪詢式部署, ”是不是聽(tīng)起來(lái)很熟悉?用最短的停機(jī)時(shí)間來(lái)維護(hù)應(yīng)用系統(tǒng),是現(xiàn)代應(yīng)用系統(tǒng)的一個(gè)狀態(tài)優(yōu)先級(jí)典型表現(xiàn)。 讓我們舉個(gè)例子,改變應(yīng)用將會(huì)貫穿整個(gè)三層架構(gòu),包括數(shù)據(jù)庫(kù)應(yīng)用程序的變化。如果數(shù)據(jù)的語(yǔ)義被修改了,任何上述技術(shù)是注定要失敗((例如: ORM(對(duì)象映射關(guān)系)一旦看到了對(duì)象的變化,就需要重新啟動(dòng)所有的節(jié)點(diǎn))。關(guān)于微服務(wù):功能型-層架構(gòu)給高可用性和維護(hù)帶來(lái)了一個(gè)新的局面。即使銀行報(bào)表微服務(wù)奔潰了也不會(huì)影響銀行系統(tǒng)其他的功能。你將會(huì)為90%的消費(fèi)者不用銀行報(bào)表功能感到慶幸。
四、 微服務(wù)需要進(jìn)一步發(fā)掘
好吧,任何關(guān)于自動(dòng)伸縮的系統(tǒng)都需要被挖掘。
1.在微服務(wù)中有10個(gè)節(jié)點(diǎn)是購(gòu)物的,兩個(gè)節(jié)點(diǎn)是預(yù)定的;
2.由于假日季節(jié),流入流量比較高;
3.你期望通過(guò)人工分拆購(gòu)物實(shí)例得到什么?
4.假設(shè)分拆出了多個(gè)實(shí)例,那負(fù)載平衡器又是怎么實(shí)現(xiàn)負(fù)責(zé)均衡的呢?
傳統(tǒng)的負(fù)載均衡器在靜態(tài)環(huán)境中能夠運(yùn)行良好,但是當(dāng)動(dòng)態(tài)增加節(jié)點(diǎn)或執(zhí)行腳本添加新實(shí)例的就很糟糕了。如果微服務(wù)能夠?qū)崿F(xiàn)縮放,微服務(wù)項(xiàng)目就需要被挖掘、注冊(cè)、添加實(shí)現(xiàn)負(fù)載均衡;對(duì),大部分的軟件問(wèn)題,通過(guò)引用間接層來(lái)解決。每個(gè)微服務(wù)在關(guān)閉或啟動(dòng)時(shí)都需要自我注冊(cè)。這就需要一個(gè)注冊(cè)管理員-負(fù)載均衡器,對(duì)微服務(wù)的加載很敏感。如何檢查呢,
Netflix解決了這個(gè)問(wèn)題, Netflix在開(kāi)源Eureka AWS上實(shí)現(xiàn)了負(fù)載均衡。
五、 微服務(wù)是否支持多元化編程語(yǔ)言?
顧名思義微服務(wù)是以協(xié)議驅(qū)動(dòng)的服務(wù),這些服務(wù)是基于HTTP/REST( XML/ JSON數(shù)據(jù)傳輸)的。微服務(wù)與輕量級(jí)協(xié)議之間的清晰的定義邊界,有助于建立一個(gè)多元化的編程團(tuán)隊(duì),因?yàn)樗麄兊慕裹c(diǎn)是功能而不在于選擇語(yǔ)言。
六、 微服務(wù)和容器是天作之合?
虛擬機(jī)的笨重和現(xiàn)代應(yīng)?程序的性質(zhì),將他們分拆和拆卸為微服務(wù),使微服務(wù)成為容器的理想搭配。這是真正意義上的DevOps,打的包不僅僅是微服務(wù)的容器也是整體的一個(gè)執(zhí)行環(huán)境。缺點(diǎn)是,應(yīng)用團(tuán)隊(duì)將成為基礎(chǔ)設(shè)施團(tuán)隊(duì),需要對(duì)集裝箱有個(gè)很好的理解。
七、 微服務(wù)添加額外的復(fù)雜性?
1.Jenkins簡(jiǎn)單通道把兩個(gè)應(yīng)用部署到2個(gè)Tomcats里,以此類推,將膨脹出無(wú)數(shù)個(gè)微服務(wù);
2.隨著部署的數(shù)量增加,部署的時(shí)間也跟著顯著上升;
3.需要有一個(gè)良好的容器管理,部署和分發(fā)工具和技術(shù);
4.每個(gè)微服務(wù)將擁有更多的日志文件,如果沒(méi)有stash、 splunk這種合適的工具,對(duì)接調(diào)試事務(wù)將成為一場(chǎng)噩夢(mèng);
5.如果每個(gè)Tomcat有10個(gè)連接,你會(huì)發(fā)現(xiàn)數(shù)百個(gè)來(lái)自不同微服務(wù)數(shù)據(jù)庫(kù)連接,因?yàn)椴荒芄蚕頂?shù)據(jù)庫(kù)連接(沒(méi)有連接數(shù)據(jù)庫(kù)的微服務(wù));
總結(jié)
所有的事情都是有代價(jià)的,微服務(wù)也是一樣,并不是所有的應(yīng)用都有同樣的架構(gòu),也不是所有應(yīng)用對(duì)高可用性、可擴(kuò)展性、可維修性都有著同樣的要求。
非常好我支持^.^
(0) 0%
不好我反對(duì)
(0) 0%
下載地址
關(guān)于微服務(wù)的一些問(wèn)題的解答下載
相關(guān)電子資料下載
- Spring Cloud :打造可擴(kuò)展的微服務(wù)網(wǎng)關(guān) 60
- SpringCloud微服務(wù)架構(gòu):實(shí)現(xiàn)分布式系統(tǒng)的無(wú)縫協(xié)作 62
- 類隔離的使用場(chǎng)景 106
- 微服務(wù)架構(gòu)組件分析,看這篇就夠了 285
- 邊緣計(jì)算微服務(wù)操作系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn) 193
- 【Spring Cloud 】基于微服務(wù)架構(gòu)的智慧工地監(jiān)管平臺(tái)源碼帶APP 150
- 聊聊這個(gè)有趣的話題:分布式單體 106
- Java版智慧工地云平臺(tái)源碼(微服務(wù)+Java+Springboot+Vue+MySQL),支持私有化部署, 369
- Service Mesh:探索分布式系統(tǒng)的幻覺(jué)與未來(lái) 141
- 微服務(wù)的4種部署策略,你都清楚嗎? 298