這裏我們拋出一個我們自己的理解：雲原生代表着原生爲雲設計。詳細的解釋是：應用原生被設計爲在雲上以最佳方式執行，充分發揮雲的優勢。

這個理解有點空泛，但是考慮到雲原生的定義和特徵在這些年間不停的變化，以及完全可以預料到的在未來的必然變化，我覺得，對雲原生的理解似乎也只能回到雲原生的出發點，而不是如何具體實現。

 

 

 

前言

自 2013 年容器（虛擬）技術（Docker）成熟後，後端的架構方式進入快速迭代的階段，出現了很多新興概念：

• 微服務
• k8s
• Serverless
• IaaS：基礎設施服務，Infrastructure-as-a-service
• PaaS：平臺服務，Platform-as-a-service
• SaaS：軟體服務，Software-as-a-service
• Cloud Native： 雲原生
• Service Mesh

後端架構的變遷和雲端計算的發展密切相關，架構其實在不斷地適應雲端計算，特別是雲原生，被譽爲未來架構，在 2019 年，雲原生落地方案 Service Mesh 在國內外全面開花，我認爲，未來已來。

接下來，我們將：

• 梳理後端架構演化史，回顧後端架構發展歷程；
• 回顧雲服務發展歷程，探討雲原生概念；
• 梳理雲原生實現方案 Service Mesh 的發展歷程；
• 介紹 Service Mesh 的代表 Istio 的亮眼功能；

後端架構演化史

集中式架構

集中式架構又叫單體式架構，在Web2.0模式並未大規模興起時十分流行。後來，基於Web應用的B/S（Browser/Server）架構逐漸取代了基於桌面應用的C/S（Client/Server）架構。B/S架構的後端系統大都採用集中式架構，它當時以優雅的分層設計，統一了伺服器後端的開發領域。

集中式應用分爲標準的3層架構模型：數據存取層M、服務層V和邏輯控制層C。每個層之間既可以共用領域模型物件，也可以進行更加細緻的拆分。

其缺點是

• 編譯時間過長;
• 迴歸測試周期過長;
• 開發效率降低等；
• 不利於更新技術框架

分佈式系統架構

對於網際網路應用規模的迅速增長，集中式架構並無法做到無限制的提升系統的吞吐量，而分佈式系統架構在理論上爲吞吐量的上升提供了無限擴充套件的可能。因此，用於搭建網際網路應用的伺服器也漸漸地放棄了昂貴的小型機，轉而採用大量的廉價PC伺服器。

容器技術新紀元 Docker

分佈式架構的概念很早就出現，阻礙其落地的最大問題是容器技術不成熟，應用程式在雲平臺執行，仍然需要爲不同的開發語言安裝相應的執行時環境。雖然自動化運維工具可以降低環境搭建的複雜度，但仍然不能從根本上解決環境的問題。

Docker的出現成爲了軟件開發行業新的分水嶺；容器技術的成熟，也標誌技術新紀元的開啓。Docker讓開發工程師可以將他們的應用和依賴封裝到一個可移植的容器中。就像當年智慧手機的出現改變了整個手機行業的遊戲規則一樣，Docker也大有席捲整個軟體行業，並且進而改變行業遊戲規則的趨勢。通過集裝箱式的封裝，開發和運維都以標準化的方式發佈的應用，異構語言不再是桎梏團隊的枷鎖。

在 Docker 之後，微服務得以流行開來

微服務架構

微服務架構風格是一種將一個單一應用程式開發爲一組小型服務的方法，每個服務執行在自己的進程中，服務間通訊採用輕量級通訊機制 機製(通常用HTTP資源API)。這些服務圍繞業務能力構建並且可通過全自動部署機制 機製獨立部署。這些服務共用一個最小型的集中式的管理，服務可用不同的語言開發，使用不同的數據儲存技術。

微服務優勢

• 可延伸
• 可升級
• 易維護
• 故障和資源的隔離

微服務的問題

但是，世界上沒有完美無缺的事物，微服務也是一樣。著名軟體大師，被認爲是十大軟體架構師之一的 Chris Richardson 曾一針見血地指出：「微服務應用是分佈式系統，由此會帶來固有的複雜性。開發者需要在 RPC 或者訊息傳遞之間選擇並完成進程間通訊機制 機製。此外，他們必須寫程式碼來處理訊息傳遞中速度過慢或者不可用等區域性失效問題。」

在微服務架構中，一般要處理以下幾類問題：

• 服務治理：彈性伸縮，故障隔離
• 流量控制：路由，熔斷，限速
• 應用觀測：指標度量、鏈式追蹤

解決方案 Spring Cloud（Netflix OSS）

這是一個典型的微服務架構圖

Spring Cloud 體系提供了服務發現、負載均衡、失效轉移、動態擴容、數據分片、呼叫鏈路監控等分佈式系統的核心功能，一度成爲微服務的最佳實踐。

Spring Cloud 的問題

