云原生如何助力微服務？

隨著技術的發(fā)展，我們云托管時代逐步的向云原生演進了。所謂云原生，就是將微服務、DevOps的架構理念與云所提供的容器、Serverless無服務器更好的結合，提升資源的使用效率，提高研發(fā)運維效率。那么在云原生時代，微服務應該如何與云原生相輔相成呢？

我們來看看微服務的定義，即將一個單體應用拆分成多個微服務，由微服務來一起協(xié)同對外提供服務支持。在微服務的運行中就存在這三個問題：

1、如何管理微服務的生命周期；

2、如何治理不同技術棧微服務之間的通信；

3、如何處理不同技術棧的微服務請求？

對于如何管理微服務的生命周期，我們來一起看看。最初服務都是單體式的，上線時直接部署某些機器資源上就可以了，當出現異常時，直接下線該機器上的服務版本，服務與資源的關系是比較簡單的，沒有動態(tài)的依賴關系。當我們把服務拆分成微服務之后，不同的微服務部署在不同的機器上，最后組成整個應用呈現給到用戶，此時服務與資源的關系變得復雜起來了。如果應用是由不同的技術棧開發(fā)實現，比如有的微服務用C++、有的用Java、有的用PHP、有的用Golang，那么部署每個服務時還需要在機器上安裝對應的運行環(huán)境，整個應用的運維成本又增加了。但是在云原生時代，有了容器如Docker、容器平臺技術如Kubernetes把這一切都變得簡單了。Docker容器技術通過標準的封裝、標準的運行時將微服務的部署變得標準化，Kubernetes技術則是把已經標準化的微服務便捷的運行在機器上，運維人員不再需要將微服務分配到某個具體的機器上，并且在Kubernetes中的Pod模型對外提供了單個容器運行狀態(tài)接口、DNS地址服務，通過簡單的二次開發(fā)可以看到每個微服務在哪些地址上的運行狀態(tài)，簡化了整個微服務生命周期的管理。

對于如何治理不同技術棧微服務之間的通信，我們一起來看看，最初服務是單體式的，模塊與模塊之間的通信都是靜態(tài)編譯產生的，比較簡單。當我們把服務拆分成微服務之后，模塊與模塊之間的通信就是動態(tài)關聯的了，微服務如何找到另外一個微服務變得復雜起來。一些微服務框架，如Java的Spring簡化了開發(fā)人員的負擔，只要是Java系服務的開發(fā)就不用再寫一遍微服務之間通信的邏輯。但是當一個業(yè)務引入多個技術棧時，常見的如上層用Java編寫，底層用Golang編寫，不同微服務之間的通信框架都不一樣，無疑又增加了開發(fā)人員的成本。但是在云原生時代，我們有了ServiceMesh服務網格，通過通信劫持，實現了比較好的服務間通信監(jiān)測與管理。在servicemesh中，有一個sidecar邊車容器的概念，它把微服務之間通信的能力從業(yè)務中抽象，單獨成一個容器與微服務并行，再使用Istio所提供的管控能力，將微服務與邊車容器搭成一個網狀的數據平面，在這上面進行服務之間通信的配置、管理、監(jiān)測。

對于如何處理不同技術棧的微服務請求，我們一起來看看，原來的外部請求通過瀏覽器或app進來之后，會經過應用層/網絡層的負載均衡決定分發(fā)給到哪臺機器去處理，單體式應用因為是一個大整體，直接分發(fā)即可，還是比較簡單的，而微服務則需要經過復雜的邏輯判斷給到哪個服務、哪臺機器。在多技術棧開發(fā)的情況下，每個微服務框架都需要寫一遍請求邏輯。但是在云原生時代，我們有了Serverless無服務器的概念，我們可以把請求類型、請求管理、請求處理的邏輯全抽出來標準化，在業(yè)務層只需要前端去調用該函數即可，后面的請求處理分發(fā)就再也不用管理了。

微服務的出現，確實推動技術向前演進了一大步，但是微服務并不是萬能的，在使用它的同時，必然要承擔它的復雜性所帶來的成本。不過微服務確實是良藥，有了云原生技術出現后，對于該良藥所帶來的副作用便能消解很多，云原生必定是企業(yè)落地微服務的最佳伴侶～