*作者：弈川*
*稽核&校對：筱姜、瀟航*
*編輯&排版：雯燕*

# 微服務架構介紹

### 微服務架構誕生背景

在網際網路早期即 Web 1.0 的時代，當時流行的是單體應用，研發團隊比較小，主要是外部網頁，然後新聞門戶等；到了新世紀的網際網路時期 Web 2.0 時代，網民數量大幅激增，相繼出現電商、社交這樣巨無霸級別的網際網路產品，出現了幾百人甚至上千的研發團隊在一個場景下，流量及業務複雜度相較於上一個時代有了質的變化，因此單體服務的弊端：例如研發效率等問題便顯現出來。

此時出現了一個叫 SOA 的架構，其架構思路與微服務很像，它有類似於 ESB 這種中心化元件，阿里的 HSF，包括後來開源的 Double，都是在此階段誕生的。

移動網際網路時代出現之後，各種各樣的 APP 誕生，生活也開始全面網際網路化。大流量高併發以及規模化的研發團隊變得越來越尋常，相應對高技術、生產力的要求也在逐步提升，此時微服務的概念應運而生。

微服務其實一直貫穿在整個架構的發展過程中。在 Java 的技術棧，類似於 Spring Cloud 、Double 這些框架都已經非常流行。不難發現整個社會已經步入數字化高速發展階段，此時更大的問題蘊含其中，如流量升高、應用複雜度提升，研發團隊擴大、對於效率的要求提高等等。

### 單體時期 1.0 版本

![1.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/9f9ab555822d4a2f9d1cb9edfc56eaf2~tplv-k3u1fbpfcp-zoom-1.image)

大部分的公司或早期業務都會經歷過這樣的過程（如圖所示）：先是客戶端，此時需要透過一個入口訪問，上圖中 SLB 是阿里雲一個負載均衡服務，它相當於一個網路入口，可以對應到 ECS（ECS 為阿里雲的虛擬機器）打到對應的單體的服務中，而此時他們會共用一個資料庫，這是第一個時期。

### 單體時期 2.0 版本

![2.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/69f23869ed9b42b090ef057dc7783e70~tplv-k3u1fbpfcp-zoom-1.image)

到第二個時期 SOA 架構：此時出現了分治的思想，它會將一些業務進行拆分。但它並未做到服務與底層的拆分，如儲存資料庫的拆分，其本質上還是共用一套資料庫，因此它還是單體的架構。

### 微服務時期

![3.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/6823811a9eb84316b4c4a93babd58c1c~tplv-k3u1fbpfcp-zoom-1.image)

而到微服務時期，如若客戶端透過 SLB 訪問閘道器（如圖所示），隨後會轉發對應的服務，且服務與服務之間會產生一些呼叫；每個服務會對應一個單獨的資料庫或快取，且每個服務會透過類似於 Nacos 這種的服務進行註冊、發現以及配置管理。

微服務引入之後，雖然解決了架構業務的分離，能夠讓研發團隊在某一個領域、業務能夠做到精專，不過從整體架構來看便會發現，相較於之前，它其實是更為複雜的，所以也帶來一些運維上的問題。

![4.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/eedf0b620e3249b280831e7fc76a90db~tplv-k3u1fbpfcp-zoom-1.image)

在單體架構中，於單體應用而言，會發生邊界不清晰、模組耦合、共享程式碼庫容易衝突的問題，同時如果團隊規模較大，此時的協作效率也會相對較低。但是微服務架構的核心就是解耦，如果做到拆分之後的解耦，就可以釋放開發團隊效率。

# 雲原生時代微服務架構發展

### 微服務技術在雲原生時代的技術引進

雲原生是一個很宏觀的概念，如果我們以微服務為起點來看雲原生給微服務帶來的變化與演進，可以更好地幫助我們理解什麼是雲原生。

![5.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/97c9a6c80d5f4e568c9049d3f43ea1d7~tplv-k3u1fbpfcp-zoom-1.image)

