云原生時(shí)代的微服務(wù)又有什么特點(diǎn)?當(dāng)前有哪些比較活躍的微服務(wù)項(xiàng)目?阿里巴巴資深技術(shù)專家李響從微服務(wù)的生命周期、流量治理、編程模型以及可信安全4個(gè)方面，分享他對(duì)微服務(wù)與云原生之間的關(guān)系的理解。

云原生時(shí)代，微服務(wù)和云原生會(huì)產(chǎn)生怎樣的關(guān)系?云原生時(shí)代的微服務(wù)又有什么特點(diǎn)?當(dāng)前有哪些比較活躍的微服務(wù)項(xiàng)目?阿里巴巴資深技術(shù)專家李響從微服務(wù)的生命周期、流量治理、編程模型以及可信安全4個(gè)方面，分享他對(duì)微服務(wù)與云原生之間的關(guān)系的理解。

一 微服務(wù)架構(gòu)與云原生

微服務(wù)從 2010 年左右開始興起。最開始大家會(huì)把微服務(wù)架構(gòu)應(yīng)用在傳統(tǒng) IT 的基礎(chǔ)設(shè)施，也就是傳統(tǒng)的 IDC 或者說物理機(jī)上，我們使用這些物理機(jī)為我們的微服務(wù)架構(gòu)提供資源，形成一個(gè)分布式的系統(tǒng)，互相協(xié)作、協(xié)同。

隨著我們整個(gè)的 IT 基礎(chǔ)設(shè)施的發(fā)展，逐步到了云的時(shí)代。

我們?cè)谠茣r(shí)代做的第一步是云托管，也就是把在傳統(tǒng) IDC 之中的物理機(jī)，換成云上的虛擬機(jī)以及云上虛擬的彈性資源，對(duì)于微服務(wù)架構(gòu)其實(shí)改動(dòng)并不是非常巨大。我們把原來部署在物理機(jī)上的架構(gòu)模型，可以比較容易地轉(zhuǎn)到在云上托管的虛擬機(jī)中，也稱之為 Lift and Shift 方式。與此同時(shí)，在云托管時(shí)代，我們也嘗試更好利用云上虛擬機(jī)的彈性能力，去做一些微服務(wù)的自動(dòng)化水平擴(kuò)縮容。

隨著技術(shù)進(jìn)一步發(fā)展，到云原生時(shí)代，到底什么不同了?云原生希望能夠把像微服務(wù)、DevOps 這些架構(gòu)和理念，能夠和云所提供的服務(wù)、能力、平臺(tái)更好地進(jìn)行融合、進(jìn)行協(xié)同和協(xié)作。我們希望云不光光是提供彈性物理資源，比如說存儲(chǔ)、計(jì)算、網(wǎng)絡(luò)等資源，而是能夠?yàn)槲⒎?wù)提供更好的一個(gè)運(yùn)行環(huán)境和平臺(tái)。

這個(gè)需要我們做到以下兩點(diǎn)：

對(duì)資源層面聯(lián)合優(yōu)化，對(duì)資源的更優(yōu)使用。

對(duì)云服務(wù)與平臺(tái)的充分利用，研發(fā)、運(yùn)維效率的極大提升。

這個(gè)其實(shí)是云原生想去做的事情，就是讓我們的微服務(wù)架構(gòu)和體系，能夠和云與云上面的服務(wù)、平臺(tái)，以最佳的方式工作、協(xié)同在一起，降本提效。

二 微服務(wù)與云原生

如果我們以微服務(wù)為中心去看待微服務(wù)與云原生，可以從四個(gè)點(diǎn)講一講它們之間的關(guān)系，以及微服務(wù)在云原生時(shí)代的演進(jìn)。

生命周期的管理。

流量治理。

編程模型。

可信安全。

生命周期

從本質(zhì)上來講，微服務(wù)就是把單體應(yīng)用從一個(gè)巨型的應(yīng)用拆分成數(shù)個(gè)更微小的服務(wù)，協(xié)作完成原來單體應(yīng)用所提供的等效業(yè)務(wù)服務(wù)。因此，服務(wù)與服務(wù)之間會(huì)有依賴關(guān)系，服務(wù)也需要去部署到一個(gè)或多個(gè)資源上。