如果開始構建微服務的方法，肯定容易被 Netflix OSS/Java/Spring/SpringCloud 所吸引。但是要知道你不是Netflix，也不需要直接使用 AWS EC2，使得應用程式變得很複雜。如今使用 docker 和採用 memos/kubernetes 是明智之舉，它們已經具備大量的分佈式系統特性。在應用層進行分層，是因爲 netflix 5年前面臨的問題，而不得不這樣做（可以說如果那時有了kubernetes，netflix OSS棧會大不相同）。

因此，建議謹慎選擇，按需選擇，避免給應用程式帶來不必要的複雜度。

的確 SpringCloud 方案看起來很美好，但是它具有非常強的侵入性，應用程式碼中會包含大量的 SpringCloud 模組，而且對其他程式語言也不友好。

Kubernetes

Kubernetes 出現就是爲了解決 SpringCloud 的問題，不侵入應用層，在容器層解決問題。

Kubernetes 起源

Kubernetes最初源於谷歌內部的Borg，提供了面嚮應用的容器叢集部署和管理系統。

Kubernetes的目標旨在消除編排物理/虛擬計算，網路和儲存基礎設施的負擔，並使應用程式運營商和開發人員完全將重點放在以容器爲中心的原語上進行自助運營。

Kubernetes 也提供穩定、相容的基礎（平臺），用於構建定製化的 workflows 和更高階的自動化任務。 Kubernetes 具備完善的叢集管理能力，包括多層次的安全防護和準入機制 機製、多租戶應用支撐能力、透明的服務註冊和服務發現機制 機製、內建負載均衡器、故障發現和自我修復能力、服務卷動升級和線上擴容、可延伸的資源自動排程機制 機製、多粒度的資源配額管理能力。

Kubernetes 還提供完善的管理工具，涵蓋開發、部署測試、運維監控等各個環節。

Service Mesh

Service Mesh 是對 Kubernetes 的增強，提供了更多的能力。

2018年9月1日，Bilgin Ibryam 在 InfoQ 發表了一篇文章 Microservices in a Post-Kubernetes Era，中文版見後 Kubernetes 時代的微服務（譯文有些錯誤，僅供參考）。

文中作者的觀點是：在後 Kubernetes 時代，服務網格（Service Mesh）技術已完全取代了使用軟體庫實現網路運維（例如 Hystrix 斷路器）的方式。

如果說 Kubernetes 對 Spring Cloud 開了第一槍，那麼 Service Mesh 就是 Spring Cloud 的終結者。

總結

最後我們用一個流程圖來描述後端架構的發展歷程

每個關鍵節點的大概時間表

架構/技術	時間/年份
集中式架構	~
分佈式架構	~
Docker	2013
微服務	2014
Spring Cloud	2014
Kubernetes 成熟	2017
Service Mesh	2017

可以看出，微服務生態這裏，Spring Cloud 爲代表的這條路已經後繼無人了，未來屬於 Service Mesh 。
Service Mesh 經過2年的發展，目前 Service Mesh 已經足夠成熟，已經有生產落地的案例，我們接下來就看看 Service Mesh，在此之前，我們要先理解一個概念，雲原生。

雲原生 Cloud Native

如何理解「雲原生」？之所以將這個話題放在前面，是因爲，這是對雲原生概唸的最基本的理解，而這會直接影響到後續的所有認知。

注意：以下雲原生的內容將全部參照敖小劍的 暢談雲原生（上）：雲原生應用應該是什麼樣子？ 這篇文章，圖畫得太好了。

雲原生的定義一直在發展，每個人對雲原生的理解都可能不同，就如莎士比亞所說：一千個人眼中有一千個哈姆雷特。

2018 年 CNCF (Cloud Native Computing Foundation)更新了雲原生的定義。

這是新定義中描述的代表技術，其中容器和微服務兩項在不同時期的不同定義中都有出現，而服務網格這個在 2017 年纔開始被社羣接納的新熱點技術被非常醒目的列出來，和微服務並列，而不是我們通常認爲的服務網格只是微服務在實施時的一種新的方式。

那我們該如何理解雲原生呢？我們嘗試一下，將 Cloud Native 這個詞彙拆開來理解，先看看什麼是 Cloud。

什麼是雲 Cloud

快速回顧一下雲端計算的歷史，來幫助我們對雲有個更感性的認識。

雲端計算的出現和虛擬化技術的發展和成熟密切相關，2000 年前後 x86 的虛擬機器技術成熟後，雲端計算逐漸發展起來。

基於虛擬機器技術，陸續出現了 IaaS/PaaS/FaaS 等形態，以及他們的開源版本。

2013 年 docker 出現，容器技術成熟，然後圍繞容器編排一場大戰，最後在 2017 年底，kubernetes 勝出。2015 年 CNCF 成立，並在近年形成了 cloud native 生態。

在這個過程中，雲的形態一直變化，可以看到：供應商提供的功能越來越多，而客戶或者說應用需要自己管理的功能越來越少。

架構也在一直適應雲端計算的變化

什麼是原生 Native