微服務和單體應用的本質是什麼呢？（如圖所示）它其實是把單體應用從一個巨型的應用拆分成數個微小的服務，協作來完成原先單體應用等效的業務服務。此時微服務與微服務之間會形成一個依賴關係，它需要部署至一個或多個資源上，這時的資源便是計算資源。

過去單體應用與資源之間的關係十分簡單，單體應用的協同也都是一些內部協同，不存在外部動態的依賴。但架構轉換到微服務之後，由於外部依賴和節點數量的爆炸，整個體系會變成網狀，管理起來十分複雜。超過 50% 的企業會覺得采用微服務架構，最大挑戰是複雜的運維，即整個服務生命週期的管理。

如今，比較公認的一點是雲原生的根基在於容器與容器的管理編排（K8s）。而容器與 K8s 的技術能夠幫助我們解決微服務體系中所存在繁雜運維的問題。

![6.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/598ee60362654e918c883d003fd3c175~tplv-k3u1fbpfcp-zoom-1.image)

首先不同的微服務之間會存在異構，即一個團隊，在微服務體系下為了發揮最大效能，可能會允許不同小團隊採用不同的程式語言、執行環境去執行微服務。因此最初我們在運維和管理微服務時，是沒有統一的標準去處理這些異構環境的。這便促發了雲原生容器技術的流行，因為這項技術的作用就是透過一層標準化的執行時和封裝來限制微服務部署。這樣從生命週期與管理角度來看，每一個微服務之間的差異變少，十分有利於資源的排程。

隨後。基於容器排程衍生出了容器平臺。容器平臺就是管理容器的，就 K8s 來說，它可以標準便捷地將微服務執行到底層的資源上，隨後儲存計算網路可以透過 K8s 這層來進行統一封裝，一層抽象與封裝，它類似於雲原生時代的作業系統。

它具體會提供哪些幫助呢？在 K8s 中有個概念叫 POD ，POD 是一組容器的結合，與微服務實體生命週期的耦合，在一個 POD 裡面，它可以執行一個或者是多個容器。

![7.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/ea11db38fb5e46469c1b6ff80c84952e~tplv-k3u1fbpfcp-zoom-1.image)

採用微服務架構時，一般會把微服務執行的主體放在主容器中，也就是把微服務執行的主邏輯放在主容器裡面。此時主容器的生命週期與 POD 的生命週期是完全耦合的，POD 什麼時候消亡，微服的執行主體便何時消亡。除此之外我們還會執行一些邊車容器— Sidecar，它主要是為主容器提供輔助功能，如日誌採集、網路代理、身份鑑權等 。此時的微服務便除了提供自身核心業務以外，它還可以動態的提供額外輔助能力，這讓微服務的管理變得更加穩定與便捷。

POD 這個模型還提供了許多非常有用的功能，比如狀態資訊。（狀態資訊是指：POD 會提供一個標準的介面來顯示執行時的狀態）透過這個資訊狀態可以出判斷微服務或是容器的執行狀態，如它是否處於執行中、業務是否已經準備好可以迎接流量接入，POD 為整體的穩定性提供了保障。另一個是地址服務功能，每個 POD 會有一個標準化的 DNS 地址服務，它對於需要統一暴露出來的 API ，日誌監控追蹤能力都十分有幫助。透過 DNS 的日誌地址來訪問以及暴露的可觀測性資訊，可以快速發現執行時的問題。由此便可總結：容器及容器平臺能夠在微觀上幫微服務具備更多的能力。

![8.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/518016ea4974469ca96668efab2eb3c6~tplv-k3u1fbpfcp-zoom-1.image)

圖中為 4 種釋出模型：

1. 滾動更新
2. 固定更新
3. 藍綠部署
4. 金絲雀釋出（灰度釋出）

### 流量治理

微服務將過去單體時期靜態的通訊關係，透過拆分編成動態執行時。通常服務間的通訊與協同是需要單獨管理的，微服務框架幫助我們進行了每個服務通用功能的抽象與實現。

![9.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/7810006ce0c442d2a6cf0bbb5f9385ad~tplv-k3u1fbpfcp-zoom-1.image)