原來的單體應(yīng)用與資源之間的關(guān)系其實(shí)是一對(duì)一的關(guān)系，單體應(yīng)用的協(xié)同也都是一些內(nèi)部協(xié)同，不存在外部動(dòng)態(tài)的依賴。而當(dāng)我們轉(zhuǎn)換到微服務(wù)之后，可以看到這張圖會(huì)變成網(wǎng)狀，變得復(fù)雜起來。

因此由于內(nèi)在原因，超過 50% 的企業(yè)會(huì)認(rèn)為微服務(wù)架構(gòu)或采用微服務(wù)架構(gòu)，其中最大的挑戰(zhàn)在于更為復(fù)雜的運(yùn)維，也就是更為復(fù)雜的生命周期管理。

我們?cè)诮裉熘v云原生的根基——容器與容器服務(wù)，就在于幫助微服務(wù)解決生命周期管理以及運(yùn)維管理難題，那是怎么解決的呢?

我認(rèn)為分為兩個(gè)部分：

第一部分，不同微服務(wù)之間可能存在一些異構(gòu)，為了讓每一個(gè)團(tuán)隊(duì)在微服務(wù)體系下發(fā)揮最大效能，我們?cè)试S不同團(tuán)隊(duì)采用不同的編程語言，甚至不同的運(yùn)行環(huán)境來去運(yùn)行這些微服務(wù)。因此，我們?cè)谶\(yùn)維和管理微服務(wù)時(shí)，最初其實(shí)并沒有一套統(tǒng)一的標(biāo)準(zhǔn)去處理的異構(gòu)環(huán)境，這也是為什么后來容器這項(xiàng)云原生技術(shù)變得流行起來，它的一個(gè)重要作用就是通過一層標(biāo)準(zhǔn)的封裝以及標(biāo)準(zhǔn)的運(yùn)行時(shí)，來標(biāo)準(zhǔn)化微服務(wù)部署。這樣從生命周期管理的角度來看，每一個(gè)微服務(wù)之間的差異就會(huì)變少，共同點(diǎn)變多。

基于這個(gè)技術(shù)，后來我們又開發(fā)出另一層：容器平臺(tái)，也是今天比較流行的，像 Kubernetes 。

它的作用是幫助把已經(jīng)標(biāo)準(zhǔn)化的微服務(wù)最便捷地運(yùn)行到底層資源上面。我們講到的存儲(chǔ)、計(jì)算、網(wǎng)絡(luò)都通過 Kubernetes 這層進(jìn)行了統(tǒng)一抽象和封裝，讓已經(jīng)被容器統(tǒng)一的微服務(wù)能夠直接運(yùn)行到 Kubernetes 平臺(tái)。因此，運(yùn)維人員不用再苦惱如何去把某個(gè)微服務(wù)分配到具體的某一個(gè)資源或計(jì)算單元上去。通過容器和容器平臺(tái)，大大簡(jiǎn)化了微服務(wù)本身的生命周期管理，簡(jiǎn)化了微服務(wù)自身的運(yùn)維管理問題，也促進(jìn)了微服務(wù)更多地被企業(yè)所采用。

如果更微觀地去看，容器和容器平臺(tái)具體給微服務(wù)的生命周期還提供了哪些幫助呢?

例如 Kubernetes 引入了一個(gè)非常有意思的概念，叫做 pod，一個(gè) pod 實(shí)際上是一組容器的集合，在一個(gè) pod 中可以運(yùn)行一個(gè)或多個(gè)容器。一般來講，當(dāng)我們采用微服務(wù)架構(gòu)時(shí)，會(huì)把微服務(wù)的主體運(yùn)行在主容器中，主容器的生命周期跟 pod 自身的生命周期是一個(gè)耦合的狀態(tài)。

除此之外，我們還會(huì)運(yùn)行一些邊車容器或者叫 Sidecar 容器，為主容器提供一些輔助功能，比如說日志采集、網(wǎng)絡(luò)代理、身份鑒權(quán)等。我們都可以把它放 Sidecar 容器中，這樣微服務(wù)具備了 Super power，一種超能力。它除了自身提供的核心業(yè)務(wù)服務(wù)以外，我們還可以裝上盔甲，也就是動(dòng)態(tài)添加一些額外的輔助能力，讓微服務(wù)管理變得更強(qiáng)健更強(qiáng)壯。

另一方面，其實(shí) pod 這個(gè)模型還提供了一些非常有用的功能：

