將來已來：雲原生（一）

前言

自 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
Server Mesh	2017

Server Mesh 通過2年的發展，目前 Server Mesh 已經足夠成熟，已經有生產落地的案例，咱們接下來就看看 Server 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以及Service Mesh，敬請期待。

參考資料

kubernetes-handbook
istio-handbook
微服務學習筆記
暢談雲原生（上）：雲原生應用應該是什麼樣子？