抽象層面包含兩方面：業務邏輯與通訊、流量、服務治理能力。我們可以將底層通用能力抽象成一個具體的框架，但是不同微服務之間的框架是沒辦法實現相互呼叫的。而到了雲原生時代，它能夠使用不同的開發語言以及模型進行程式設計，實現微服務的研發。

![10.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/855d28ebd1814e6ca6aafae0e1ca4739~tplv-k3u1fbpfcp-zoom-1.image)

Service Mesh 服務網格就是為了解決流量治理在多語言，多環境下的問題而出現的。

在資料層面，Sidecar 負責流量劫持轉發以及管理，該功能典型 Sidecar 實現就是 Envoy。

如圖它會先將上面部分從框架層面抽象出來後與業務直接進行解耦，將通用能力放在 Sidecar 中，透過 Sidecar 之間的通訊、轉發去管理；這樣會使問題變得簡單很多。開發者只需要在流量管理和 Sidecar 之間通訊，不同技術棧的微服務例項便可實現互相通訊。

除了資料層面，我們還需要管控層面的支援。需要一個元件來實現原微服務體系中的策略規則的管理，經典實現就是 Istio。比如在原來在微服務體系中的服務註冊、服務發現、流量觀測等能力是需要管控層面的主線去完成的。有這些能力之後它就組成了 Service Mesh。我們可以透過管理 POD 中的流量以及資料層面的單點，讓他們形成網狀結構，變成叢集實現流量的分配、安全、觀測。

![11.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/fd7f6cb46156448c88f1fe14ba5fccfc~tplv-k3u1fbpfcp-zoom-1.image)
圖中的程式設計模型與函式計算相關

請求驅動是基於請求的動態彈性伸縮，並簡化請求處理的邏輯。微服務的呼叫，從流量進來後，會經過 4 層或者 7 層的負載均衡分發到不同的微服務例項；但是在同一個微服務例項程式的內部，一般會有兩個邏輯：第一個是請求管理，它可能是一個 HTTP 伺服器，或者是一些 Handler，也可能是一些佇列管理，請求分發能力的組成；這些組成最終會將請求提交到第二部分，即請求處理中，而請求處理也是開發者真正需要實現的一些邏輯。

比如說 Java Go 、Python，它們都有自己的一套請求管理邏輯，請求管理和請求處理之間會形成強烈的耦合，這個例項既包含請求的管理，又包含請求處理的邏輯。在這個架構下不存在一個全域性獨立，且可以感知到請求去進行流量管理的控制層，只有到整個例項自身的處理層才如此解釋請求。即便此時微服務例項已然過載，也很難再次將這個請求轉發到其它微服務例項上進行負載均衡。因此請求驅動系統就是查資料、並解決這兩個要素，開發者實際在做的就是請求驅動的解耦。

![12.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/9ebcddb89fc84ec489d6779b17d859e1~tplv-k3u1fbpfcp-zoom-1.image)

如圖所示，首先外部系統傳輸過來的請求會先進行標準化，有一個介面卡；標準化之後就會將其放在請求負載均衡器中，這個負載均衡器可以理解該請求本身的語義；然後它可以驅動並進行處理。當處理單元不夠時，它可以透過管理器來進行擴容；邏輯單元比較多時，它還可以進行縮容，這樣便形成了一個動態管理，可以為開發者節約非常多的成本。

請求驅動模型：

1. 請求標準化
2. 請求路由
3. 處理管理

將請求標準化、請求路由、處理管理等組合起來，便與 Serverless 的概念吻合。開發者根本不需要去關心 Server ，只需要去專注業務邏輯即可。這其實也是微服務體系與平臺化的 Serverless 架構融合的過程。阿里雲的 FC （函式計算）和 SAE（應用引擎） 都是以解決這些問題為核心的。

# 微服務+Serverless的最佳實踐

![13.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/b49729e35e974cc5bfbc42d9ffa26ebc~tplv-k3u1fbpfcp-zoom-1.image)