狀態(tài)信息。Pod 會(huì)提供一個(gè)標(biāo)準(zhǔn)接口顯示運(yùn)行狀態(tài)。例如，是否已經(jīng)準(zhǔn)備好接收流量，如果準(zhǔn)備好接收流量，那么從 ingress 流量就可以打到微服務(wù)上。如果運(yùn)行狀態(tài)不良，我們可以嘗試對(duì)這個(gè)容器進(jìn)行修理、重啟或刪除，甚至是換到另一個(gè)計(jì)算單元上去運(yùn)行，為微服務(wù)整體的穩(wěn)定性提供了保障。

地址服務(wù)。每一個(gè) pod 都有一個(gè)標(biāo)準(zhǔn)化的 DNS 地址服務(wù)，可以被統(tǒng)一的尋址。這樣對(duì)于需要統(tǒng)一暴露出來 API 的日志、監(jiān)控、追蹤能力都有著非常大的幫助，可以根據(jù)這個(gè) DNS 的地址來訪問 pod 所暴露的可觀測(cè)性信息，便捷及時(shí)的發(fā)現(xiàn)運(yùn)行時(shí)問題。

所以我們可以看到容器平臺(tái)及容器其實(shí)在微觀上也幫助了微服務(wù)具有更多能力、具有更強(qiáng)的健壯性以及具有更好的可觀測(cè)性。

在這，如上圖所示，在微服務(wù)運(yùn)行時(shí)這一方面，容器平臺(tái)也提供了非常有效的能力幫助我們做 Day 2 的微服務(wù)更新、發(fā)布、擴(kuò)容等操作。比如 Kubernetes 提供了幾種比較典型的升級(jí)或是擴(kuò)容策略：Rolling deployment、Blue-green release 等等，這些都有效簡(jiǎn)化了我們的運(yùn)維工作，提高了運(yùn)維本身的確定性和自動(dòng)化效率。

總而言之，在生命周期這一方面，通過使用容器及容器平臺(tái)技術(shù)，大大提高了我們對(duì)于容器生命周期管控的標(biāo)準(zhǔn)化及自動(dòng)化程度，節(jié)約了人力成本，提升了效率，讓更多的企業(yè)愿意使用微服務(wù)這種技術(shù)。

流量治理

微服務(wù)一方面是把原來在靜態(tài)編譯時(shí)產(chǎn)生的能力與能力之間的關(guān)聯(lián)關(guān)系，通過架構(gòu)拆分推演到動(dòng)態(tài)的運(yùn)行時(shí)。因此在運(yùn)行時(shí)，服務(wù)與服務(wù)之間是需要進(jìn)行通訊、協(xié)同，才能完成某一項(xiàng)具體的業(yè)務(wù)功能。當(dāng)大家進(jìn)行通訊、協(xié)同時(shí)，就一定要對(duì)其通訊過程進(jìn)行管理，或者說要進(jìn)行流量管理。例如，我們要知道怎樣從一個(gè)微服務(wù)找到另一個(gè)微服務(wù)，以及怎樣能保證一個(gè)微服務(wù)找到最佳的微服務(wù)實(shí)例跟它進(jìn)行通訊，這是一個(gè)比較復(fù)雜的過程，其中包括 RPC 能力、服務(wù)注冊(cè)發(fā)現(xiàn)能力、動(dòng)態(tài)配置管理能力以及服務(wù)降級(jí)能力等等。

為了減輕業(yè)務(wù)開發(fā)同學(xué)的負(fù)擔(dān)，不用重復(fù)的在每一個(gè)微服務(wù)中寫一遍微服務(wù)的流量管理的通用能力，因此大家開發(fā)了很多框架，比如在 Java 體系中，著名的 Spring Cloud 提供了一個(gè)分布式微服務(wù)管理框架;在 Go 語言的開源生態(tài)中也有像 Go Mirco 這樣的體系;在阿里巴巴內(nèi)部我們也有像 HSF 這樣的體系發(fā)展起來的微服務(wù)治理框架。

因此，從抽象層面可以看到一個(gè)服務(wù)包含了兩個(gè)層面：

一個(gè)層面是本身的業(yè)務(wù)邏輯，也就是由微服務(wù)業(yè)務(wù)開發(fā)人員去編寫的，功能實(shí)現(xiàn)與業(yè)務(wù)實(shí)現(xiàn)相關(guān)的代碼。