在回顧完雲端計算的歷史之後，我們對 Cloud 有更深的認識，接着繼續看一下：什麼是 Native？
字典的解釋是：與生俱來的。
那 Cloud 和 native 和在一起，又該如何理解？

這裏我們拋出一個我們自己的理解：雲原生代表着原生爲雲設計。詳細的解釋是：應用原生被設計爲在雲上以最佳方式執行，充分發揮雲的優勢。

這個理解有點空泛，但是考慮到雲原生的定義和特徵在這些年間不停的變化，以及完全可以預料到的在未來的必然變化，我覺得，對雲原生的理解似乎也只能回到雲原生的出發點，而不是如何具體實現。

Cloud Native 是道，Service Mesh 是術

那在這麼一個雲原生理解的背景下，我再來介紹一下我對雲原生應用的設想，也就是我覺得雲原生應用應該是什麼樣子。

在雲原生之前，底層平臺負責向上提供基本執行資源。而應用需要滿足業務需求和非業務需求，爲了更好的程式碼複用，通用型好的非業務需求的實現往往會以類庫和開發框架的方式提供，另外在 SOA/ 微服務時代部分功能會以後端服務的方式存在，這樣在應用中就被簡化爲對其用戶端的呼叫程式碼。

然後應用將這些功能，連同自身的業務實現程式碼，一起打包。

而雲的出現，可以在提供各種資源之外，還提供各種能力，從而幫助應用，使得應用可以專注於業務需求的實現。
非業務需求相關的功能都被移到雲，或者說基礎設施中去了，以及下沉到基礎設施的中介軟體。

以服務間通訊爲例：需要實現上面列舉的各種功能。

SDK 的思路：在應用層新增一個胖用戶端，在這個用戶端中實現各種功能。

Service Mesh 的思路，體現在將 SDK 用戶端的功能剝離出來，放到 Sidecar 中。就是把更多的事情下沉，下沉到基礎設施中。

在使用者看來，應用長這樣：

雲原生是我們的目標，Service Mesh 交出了自己的答卷，接下來我們可以回到 Service Mesh 這裏了。

Service Mesh

其中文譯名是服務網格，這個詞最早使用由開發Linkerd的Buoyant公司提出，並在內部使用。

定義

服務網格的基本構成

紛爭 2017

2017 年年底，當非侵入式的 Service Mesh 技術終於從萌芽到走向了成熟，當 Istio/Conduit 橫空出世，人們才驚覺：微服務並非只有侵入式一種玩法，更不是 Spring Cloud 的獨角戲！

解讀 2017 之 Service Mesh：羣雄逐鹿烽煙起

文章總結一下：
創業公司 Buoyant 的產品 Linkerd 開局拿下一血；
Envoy 默默耕耘；
從 Google 和 IBM 聯手推出 Istio，Linkerd 急轉直下；
2017 年底 Buoyant 推出 Conduit 背水一戰；
Nginmesh 與 Kong 低調參與；

百家爭鳴 2018

2018 年，Service Mesh 又多了哪些內容呢？在 2018 年，Service Mesh 在國內大熱，有多家公司推出自己的 Service Mesh 產品和方案，Service Mesh 更加熱鬧了。
詳細見這篇文章 下一代微服務！Service Mesh 2018 年度總結

文章總結一下：
Service Mesh 在國內大熱，有多家公司加入戰場；
Istio 發佈1.0，成爲最受歡迎的 Service Mesh 專案，獲得多方支援；
Envoy 繼續穩紮穩打，Envoy 被 Istio 直接採用爲數據平面，有望成爲數據平面標準；
Linkerd1.x 陷入困境，Conduit 小步快跑，但響應平平，Buoyant 公司決定合併產品線，Linkerd1.x + Conduit = Linkerd2.0；
更多的公司參與 Service Mesh，國外有 Nginx、Consul、Kong、AWS等，國內有螞蟻金服、新浪微博、華爲，阿裡 Dubbo，騰訊等；

持續發展 2019

2019 將會聽到更多 Service Mesh 的聲音，請關注Service Mesh 中文社羣

Istio

前文講到 Istio 是當前最受歡迎的 Service Mesh 框架，一句話定義 Istio：一個用來連線、管理和保護微服務的開放平臺。
它能給我們的微服務提供哪些功能呢？

連線

• 動態路由
• 超時重試
• 熔斷
• 故障注入

詳細見官網介紹

保護

安全問題一開始就要做好，在 Istio 實現安全通訊是非常方便的。

Istio 支援雙向 TLS 加密

見官方文件

控制

速率限制
黑白名單

見官方文件

觀測

• 指標度量：每秒請求數，Prometheus 與 Grafana
  使用 Grafana 觀測流量情況
  

• 分佈式追蹤：Jaeger 或 Zipkin
  快速觀測呼叫鏈路
  

• 日誌：非應用日誌

• 網格視覺化
  快速理清服務的關係
  

總結

虛擬化技術推動這雲端計算技術的變革，順帶也影響了後端架構的演進，目前我們身處雲時代，將會有更多的元原生應用出現，Istio 作爲其中的佼佼者，值得你投入一份精力瞭解一下。