云原生时代，微服务如何演进？
一 微服務架構與云原生
微服務從 2010 年左右開始興起。最開始大家會把微服務架構應用在傳統(tǒng) IT 的基礎設施，也就是傳統(tǒng)的 IDC 或者說物理機上，我們使用這些物理機為我們的微服務架構提供資源，形成一個分布式的系統(tǒng)，互相協(xié)作、協(xié)同。
隨著我們整個的 IT 基礎設施的發(fā)展，逐步到了云的時代。
我們在云時代做的第一步是云托管，也就是把在傳統(tǒng) IDC 之中的物理機，換成云上的虛擬機以及云上虛擬的彈性資源，對于微服務架構其實改動并不是非常巨大。我們把原來部署在物理機上的架構模型，可以比較容易地轉到在云上托管的虛擬機中，也稱之為 Lift and Shift 方式。與此同時，在云托管時代，我們也嘗試更好利用云上虛擬機的彈性能力，去做一些微服務的自動化水平擴縮容。
隨著技術進一步發(fā)展，到云原生時代，到底什么不同了？云原生希望能夠把像微服務、DevOps 這些架構和理念，能夠和云所提供的服務、能力、平臺更好地進行融合、進行協(xié)同和協(xié)作。我們希望云不光光是提供彈性物理資源，比如說存儲、計算、網(wǎng)絡等資源，而是能夠為微服務提供更好的一個運行環(huán)境和平臺。這個需要我們做到以下兩點：
- 對資源層面聯(lián)合優(yōu)化，對資源的更優(yōu)使用。
- 對云服務與平臺的充分利用，研發(fā)、運維效率的極大提升。
這個其實是云原生想去做的事情，就是讓我們的微服務架構和體系，能夠和云與云上面的服務、平臺，以最佳的方式工作、協(xié)同在一起，降本提效。
二 微服務與云原生
如果我們以微服務為中心去看待微服務與云原生，可以從四個點講一講它們之間的關系，以及微服務在云原生時代的演進。
- 生命周期的管理。
- 流量治理。
- 編程模型。
- 可信安全。
生命周期
從本質(zhì)上來講，微服務就是把單體應用從一個巨型的應用拆分成數(shù)個更微小的服務，協(xié)作完成原來單體應用所提供的等效業(yè)務服務。因此，服務與服務之間會有依賴關系，服務也需要去部署到一個或多個資源上。
如上圖所示，大家可以看到，原來的單體應用與資源之間的關系其實是一對一的關系，單體應用的協(xié)同也都是一些內(nèi)部協(xié)同，不存在外部動態(tài)的依賴。而當我們轉換到微服務之后，可以看到這張圖會變成網(wǎng)狀，變得復雜起來。
因此由于內(nèi)在原因，超過 50% 的企業(yè)會認為微服務架構或采用微服務架構，其中最大的挑戰(zhàn)在于更為復雜的運維，也就是更為復雜的生命周期管理。
我們在今天講云原生的根基——容器與容器服務，就在于幫助微服務解決生命周期管理以及運維管理難題，那是怎么解決的呢？
我認為分為兩個部分：
第一部分，不同微服務之間可能存在一些異構，為了讓每一個團隊在微服務體系下發(fā)揮最大效能，我們允許不同團隊采用不同的編程語言，甚至不同的運行環(huán)境來去運行這些微服務。因此，我們在運維和管理微服務時，最初其實并沒有一套統(tǒng)一的標準去處理的異構環(huán)境，這也是為什么后來容器這項云原生技術變得流行起來，它的一個重要作用就是通過一層標準的封裝以及標準的運行時，來標準化微服務部署。這樣從生命周期管理的角度來看，每一個微服務之間的差異就會變少，共同點變多。
基于這個技術，后來我們又開發(fā)出另一層：容器平臺，也是今天比較流行的，像 Kubernetes 。它的作用是幫助把已經(jīng)標準化的微服務最便捷地運行到底層資源上面。我們講到的存儲、計算、網(wǎng)絡都通過 Kubernetes 這層進行了統(tǒng)一抽象和封裝，讓已經(jīng)被容器統(tǒng)一的微服務能夠直接運行到 Kubernetes 平臺。因此，運維人員不用再苦惱如何去把某個微服務分配到具體的某一個資源或計算單元上去。通過容器和容器平臺，大大簡化了微服務本身的生命周期管理，簡化了微服務自身的運維管理問題，也促進了微服務更多地被企業(yè)所采用。
如果更微觀地去看，容器和容器平臺具體給微服務的生命周期還提供了哪些幫助呢？
例如 Kubernetes 引入了一個非常有意思的概念，叫做 pod，一個 pod 實際上是一組容器的集合，在一個 pod 中可以運行一個或多個容器。一般來講，當我們采用微服務架構時，會把微服務的主體運行在主容器中，主容器的生命周期跟 pod 自身的生命周期是一個耦合的狀態(tài)。
除此之外，我們還會運行一些邊車容器或者叫 Sidecar 容器，為主容器提供一些輔助功能，比如說日志采集、網(wǎng)絡代理、身份鑒權等。我們都可以把它放 Sidecar 容器中，這樣微服務具備了 Super power，一種超能力。它除了自身提供的核心業(yè)務服務以外，我們還可以裝上盔甲，也就是動態(tài)添加一些額外的輔助能力，讓微服務管理變得更強健更強壯。
另一方面，其實 pod 這個模型還提供了一些非常有用的功能：
- 狀態(tài)信息。Pod 會提供一個標準接口顯示運行狀態(tài)。例如，是否已經(jīng)準備好接收流量，如果準備好接收流量，那么從 ingress 流量就可以打到微服務上。如果運行狀態(tài)不良，我們可以嘗試對這個容器進行修理、重啟或刪除，甚至是換到另一個計算單元上去運行，為微服務整體的穩(wěn)定性提供了保障。
- 地址服務。每一個 pod 都有一個標準化的 DNS 地址服務，可以被統(tǒng)一的尋址。這樣對于需要統(tǒng)一暴露出來 API 的日志、監(jiān)控、追蹤能力都有著非常大的幫助，可以根據(jù)這個 DNS 的地址來訪問 pod 所暴露的可觀測性信息，便捷及時的發(fā)現(xiàn)運行時問題。
所以我們可以看到容器平臺及容器其實在微觀上也幫助了微服務具有更多能力、具有更強的健壯性以及具有更好的可觀測性。
在這，如上圖所示，在微服務運行時這一方面，容器平臺也提供了非常有效的能力幫助我們做 Day 2 的微服務更新、發(fā)布、擴容等操作。比如 Kubernetes 提供了幾種比較典型的升級或是擴容策略：Rolling deployment、Blue-green release 等等，這些都有效簡化了我們的運維工作，提高了運維本身的確定性和自動化效率。
總而言之，在生命周期這一方面，通過使用容器及容器平臺技術，大大提高了我們對于容器生命周期管控的標準化及自動化程度，節(jié)約了人力成本，提升了效率，讓更多的企業(yè)愿意使用微服務這種技術。
流量治理
微服務一方面是把原來在靜態(tài)編譯時產(chǎn)生的能力與能力之間的關聯(lián)關系，通過架構拆分推演到動態(tài)的運行時。因此在運行時，服務與服務之間是需要進行通訊、協(xié)同，才能完成某一項具體的業(yè)務功能。當大家進行通訊、協(xié)同時，就一定要對其通訊過程進行管理，或者說要進行流量管理。例如，我們要知道怎樣從一個微服務找到另一個微服務，以及怎樣能保證一個微服務找到最佳的微服務實例跟它進行通訊，這是一個比較復雜的過程，其中包括 RPC 能力、服務注冊發(fā)現(xiàn)能力、動態(tài)配置管理能力以及服務降級能力等等。
為了減輕業(yè)務開發(fā)同學的負擔，不用重復的在每一個微服務中寫一遍微服務的流量管理的通用能力，因此大家開發(fā)了很多框架，比如在 Java 體系中，著名的 Spring Cloud 提供了一個分布式微服務管理框架；在 Go 語言的開源生態(tài)中也有像 Go Mirco 這樣的體系；在阿里巴巴內(nèi)部我們也有像 HSF 這樣的體系發(fā)展起來的微服務治理框架。
因此，從抽象層面可以看到一個服務包含了兩個層面：
一個層面是本身的業(yè)務邏輯，也就是由微服務業(yè)務開發(fā)人員去編寫的，功能實現(xiàn)與業(yè)務實現(xiàn)相關的代碼。
另一個層面是為了實現(xiàn)微服務與微服務之間通訊、流量、服務治理的代碼，我們會將其抽象成一個框架，如下圖中標出的 Spring Cloud。這樣的抽象帶來了一個問題，就是所有的通用能力都依賴于這個具體的框架。
假設在公司之中，除了 Spring Cloud 之外，我們?nèi)ヒ肓硗庖恍┓湛蚣?#xff0c;如阿里巴巴 HSF 如果希望和 Spring Cloud 框架上面編寫的微服務進行通訊的話應該如何去操作？這就要求 HSF 與 Spring Cloud 之間互聯(lián)互通以及協(xié)議之間的互相理解。但其實這些框架之間往往并不具備這個能力。更大的一個問題可能在于，云原生時代我們允許這些微服務的研發(fā)能用不同開發(fā)語言及模型來進行編程。因此，框架之間的系統(tǒng)并不是不是一對二的關系，也不是 僅僅是 Spring Cloud 與 HSF 的關系，可能是 Java 體系與 JavaScript、Python、Go 體系這些微服務框架都需要打通的問題，它變成了一個 N to M 的 problem，來解決多語言、復雜環(huán)境中微服務的治理與管理問題。
這時，當我們有了容器、容器平臺、Pod 這些抽象，能夠提供一個平臺，而不是必須要完全依賴于業(yè)務中的代碼或 框架時，有沒有更好的辦法來解決剛才提到的問題？
現(xiàn)在有一個比較流行的概念叫 Service Mesh——服務網(wǎng)格。它的本質(zhì)就是為了更好地解決流量治理在多語言、多環(huán)境場景下的問題，它的主要思想如下：
第一就是希望把流量管理的這些框架能力從耦合在業(yè)務的二進制中抽象、剝離出來，形成一個流量管理的單獨進程，并以 Sidecar 的模式部署在 Pod 中。通過操作系統(tǒng)級別的透明流量劫持工作，把所有的微服務之間的流量劫持到 Sidecar 中，然后通過 Sidecar 與 Sidecar 之間通訊進行流量的轉發(fā)與管理。這樣問題就簡單多了，我們只需要讓流量管理的 Sidecar 之間互相通訊、能夠進行互聯(lián)互通。目前比較知名、流行的開源流量劫持和管理 Sidecar 實現(xiàn)叫做 Envoy。
當然，單單有了這層流量劫持與管理還是不夠的，還需要管控平面的支持。比如原來微服務體系做的服務注冊、服務發(fā)現(xiàn)以及流量觀測還是需要的，這些策略和規(guī)則需要下發(fā)給流量管理的 Sidecar 代理。因此，我們還需要構建一個管控平面來管理在 Pod 中部署的流量管理的數(shù)據(jù)平面的單點，讓它們形成一個網(wǎng)狀，形成一個集群。所以我們需要有一些管控平面的能力，在開源中比較流行的一個管控平面實現(xiàn)叫 Istio。主要實現(xiàn)了三個能力：流量的配置、流量的安全、流量的觀測。
我們認為在云原生這個逐漸平臺化的時代，大部分新的應用及場景都會嘗試選用基于 Service Mesh 的技術進行微服務的流量治理。
編程模型
請求驅動
請求驅動，也就是支持基于請求的動態(tài)彈性伸縮并且簡化請求處理邏輯。有些同學可能把這個模型稱之為 Event-driven，也就是事件驅動，但是請求驅動實際是事件驅動中的一個分支。
什么是請求驅動呢？從傳統(tǒng)的微服務架構看，當一個外部系統(tǒng)請求進來后，一般都會經(jīng)過一個 L4/L7 的負載均衡，然后給到不同的微服務實例上面。在同一個微服務實例本身進程的內(nèi)部，一般會有兩塊邏輯，第一塊邏輯是請求管理，它可能是一個 HTTP Server 和一些 Handlers，有一些隊列管理、請求分發(fā)等能力。這些請求最終會提交到第二個邏輯部分，processor 也就是真正的請求業(yè)務處理邏輯中，真正的處理并且相應這些請求。
這個架構會帶來兩個問題：
- 請求管理的邏輯在不同的微服務框架實現(xiàn)中都要去寫一遍，比如 Java、Go 或 Python 都要有自己的請求管理邏輯。
- 請求管理和請求處理形成耦合關系。因此，在這個架構下不存在一個全局獨立的可以感知請求以及進行流量管理的控制層。只有到了微服務實例自身的處理層，才能解析這個請求。這時候即便這個微服務實例已經(jīng)過載，也很難把請求再轉發(fā)給其他微服務實例進行負載均衡了。
請求驅動系統(tǒng)就是嘗試去解決這兩個問題，我們嘗試在微服務中做一個請求驅動的解耦操作。
首先把外部系統(tǒng)傳輸過來的請求都進行一次標準化，我們有一個適配器，進行標準化之后，把它放到一個請求負載均衡器中，這個負載均衡已經(jīng)能理解請求本身的語義，它就能驅動請求處理的邏輯進行請求處理。當請求處理單元不夠時，可以通過請求處理的管理器進行擴容；當請求處理的邏輯單元比較多時，還可以進行縮容，這樣就可以節(jié)約成本。另外，開發(fā)人員也不用再去實現(xiàn)請求管理邏輯，降低了開發(fā)成本。
剛才講的請求驅動模型可以分為三部分：
- 請求的標準化
- 請求的路由
- 請求的處理
其實，如果把外部系統(tǒng)的請求標準化，加上請求路由、處理管理，而不包含業(yè)務代碼，就會組成我們常說 Serverless 概念。這也就是一種把微服務體系和平臺化的 Serverless 體系融合的一個過程。
Serverless 平臺有阿里云 FaaSS、SAE，AWS 有 Lambda、Google 推出了 CloudRun、Azure 有 Functions。如果大家希望自己能夠構建一個 Serverless 平臺，如請求標準化，也有像 Cloud Events 這樣的開源請求標準， Knative 這樣的處理路由以及處理請求的水平擴展能力組件，可以利用 Kafka 或者 RocketMQ 來做請求本身的持久化以及請求本身的轉發(fā)。
分布式運行時
在編程模型中的分布式運行時，也就是我們希望微服務能夠有更好的多語言環(huán)境支持、環(huán)境可移植性并能做到極速啟動。
單體應用時代，我們的業(yè)務代碼跟中間件代碼耦合在一起，而且是一份部署的實例；當?shù)搅宋⒎諘r代，通過像 Service Mesh 服務網(wǎng)格進行流量管理之后，可以看到我們的業(yè)務代碼和流量管理代碼實際上是可分離的，只有部分中間件的代碼仍然和部分業(yè)務代碼耦合在一起形成一個二進制。
為了能夠做到充分的多語言能力支持、環(huán)境的可移植性，我們希望能夠把剩余的中間件代碼也從業(yè)務中解耦出來，這項技術叫做運行時解耦。它的根本理念是通過向業(yè)務代碼提供一個標準的可擴展 API，并且是一個多語言可支持、輕量級的 API，通過調(diào)用 API 來實現(xiàn)中間件的功能，我們把中間件的能力像流量管理一樣下沉到一個 Sidecar 中，用一種語言進行統(tǒng)一實現(xiàn)，然后設計一個可拔插的模式，讓大家能夠拔插更多中間件的能力。
Dapr
這項技術比較領先的一個實踐是微軟去年推出的一個分布式運行時，叫做 Dapr。
Dapr 向業(yè)務的代碼暴露了兩個 API，一個是 HTTP 的 API，另外一個是 grpc 的 API。這兩個 API 都非常輕量級，并能夠跨多種語言，Dapr 本身作為分布式運行時，可以對接多種中間件系統(tǒng)，向上通過標準的 API 屏蔽不同系統(tǒng)之間的差異性，提供一定的編程界面界面統(tǒng)一。代碼實現(xiàn)上把中間件的代碼從應用級別抽離到 Sidecar 中，如上圖所示，我們在業(yè)務上面只需要寫業(yè)務的代碼，其他代碼幾乎都被基于 Dapr 的平臺所接管。
Dapr 本身分為兩部分：第一部分是 Dapr 向 Application 暴露的 API，另一部分是 Dapr 的框架層。
通過 Dapr 的框架層，我們可以接入各種不同的 Dapr 相關實現(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è)務代碼、應用代碼去使用，這樣就做到了業(yè)務代碼與中間件、流量管理能力的更徹底的解耦，應用的開發(fā)人員也能夠更專注、更自由地去關注業(yè)務代碼研發(fā)。
可信安全
因為微服務與微服務之間需要有網(wǎng)絡通訊，需要有安全可信的認證。傳統(tǒng)做法就是把微服務放到一個可信網(wǎng)絡環(huán)境中，假設網(wǎng)絡環(huán)境中所有通訊、執(zhí)行的應用或微服務都是受信的，它們可以自由通訊或交流，可能有一些輕量級的鑒權與授權進行一定的安全防護措施。
但這個模型會帶來一種風險，當有微服務入侵到這個可信網(wǎng)絡之中，它會對整個微服務體系造成極大的安全隱患，因為可信網(wǎng)絡中的內(nèi)部防范一定程度上是比較欠缺的。
另外，經(jīng)常會有可信網(wǎng)絡與可信網(wǎng)絡之間的微服務互相調(diào)用或鑒權的問題，常見解決方法是通過 VPC peering 或者通過 gateway 網(wǎng)絡的網(wǎng)關打通。利用一個可信通道保證微服務與微服務之間的網(wǎng)絡層面可信的調(diào)用。但同樣引出一種問題，比如在另外一個可信網(wǎng)絡中被入侵，便可以攻擊到其它相連的可信網(wǎng)絡，也增大了受攻擊的可能性。
在微服務時代，我們思考是否有更好的解決方式，不去假設網(wǎng)絡是完全可信的環(huán)境。因此，提出了一個叫做微服務或應用可信安全。也就是微服務與微服務或者機密文件之間的每一次通訊，都基于身份體系。微服務會提供給它所溝通、協(xié)同的目標對象一個身份認證。就好比我們通過瀏覽器訪問 HTTPs 網(wǎng)站，這些網(wǎng)站需要提供證書，我們的微服務也需要提供一個自身的身份認證，這樣接收方就可以通過平臺進行認證且查看授權。只有這些認證都通過，才會和開始微服務的通訊。
實際上，利用平臺的特點在網(wǎng)絡層面內(nèi)部以應用為中心，又建設起一套基于統(tǒng)一身份認證授權的體系。
但這個體系還是比較難構建的，相當于要在不完全受信的網(wǎng)絡中，需要有一個可以信任的平臺層或中間層，也就類似 PKI 中的 CA 機制。在 HTTPs 上，比如說我們要信任一個 CA，可能需要提前講證書預置在操作系統(tǒng)中，從安裝時就要預置好，才能提供一個更為安全的端到端的可信，否則是無法構建好這個信任鏈的。同樣的，在云環(huán)境中也需要這個機制。云本身是一個可控平臺，通過從云最底層的硬件機制，到云上運行的 OS 上，再到最終向上部署微服務的平臺層，我們都要建立起來了一個可證的授信鏈，最終給每一個微服務提供自身的身份 ID 以及授權可證的授權信息，這樣微服務才能提供統(tǒng)一可驗證、可證實的身份。也就是說在云原生時代，通過平臺思維能夠給微服務安全提供更大的價值。
另外在平臺與平臺之間或網(wǎng)絡與網(wǎng)絡之間，也可以通過平臺級別的可信授信來建立關聯(lián)的關系，讓不同平臺之間的微服務也能產(chǎn)生信任關系。為了打通不同的平臺，有一個開源項目叫做 spiffe，它提供了統(tǒng)一的標準身份 ID 以及如何統(tǒng)一標準地進行授權信息的可證和授權信息的認證。
三 EDAS
其實上面講了那么多，可以發(fā)現(xiàn)在開源開放領域不停地有新的技術衍生出來，不管是與微服務流量治理相關，還是與微服務生命周期相關，又或是微服務的可信安全、編程模型，如果大家自己嘗試去構建這種能力或平臺，一般還是需要花費非常大的時間和精力的。
因此阿里云最近升級了云上的服務——EDAS，把 EDAS 從傳統(tǒng)的面向微服務的管理體系，基于云原生的基礎設施變成了一個云原生應用 PaaS，提供容器的生命周期管理、微服務治理、可觀測性、安全流量治理等能力，讓阿里云用戶能最大化享受到微服務在云原生時代的紅利，同時又不需要花費時間去構建這樣的平臺。
因此推薦對云原生微服務感興趣的同學可以嘗試使用 EDAS。
四 云原生微服務
在云原生時代，微服務的特點：
- 平臺化，利用云作為一個平臺，如微服務架構進行更多的賦能。
- 標準化，我們希望微服務本身的部署、運維，微服務之間與其它服務之間的通訊都能做到標準化，讓服務與服務之間的互聯(lián)互通變得更容易，服務能夠跨到不同的平臺上，做到一次編寫、一次定義、多處運行。
- 微服務輕量化，讓研發(fā)人員關心核心業(yè)務代碼、業(yè)務邏輯的研發(fā)，而不是復雜的微服務治理相關的邏輯研發(fā)。
- 微服務的產(chǎn)品化。我們希望能構建微服務相關的產(chǎn)品，以產(chǎn)品化的方式支持大家使用微服務架構，讓它變得更好用、更易用。
五 全球開源微服務框架活躍度報告
我們最近花了很大精力收集在云原生時代比較活躍的一些微服務項目，然后發(fā)現(xiàn)了幾個特點：
- quarkus 這個項目非常活躍，它可以幫助 Java 或 Java 生態(tài)盡量輕量化，適應云原生時代我們對彈性和高效啟動速度的要求。
- Spring Cloud 的上升趨勢還是非常好的，作為 Java 里非常典型的微服務框架，在阿里巴巴我們也是在 Spring Cloud 生態(tài)中進行深耕，現(xiàn)在最流行的一個Spring Cloud 云服務提供廠商就是 Spring Cloud Alibaba。
- 最后像 Dubbo，還有阿里正投資很多人力去共建的 Dapr 項目其實也比較活躍。
原文鏈接：https://developer.aliyun.com/article/771128?
版權聲明：本文內(nèi)容由阿里云實名注冊用戶自發(fā)貢獻，版權歸原作者所有，阿里云開發(fā)者社區(qū)不擁有其著作權，亦不承擔相應法律責任。具體規(guī)則請查看《阿里云開發(fā)者社區(qū)用戶服務協(xié)議》和《阿里云開發(fā)者社區(qū)知識產(chǎn)權保護指引》。如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容，填寫侵權投訴表單進行舉報，一經(jīng)查實，本社區(qū)將立刻刪除涉嫌侵權內(nèi)容。總結
以上是生活随笔為你收集整理的云原生时代，微服务如何演进？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 连载：阿里巴巴大数据实践—数据服务
- 下一篇： 一篇文章教会你使用html+css3制作