另一個(gè)層面是為了實(shí)現(xiàn)微服務(wù)與微服務(wù)之間通訊、流量、服務(wù)治理的代碼，我們會(huì)將其抽象成一個(gè)框架，如下圖中標(biāo)出的 Spring Cloud。這樣的抽象帶來了一個(gè)問題，就是所有的通用能力都依賴于這個(gè)具體的框架。

假設(shè)在公司之中，除了 Spring Cloud 之外，我們?nèi)ヒ肓硗庖恍┓?wù)框架，如阿里巴巴 HSF 如果希望和 Spring Cloud 框架上面編寫的微服務(wù)進(jìn)行通訊的話應(yīng)該如何去操作?這就要求 HSF 與 Spring Cloud 之間互聯(lián)互通以及協(xié)議之間的互相理解。但其實(shí)這些框架之間往往并不具備這個(gè)能力。更大的一個(gè)問題可能在于，云原生時(shí)代我們?cè)试S這些微服務(wù)的研發(fā)能用不同開發(fā)語言及模型來進(jìn)行編程。

因此，框架之間的系統(tǒng)并不是不是一對(duì)二的關(guān)系，也不是 僅僅是 Spring Cloud 與 HSF 的關(guān)系，可能是 Java 體系與 JavaScript、Python、Go 體系這些微服務(wù)框架都需要打通的問題，它變成了一個(gè) N to M 的 problem，來解決多語言、復(fù)雜環(huán)境中微服務(wù)的治理與管理問題。

這時(shí)，當(dāng)我們有了容器、容器平臺(tái)、Pod 這些抽象，能夠提供一個(gè)平臺(tái)，而不是必須要完全依賴于業(yè)務(wù)中的代碼或 框架時(shí)，有沒有更好的辦法來解決剛才提到的問題?

現(xiàn)在有一個(gè)比較流行的概念叫 Service Mesh——服務(wù)網(wǎng)格。

它的本質(zhì)就是為了更好地解決流量治理在多語言、多環(huán)境場(chǎng)景下的問題，它的主要思想如下：

第一就是希望把流量管理的這些框架能力從耦合在業(yè)務(wù)的二進(jìn)制中抽象、剝離出來，形成一個(gè)流量管理的單獨(dú)進(jìn)程，并以 Sidecar 的模式部署在 Pod 中。通過操作系統(tǒng)級(jí)別的透明流量劫持工作，把所有的微服務(wù)之間的流量劫持到 Sidecar 中，然后通過 Sidecar 與 Sidecar 之間通訊進(jìn)行流量的轉(zhuǎn)發(fā)與管理。這樣問題就簡(jiǎn)單多了，我們只需要讓流量管理的 Sidecar 之間互相通訊、能夠進(jìn)行互聯(lián)互通。目前比較知名、流行的開源流量劫持和管理 Sidecar 實(shí)現(xiàn)叫做 Envoy。

當(dāng)然，單單有了這層流量劫持與管理還是不夠的，還需要管控平面的支持。比如原來微服務(wù)體系做的服務(wù)注冊(cè)、服務(wù)發(fā)現(xiàn)以及流量觀測(cè)還是需要的，這些策略和規(guī)則需要下發(fā)給流量管理的 Sidecar 代理。因此，我們還需要構(gòu)建一個(gè)管控平面來管理在 Pod 中部署的流量管理的數(shù)據(jù)平面的單點(diǎn)，讓它們形成一個(gè)網(wǎng)狀，形成一個(gè)集群。所以我們需要有一些管控平面的能力，在開源中比較流行的一個(gè)管控平面實(shí)現(xiàn)叫 Istio。

主要實(shí)現(xiàn)了三個(gè)能力：流量的配置、流量的安全、流量的觀測(cè)。

我們認(rèn)為在云原生這個(gè)逐漸平臺(tái)化的時(shí)代，大部分新的應(yīng)用及場(chǎng)景都會(huì)嘗試選用基于 Service Mesh 的技術(shù)進(jìn)行微服務(wù)的流量治理。

編程模型

請(qǐng)求驅(qū)動(dòng)