Serverless 其實經過了很多年的發展，其理念最早可以追溯到 2012 年；而2014 年 AWS 正式推出 Lambda，才掀起了 Serverless 浪潮；但隨後而來的是一段沉靜的發展期。這種情況出現的原因是為什麼呢？分析來看是因為函式計算的開發模式與原本模式有非常大的出入，它更適合前端而不是 long running 形式的一些應用，它更偏向基於請求的一些處理。因此那些需要長時間執行的服務或應用架構便不太能夠享受到 Serverless 所帶來的彈性和降本提效等紅利。

### 微服務架構的痛點

![14.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/2afdde5cd778485aa21b6a04926183ed~tplv-k3u1fbpfcp-zoom-1.image)

微服務的痛點在於穩定性。微服務帶來了許多其他元件。例如服務發現、或是其他的一些工具類的產品，這些在單體情況下會變得更加複雜，因為整個架構變成網狀結構。容器與容器平臺在某些程度上是幫助我們承載微服務這部分的運維的，但是其本身如容器 K8s 都是存在一定複雜性的。

![15.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/3f3f73e67fc846ed9ae35b0566148da0~tplv-k3u1fbpfcp-zoom-1.image)
K8s 的架構圖

K8s 不僅複雜也存在一些痛點：

1. 容器映象部署方式差異
2. K8s 元件運維的複雜
3. 學習成本

![16.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/11efa0cce2a84d1c9f0174d29c2fcdd8~tplv-k3u1fbpfcp-zoom-1.image)

對於開發者來說是最有吸引力的是不需要改變原本的開發方式的基礎上可以將精力專注於業務邏輯。而微服務比較理想的狀態也是開發者只需關注架構中的業務系統，其它部分如：閘道器 CICD 釋出系統、驗貨流程，註冊中心、告警監控、分析日誌，這些通通都不再需開發者再去關心。其優勢可以總結為：

1. 讓開發者專注業務邏輯
2. 不改變原有開發方式
3. 無需關心與運維底層資源
4. 具備彈效能力可以降低閒時成本
5. 優秀的工具鏈

# 總結

![17.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/8b9c3aa246c849aa82521c019e9b3e5c~tplv-k3u1fbpfcp-zoom-1.image)

微服務體系在整個雲端計算發展的時代有不同的事件。如最開始部署就是傳統的 IT 設施，像 IDC 這種機房，微服務提供的是靜態的物理計算資源。

然後到了第二步就是雲託管時代，就是我們大家所熟知的 VM，阿里的話就是 ECS ，它可以提供彈性的計算資源，但它並沒有實質的改變，只是資源上變成彈性，它對於服務、微服務的部署，包括管理運維等本質上都沒有太大變化。

到了第三階段雲原生時代，雲平臺、雲服務都可以承擔這些複雜的運維操作、配置、管理。微服務提供的就是一個執行環境與平臺，此時使用者只需要去關心業務系統、以及如何實現業務系統即可。將複雜的技術變得越來越簡單，讓使用者不再感知那些煩雜的操作，由平臺代替使用者去做重複的、難以維護的工作，這也十分符合計算機技術整體的發展方向。

*作者介紹：*

*弈川｜阿里云云原生團隊*
*目前從事阿里雲 Serverless 應用引擎的研發工作，專注於aPaas、微服務、分散式系統、Serverless 工具鏈等方向，致力於打造下一代 Serverless 平臺，讓傳統應用的開發者能零改造、低成本的享受 Serverless、K8S 等技術紅利。*

*相關連結：*

*1）社群官網
http://www.serverless-devs.com/
2）專案倉庫
https://：.com/Serverless-Devs/Serverless-Devs
3）Serverless Desktop 桌面客戶端
https://serverlessdevs.resume.net.cn/zh-cn/desktop/index.html
4）Serverless 應用開發者套件
http://serverless-dk.oss.devsapp.net/docs/tutorial-dk/intro/react
5）Serverless Devs CLI 
https://serverlessdevs.resume.net.cn/zh-cn/cli/index.html
6）Serverless Hub 應用中心
https://serverlesshub.resume.net.cn/#/hubs/special-view*

點選[此處](https://developer.aliyun.com/live/247332)，看相關影片版解析~

Serverless 下的微服務實踐

相關文章