[[339605]]

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

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

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

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

 

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

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

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

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

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

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

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

生命周期的管理。

流量治理。

編程模型。

可信安全。

生命周期

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

 

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

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

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

 

我認為分為兩個部分：

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

基于這個技術(shù)，后來我們又開發(fā)出另一層：容器平臺，也是今天比較流行的，像 Kubernetes 。它的作用是幫助把已經(jīng)標準化的微服務(wù)最便捷地運行到底層資源上面。我們講到的存儲、計算、網(wǎng)絡(luò)都通過 Kubernetes 這層進行了統(tǒng)一抽象和封裝，讓已經(jīng)被容器統(tǒng)一的微服務(wù)能夠直接運行到 Kubernetes 平臺。因此，運維人員不用再苦惱如何去把某個微服務(wù)分配到具體的某一個資源或計算單元上去。通過容器和容器平臺，大大簡化了微服務(wù)本身的生命周期管理，簡化了微服務(wù)自身的運維管理問題，也促進了微服務(wù)更多地被企業(yè)所采用。

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

 

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

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

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

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

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

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

 

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

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

流量治理

 

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

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

 

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

 

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

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

 

假設(shè)在公司之中，除了 Spring Cloud 之外，我們?nèi)ヒ肓硗庖恍┓?wù)框架，如阿里巴巴 HSF 如果希望和 Spring Cloud 框架上面編寫的微服務(wù)進行通訊的話應(yīng)該如何去操作?這就要求 HSF 與 Spring Cloud 之間互聯(lián)互通以及協(xié)議之間的互相理解。但其實這些框架之間往往并不具備這個能力。更大的一個問題可能在于，云原生時代我們允許這些微服務(wù)的研發(fā)能用不同開發(fā)語言及模型來進行編程。因此，框架之間的系統(tǒng)并不是不是一對二的關(guān)系，也不是 僅僅是 Spring Cloud 與 HSF 的關(guān)系，可能是 Java 體系與 JavaScript、Python、Go 體系這些微服務(wù)框架都需要打通的問題，它變成了一個 N to M 的 problem，來解決多語言、復(fù)雜環(huán)境中微服務(wù)的治理與管理問題。

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

 

現(xiàn)在有一個比較流行的概念叫 Service Mesh——服務(wù)網(wǎng)格。它的本質(zhì)就是為了更好地解決流量治理在多語言、多環(huán)境場景下的問題，它的主要思想如下：

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

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

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

編程模型

請求驅(qū)動

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

 

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

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

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

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

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

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

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

 

請求的標準化

請求的路由

請求的處理

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

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

分布式運行時

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

 

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

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

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

Dapr

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

 

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

 

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

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

可信安全

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

 

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

 

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

 

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

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

 

但這個體系還是比較難構(gòu)建的，相當于要在不完全受信的網(wǎng)絡(luò)中，需要有一個可以信任的平臺層或中間層，也就類似 PKI 中的 CA 機制。在 HTTPs 上，比如說我們要信任一個 CA，可能需要提前講證書預(yù)置在操作系統(tǒng)中，從安裝時就要預(yù)置好，才能提供一個更為安全的端到端的可信，否則是無法構(gòu)建好這個信任鏈的。同樣的，在云環(huán)境中也需要這個機制。云本身是一個可控平臺，通過從云最底層的硬件機制，到云上運行的 OS 上，再到最終向上部署微服務(wù)的平臺層，我們都要建立起來了一個可證的授信鏈，最終給每一個微服務(wù)提供自身的身份 ID 以及授權(quán)可證的授權(quán)信息，這樣微服務(wù)才能提供統(tǒng)一可驗證、可證實的身份。也就是說在云原生時代，通過平臺思維能夠給微服務(wù)安全提供更大的價值。

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

 

三 EDAS

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

 

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

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

四 云原生微服務(wù)

在云原生時代，微服務(wù)的特點：

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

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

微服務(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ù)框架活躍度報告

 

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

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

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

最后像 Dubbo，還有阿里正投資很多人力去共建的 Dapr 項目其實也比較活躍。