請(qǐng)求驅(qū)動(dòng)，也就是支持基于請(qǐng)求的動(dòng)態(tài)彈性伸縮并且簡(jiǎn)化請(qǐng)求處理邏輯。有些同學(xué)可能把這個(gè)模型稱之為 Event-driven，也就是事件驅(qū)動(dòng)，但是請(qǐng)求驅(qū)動(dòng)實(shí)際是事件驅(qū)動(dòng)中的一個(gè)分支。

什么是請(qǐng)求驅(qū)動(dòng)呢?從傳統(tǒng)的微服務(wù)架構(gòu)看，當(dāng)一個(gè)外部系統(tǒng)請(qǐng)求進(jìn)來后，一般都會(huì)經(jīng)過一個(gè) L4/L7 的負(fù)載均衡，然后給到不同的微服務(wù)實(shí)例上面。在同一個(gè)微服務(wù)實(shí)例本身進(jìn)程的內(nèi)部，一般會(huì)有兩塊邏輯，第一塊邏輯是請(qǐng)求管理，它可能是一個(gè) HTTP Server 和一些 Handlers，有一些隊(duì)列管理、請(qǐng)求分發(fā)等能力。這些請(qǐng)求最終會(huì)提交到第二個(gè)邏輯部分，processor 也就是真正的請(qǐng)求業(yè)務(wù)處理邏輯中，真正的處理并且相應(yīng)這些請(qǐng)求。

這個(gè)架構(gòu)會(huì)帶來兩個(gè)問題：

請(qǐng)求管理的邏輯在不同的微服務(wù)框架實(shí)現(xiàn)中都要去寫一遍，比如 Java、Go 或 Python 都要有自己的請(qǐng)求管理邏輯。

請(qǐng)求管理和請(qǐng)求處理形成耦合關(guān)系。因此，在這個(gè)架構(gòu)下不存在一個(gè)全局獨(dú)立的可以感知請(qǐng)求以及進(jìn)行流量管理的控制層。只有到了微服務(wù)實(shí)例自身的處理層，才能解析這個(gè)請(qǐng)求。這時(shí)候即便這個(gè)微服務(wù)實(shí)例已經(jīng)過載，也很難把請(qǐng)求再轉(zhuǎn)發(fā)給其他微服務(wù)實(shí)例進(jìn)行負(fù)載均衡了。

請(qǐng)求驅(qū)動(dòng)系統(tǒng)就是嘗試去解決這兩個(gè)問題，我們嘗試在微服務(wù)中做一個(gè)請(qǐng)求驅(qū)動(dòng)的解耦操作。

首先把外部系統(tǒng)傳輸過來的請(qǐng)求都進(jìn)行一次標(biāo)準(zhǔn)化，我們有一個(gè)適配器，進(jìn)行標(biāo)準(zhǔn)化之后，把它放到一個(gè)請(qǐng)求負(fù)載均衡器中，這個(gè)負(fù)載均衡已經(jīng)能理解請(qǐng)求本身的語義，它就能驅(qū)動(dòng)請(qǐng)求處理的邏輯進(jìn)行請(qǐng)求處理。當(dāng)請(qǐng)求處理單元不夠時(shí)，可以通過請(qǐng)求處理的管理器進(jìn)行擴(kuò)容;當(dāng)請(qǐng)求處理的邏輯單元比較多時(shí)，還可以進(jìn)行縮容，這樣就可以節(jié)約成本。另外，開發(fā)人員也不用再去實(shí)現(xiàn)請(qǐng)求管理邏輯，降低了開發(fā)成本。

剛才講的請(qǐng)求驅(qū)動(dòng)模型可以分為三部分：

請(qǐng)求的標(biāo)準(zhǔn)化

請(qǐng)求的路由

請(qǐng)求的處理

其實(shí)，如果把外部系統(tǒng)的請(qǐng)求標(biāo)準(zhǔn)化，加上請(qǐng)求路由、處理管理，而不包含業(yè)務(wù)代碼，就會(huì)組成我們常說 Serverless 概念。這也就是一種把微服務(wù)體系和平臺(tái)化的 Serverless 體系融合的一個(gè)過程。

