隨著技術(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ù)的最佳伴侶～