未來已來：云原生 Cloud Native

作者: 天如發布時間: 2019-10-13 21:03 閱讀: 1603 次推薦: 16 原文鏈接 [收藏]

前言

自 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，騰訊等；