Serverless 平臺(tái)有阿里云 FaaSS、SAE，AWS 有 Lambda、Google 推出了 CloudRun、Azure 有 Functions。如果大家希望自己能夠構(gòu)建一個(gè) Serverless 平臺(tái)，如請(qǐng)求標(biāo)準(zhǔn)化，也有像 Cloud Events 這樣的開源請(qǐng)求標(biāo)準(zhǔn)， Knative 這樣的處理路由以及處理請(qǐng)求的水平擴(kuò)展能力組件，可以利用 Kafka 或者 RocketMQ 來做請(qǐng)求本身的持久化以及請(qǐng)求本身的轉(zhuǎn)發(fā)。

分布式運(yùn)行時(shí)

在編程模型中的分布式運(yùn)行時(shí)，也就是我們希望微服務(wù)能夠有更好的多語言環(huán)境支持、環(huán)境可移植性并能做到極速啟動(dòng)。

多語言支持、環(huán)境可移植性、極速啟動(dòng)

單體應(yīng)用時(shí)代，我們的業(yè)務(wù)代碼跟中間件代碼耦合在一起，而且是一份部署的實(shí)例;當(dāng)?shù)搅宋⒎?wù)時(shí)代，通過像 Service Mesh 服務(wù)網(wǎng)格進(jìn)行流量管理之后，可以看到我們的業(yè)務(wù)代碼和流量管理代碼實(shí)際上是可分離的，只有部分中間件的代碼仍然和部分業(yè)務(wù)代碼耦合在一起形成一個(gè)二進(jìn)制。

為了能夠做到充分的多語言能力支持、環(huán)境的可移植性，我們希望能夠把剩余的中間件代碼也從業(yè)務(wù)中解耦出來，這項(xiàng)技術(shù)叫做運(yùn)行時(shí)解耦。它的根本理念是通過向業(yè)務(wù)代碼提供一個(gè)標(biāo)準(zhǔn)的可擴(kuò)展 API，并且是一個(gè)多語言可支持、輕量級(jí)的 API，通過調(diào)用 API 來實(shí)現(xiàn)中間件的功能，我們把中間件的能力像流量管理一樣下沉到一個(gè) Sidecar 中，用一種語言進(jìn)行統(tǒng)一實(shí)現(xiàn)，然后設(shè)計(jì)一個(gè)可拔插的模式，讓大家能夠拔插更多中間件的能力。

Dapr

這項(xiàng)技術(shù)比較領(lǐng)先的一個(gè)實(shí)踐是微軟去年推出的一個(gè)分布式運(yùn)行時(shí)，叫做 Dapr。

Dapr 向業(yè)務(wù)的代碼暴露了兩個(gè) API，一個(gè)是 HTTP 的 API，另外一個(gè)是 grpc 的 API。這兩個(gè) API 都非常輕量級(jí)，并能夠跨多種語言，Dapr 本身作為分布式運(yùn)行時(shí)，可以對(duì)接多種中間件系統(tǒng)，向上通過標(biāo)準(zhǔn)的 API 屏蔽不同系統(tǒng)之間的差異性，提供一定的編程界面界面統(tǒng)一。代碼實(shí)現(xiàn)上把中間件的代碼從應(yīng)用級(jí)別抽離到 Sidecar 中，如上圖所示，我們?cè)跇I(yè)務(wù)上面只需要寫業(yè)務(wù)的代碼，其他代碼幾乎都被基于 Dapr 的平臺(tái)所接管。

Dapr 本身分為兩部分：第一部分是 Dapr 向 Application 暴露的 API，另一部分是 Dapr 的框架層。

通過 Dapr 的框架層，我們可以接入各種不同的 Dapr 相關(guān)實(shí)現(xiàn)：Resource bandings 如 Kafka/SQS、管理數(shù)據(jù)的如 Redis/cassandra、或者我們?nèi)プ?Publish & subscribe 如 RabbitMQ、甚至 Distributed Tracing 如 Prometheus/Open tracing 等等，都可以接入到 Dapr 這套框架里，然后通過統(tǒng)一的標(biāo)準(zhǔn) HTTP、gRPC API 提供給業(yè)務(wù)代碼、應(yīng)用代碼去使用，這樣就做到了業(yè)務(wù)代碼與中間件、流量管理能力的更徹底的解耦，應(yīng)用的開發(fā)人員也能夠更專注、更自由地去關(guān)注業(yè)務(wù)代碼研發(fā)。

可信安全

