隨著技術(shù)的發(fā)展,我們?cè)仆泄軙r(shí)代逐步的向云原生演進(jìn)了。所謂云原生,就是將微服務(wù)、DevOps的架構(gòu)理念與云所提供的容器、Serverless無(wú)服務(wù)器更好的結(jié)合,提升資源的使用效率,提高研發(fā)運(yùn)維效率。那么在云原生時(shí)代,微服務(wù)應(yīng)該如何與云原生相輔相成呢?
我們來(lái)看看微服務(wù)的定義,即將一個(gè)單體應(yīng)用拆分成多個(gè)微服務(wù),由微服務(wù)來(lái)一起協(xié)同對(duì)外提供服務(wù)支持。在微服務(wù)的運(yùn)行中就存在這三個(gè)問(wèn)題:
1、如何管理微服務(wù)的生命周期;
2、如何治理不同技術(shù)棧微服務(wù)之間的通信;
3、如何處理不同技術(shù)棧的微服務(wù)請(qǐng)求?
對(duì)于如何管理微服務(wù)的生命周期,我們來(lái)一起看看。最初服務(wù)都是單體式的,上線時(shí)直接部署某些機(jī)器資源上就可以了,當(dāng)出現(xiàn)異常時(shí),直接下線該機(jī)器上的服務(wù)版本,服務(wù)與資源的關(guān)系是比較簡(jiǎn)單的,沒(méi)有動(dòng)態(tài)的依賴關(guān)系。當(dāng)我們把服務(wù)拆分成微服務(wù)之后,不同的微服務(wù)部署在不同的機(jī)器上,最后組成整個(gè)應(yīng)用呈現(xiàn)給到用戶,此時(shí)服務(wù)與資源的關(guān)系變得復(fù)雜起來(lái)了。如果應(yīng)用是由不同的技術(shù)棧開(kāi)發(fā)實(shí)現(xiàn),比如有的微服務(wù)用C++、有的用Java、有的用PHP、有的用Golang,那么部署每個(gè)服務(wù)時(shí)還需要在機(jī)器上安裝對(duì)應(yīng)的運(yùn)行環(huán)境,整個(gè)應(yīng)用的運(yùn)維成本又增加了。
但是在云原生時(shí)代,有了容器如Docker、容器平臺(tái)技術(shù)如Kubernetes把這一切都變得簡(jiǎn)單了。Docker容器技術(shù)通過(guò)標(biāo)準(zhǔn)的封裝、標(biāo)準(zhǔn)的運(yùn)行時(shí)將微服務(wù)的部署變得標(biāo)準(zhǔn)化,Kubernetes技術(shù)則是把已經(jīng)標(biāo)準(zhǔn)化的微服務(wù)便捷的運(yùn)行在機(jī)器上,運(yùn)維人員不再需要將微服務(wù)分配到某個(gè)具體的機(jī)器上,并且在Kubernetes中的Pod模型對(duì)外提供了單個(gè)容器運(yùn)行狀態(tài)接口、DNS地址服務(wù),通過(guò)簡(jiǎn)單的二次開(kāi)發(fā)可以看到每個(gè)微服務(wù)在哪些地址上的運(yùn)行狀態(tài),簡(jiǎn)化了整個(gè)微服務(wù)生命周期的管理。
對(duì)于如何治理不同技術(shù)棧微服務(wù)之間的通信,我們一起來(lái)看看,最初服務(wù)是單體式的,模塊與模塊之間的通信都是靜態(tài)編譯產(chǎn)生的,比較簡(jiǎn)單。當(dāng)我們把服務(wù)拆分成微服務(wù)之后,模塊與模塊之間的通信就是動(dòng)態(tài)關(guān)聯(lián)的了,微服務(wù)如何找到另外一個(gè)微服務(wù)變得復(fù)雜起來(lái)。一些微服務(wù)框架,如Java的Spring簡(jiǎn)化了開(kāi)發(fā)人員的負(fù)擔(dān),只要是Java系服務(wù)的開(kāi)發(fā)就不用再寫一遍微服務(wù)之間通信的邏輯。
但是當(dāng)一個(gè)業(yè)務(wù)引入多個(gè)技術(shù)棧時(shí),常見(jiàn)的如上層用Java編寫,底層用Golang編寫,不同微服務(wù)之間的通信框架都不一樣,無(wú)疑又增加了開(kāi)發(fā)人員的成本。但是在云原生時(shí)代,我們有了ServiceMesh服務(wù)網(wǎng)格,通過(guò)通信劫持,實(shí)現(xiàn)了比較好的服務(wù)間通信監(jiān)測(cè)與管理。在servicemesh中,有一個(gè)sidecar邊車容器的概念,它把微服務(wù)之間通信的能力從業(yè)務(wù)中抽象,單獨(dú)成一個(gè)容器與微服務(wù)并行,再使用Istio所提供的管控能力,將微服務(wù)與邊車容器搭成一個(gè)網(wǎng)狀的數(shù)據(jù)平面,在這上面進(jìn)行服務(wù)之間通信的配置、管理、監(jiān)測(cè)。
對(duì)于如何處理不同技術(shù)棧的微服務(wù)請(qǐng)求,我們一起來(lái)看看,原來(lái)的外部請(qǐng)求通過(guò)瀏覽器或app進(jìn)來(lái)之后,會(huì)經(jīng)過(guò)應(yīng)用層/網(wǎng)絡(luò)層的負(fù)載均衡決定分發(fā)給到哪臺(tái)機(jī)器去處理,單體式應(yīng)用因?yàn)槭且粋€(gè)大整體,直接分發(fā)即可,還是比較簡(jiǎn)單的,而微服務(wù)則需要經(jīng)過(guò)復(fù)雜的邏輯判斷給到哪個(gè)服務(wù)、哪臺(tái)機(jī)器。在多技術(shù)棧開(kāi)發(fā)的情況下,每個(gè)微服務(wù)框架都需要寫一遍請(qǐng)求邏輯。但是在云原生時(shí)代,我們有了Serverless無(wú)服務(wù)器的概念,我們可以把請(qǐng)求類型、請(qǐng)求管理、請(qǐng)求處理的邏輯全抽出來(lái)標(biāo)準(zhǔn)化,在業(yè)務(wù)層只需要前端去調(diào)用該函數(shù)即可,后面的請(qǐng)求處理分發(fā)就再也不用管理了。
微服務(wù)的出現(xiàn),確實(shí)推動(dòng)技術(shù)向前演進(jìn)了一大步,但是微服務(wù)并不是萬(wàn)能的,在使用它的同時(shí),必然要承擔(dān)它的復(fù)雜性所帶來(lái)的成本。不過(guò)微服務(wù)確實(shí)是良藥,有了云原生技術(shù)出現(xiàn)后,對(duì)于該良藥所帶來(lái)的副作用便能消解很多,云原生必定是企業(yè)落地微服務(wù)的優(yōu)秀伴侶~
責(zé)編AJX
-
云計(jì)算
+關(guān)注
關(guān)注
39文章
7845瀏覽量
137612 -
容器
+關(guān)注
關(guān)注
0文章
498瀏覽量
22086 -
微服務(wù)
+關(guān)注
關(guān)注
0文章
139瀏覽量
7371
發(fā)布評(píng)論請(qǐng)先 登錄
相關(guān)推薦
評(píng)論