因?yàn)槲⒎?wù)與微服務(wù)之間需要有網(wǎng)絡(luò)通訊，需要有安全可信的認(rèn)證。傳統(tǒng)做法就是把微服務(wù)放到一個(gè)可信網(wǎng)絡(luò)環(huán)境中，假設(shè)網(wǎng)絡(luò)環(huán)境中所有通訊、執(zhí)行的應(yīng)用或微服務(wù)都是受信的，它們可以自由通訊或交流，可能有一些輕量級(jí)的鑒權(quán)與授權(quán)進(jìn)行一定的安全防護(hù)措施。

但這個(gè)模型會(huì)帶來一種風(fēng)險(xiǎn)，當(dāng)有微服務(wù)入侵到這個(gè)可信網(wǎng)絡(luò)之中，它會(huì)對(duì)整個(gè)微服務(wù)體系造成極大的安全隱患，因?yàn)榭尚啪W(wǎng)絡(luò)中的內(nèi)部防范一定程度上是比較欠缺的。

另外，經(jīng)常會(huì)有可信網(wǎng)絡(luò)與可信網(wǎng)絡(luò)之間的微服務(wù)互相調(diào)用或鑒權(quán)的問題，常見解決方法是通過 VPC peering 或者通過 gateway 網(wǎng)絡(luò)的網(wǎng)關(guān)打通。利用一個(gè)可信通道保證微服務(wù)與微服務(wù)之間的網(wǎng)絡(luò)層面可信的調(diào)用。但同樣引出一種問題，比如在另外一個(gè)可信網(wǎng)絡(luò)中被入侵，便可以攻擊到其它相連的可信網(wǎng)絡(luò)，也增大了受攻擊的可能性。

在微服務(wù)時(shí)代，我們思考是否有更好的解決方式，不去假設(shè)網(wǎng)絡(luò)是完全可信的環(huán)境。因此，提出了一個(gè)叫做微服務(wù)或應(yīng)用可信安全。也就是微服務(wù)與微服務(wù)或者機(jī)密文件之間的每一次通訊，都基于身份體系。微服務(wù)會(huì)提供給它所溝通、協(xié)同的目標(biāo)對(duì)象一個(gè)身份認(rèn)證。就好比我們通過瀏覽器訪問 HTTPs 網(wǎng)站，這些網(wǎng)站需要提供證書，我們的微服務(wù)也需要提供一個(gè)自身的身份認(rèn)證，這樣接收方就可以通過平臺(tái)進(jìn)行認(rèn)證且查看授權(quán)。只有這些認(rèn)證都通過，才會(huì)和開始微服務(wù)的通訊。

實(shí)際上，利用平臺(tái)的特點(diǎn)在網(wǎng)絡(luò)層面內(nèi)部以應(yīng)用為中心，又建設(shè)起一套基于統(tǒng)一身份認(rèn)證授權(quán)的體系。

但這個(gè)體系還是比較難構(gòu)建的，相當(dāng)于要在不完全受信的網(wǎng)絡(luò)中，需要有一個(gè)可以信任的平臺(tái)層或中間層，也就類似 PKI 中的 CA 機(jī)制。在 HTTPs 上，比如說我們要信任一個(gè) CA，可能需要提前講證書預(yù)置在操作系統(tǒng)中，從安裝時(shí)就要預(yù)置好，才能提供一個(gè)更為安全的端到端的可信，否則是無法構(gòu)建好這個(gè)信任鏈的。同樣的，在云環(huán)境中也需要這個(gè)機(jī)制。

云本身是一個(gè)可控平臺(tái)，通過從云最底層的硬件機(jī)制，到云上運(yùn)行的 OS 上，再到最終向上部署微服務(wù)的平臺(tái)層，我們都要建立起來了一個(gè)可證的授信鏈，最終給每一個(gè)微服務(wù)提供自身的身份 ID 以及授權(quán)可證的授權(quán)信息，這樣微服務(wù)才能提供統(tǒng)一可驗(yàn)證、可證實(shí)的身份。也就是說在云原生時(shí)代，通過平臺(tái)思維能夠給微服務(wù)安全提供更大的價(jià)值。

另外在平臺(tái)與平臺(tái)之間或網(wǎng)絡(luò)與網(wǎng)絡(luò)之間，也可以通過平臺(tái)級(jí)別的可信授信來建立關(guān)聯(lián)的關(guān)系，讓不同平臺(tái)之間的微服務(wù)也能產(chǎn)生信任關(guān)系。為了打通不同的平臺(tái)，有一個(gè)開源項(xiàng)目叫做 spiffe，它提供了統(tǒng)一的標(biāo)準(zhǔn)身份 ID 以及如何統(tǒng)一標(biāo)準(zhǔn)地進(jìn)行授權(quán)信息的可證和授權(quán)信息的認(rèn)證。

三 EDAS

其實(shí)上面講了那么多，可以發(fā)現(xiàn)在開源開放領(lǐng)域不停地有新的技術(shù)衍生出來，不管是與微服務(wù)流量治理相關(guān)，還是與微服務(wù)生命周期相關(guān)，又或是微服務(wù)的可信安全、編程模型，如果大家自己嘗試去構(gòu)建這種能力或平臺(tái)，一般還是需要花費(fèi)非常大的時(shí)間和精力的。

因此阿里云最近升級(jí)了云上的服務(wù)——EDAS，把 EDAS 從傳統(tǒng)的面向微服務(wù)的管理體系，基于云原生的基礎(chǔ)設(shè)施變成了一個(gè)云原生應(yīng)用 PaaS，提供容器的生命周期管理、微服務(wù)治理、可觀測(cè)性、安全流量治理等能力，讓阿里云用戶能最大化享受到微服務(wù)在云原生時(shí)代的紅利，同時(shí)又不需要花費(fèi)時(shí)間去構(gòu)建這樣的平臺(tái)。

因此推薦對(duì)云原生微服務(wù)感興趣的同學(xué)可以嘗試使用 EDAS。

四 云原生微服務(wù)

在云原生時(shí)代，微服務(wù)的特點(diǎn)：

平臺(tái)化，利用云作為一個(gè)平臺(tái)，如微服務(wù)架構(gòu)進(jìn)行更多的賦能。

標(biāo)準(zhǔn)化，我們希望微服務(wù)本身的部署、運(yùn)維，微服務(wù)之間與其它服務(wù)之間的通訊都能做到標(biāo)準(zhǔn)化，讓服務(wù)與服務(wù)之間的互聯(lián)互通變得更容易，服務(wù)能夠跨到不同的平臺(tái)上，做到一次編寫、一次定義、多處運(yùn)行。

微服務(wù)輕量化，讓研發(fā)人員關(guān)心核心業(yè)務(wù)代碼、業(yè)務(wù)邏輯的研發(fā)，而不是復(fù)雜的微服務(wù)治理相關(guān)的邏輯研發(fā)。

微服務(wù)的產(chǎn)品化。我們希望能構(gòu)建微服務(wù)相關(guān)的產(chǎn)品，以產(chǎn)品化的方式支持大家使用微服務(wù)架構(gòu)，讓它變得更好用、更易用。

五 全球開源微服務(wù)框架活躍度報(bào)告

我們最近花了很大精力收集在云原生時(shí)代比較活躍的一些微服務(wù)項(xiàng)目，然后發(fā)現(xiàn)了幾個(gè)特點(diǎn)：

quarkus 這個(gè)項(xiàng)目非?；钴S，它可以幫助 Java 或 Java 生態(tài)盡量輕量化，適應(yīng)云原生時(shí)代我們對(duì)彈性和高效啟動(dòng)速度的要求。

Spring Cloud 的上升趨勢(shì)還是非常好的，作為 Java 里非常典型的微服務(wù)框架，在阿里巴巴我們也是在 Spring Cloud 生態(tài)中進(jìn)行深耕，現(xiàn)在最流行的一個(gè)Spring Cloud 云服務(wù)提供廠商就是 Spring Cloud Alibaba。

文章來源：50CTO，作者：李響；

【數(shù)商云m.zhimaihui.cn】致力于提供企業(yè)級(jí)的電子商務(wù)平臺(tái)建設(shè)服務(wù)，長(zhǎng)期為大中型企業(yè)打造數(shù)據(jù)化、商業(yè)化、智能化的電子商務(wù)建設(shè)方案，同時(shí)我們還提供B2B電子商務(wù)平臺(tái)、B2B2C多用戶商城系統(tǒng)、B2C電子商務(wù)系統(tǒng)、跨境進(jìn)口電商平臺(tái)、供應(yīng)商管理系統(tǒng)、新零售電商平臺(tái)、直播電商系統(tǒng)等一系列系統(tǒng)定制開發(fā)服務(wù)。