自 2013 年容器（虛擬）技術（Docker）成熟后，后端的架構方式進入快速迭代的階段，出現(xiàn)了很多新興概念：
微服務
k8s
Serverless
IaaS：基礎設施服務，Infrastructure-as-a-service
PaaS：平臺服務，Platform-as-a-service
SaaS：軟件服務，Software-as-a-service
Cloud Native：云原生
Service Mesh
后端架構的變遷和云計算的發(fā)展密切相關，架構其實在不斷地適應云計算，特別是云原生，被譽為未來架構，在 2019 年，云原生落地方案 Service Mesh 在國內外全面開花，我認為，未來已來。
接下來，我們將：
梳理后端架構演化史，回顧后端架構發(fā)展歷程；
回顧云服務發(fā)展歷程，探討云原生概念；
梳理云原生實現(xiàn)方案 Service Mesh 的發(fā)展歷程；
介紹 Service Mesh 的代表 Istio 的亮眼功能；
集中式架構又叫單體式架構，在Web2.0模式并未大規(guī)模興起時十分流行。后來，基于Web應用的B/S（Browser/Server）架構逐漸取代了基于桌面應用的C/S（Client/Server）架構。B/S架構的后端系統(tǒng)大都采用集中式架構，它當時以優(yōu)雅的分層設計，統(tǒng)一了服務器后端的開發(fā)領域。
集中式應用分為標準的3層架構模型：數(shù)據(jù)訪問層M、服務層V和邏輯控制層C。每個層之間既可以共享領域模型對象，也可以進行更加細致的拆分。
其缺點是
編譯時間過長;
回歸測試周期過長;
開發(fā)效率降低等；
不利于更新技術框架
對于互聯(lián)網(wǎng)應用規(guī)模的迅速增長，集中式架構并無法做到無限制的提升系統(tǒng)的吞吐量，而分布式系統(tǒng)架構在理論上為吞吐量的上升提供了無限擴展的可能。因此，用于搭建互聯(lián)網(wǎng)應用的服務器也漸漸地放棄了昂貴的小型機，轉而采用大量的廉價PC服務器。
分布式架構的概念很早就出現(xiàn)，阻礙其落地的最大問題是容器技術不成熟，應用程序在云平臺運行，仍然需要為不同的開發(fā)語言安裝相應的運行時環(huán)境。雖然自動化運維工具可以降低環(huán)境搭建的復雜度，但仍然不能從根本上解決環(huán)境的問題。
Docker的出現(xiàn)成為了軟件開發(fā)行業(yè)新的分水嶺；容器技術的成熟，也標志技術新紀元的開啟。Docker讓開發(fā)工程師可以將他們的應用和依賴封裝到一個可移植的容器中。就像當年智能手機的出現(xiàn)改變了整個手機行業(yè)的游戲規(guī)則一樣，Docker也大有席卷整個軟件行業(yè)，并且進而改變行業(yè)游戲規(guī)則的趨勢。通過集裝箱式的封裝，開發(fā)和運維都以標準化的方式發(fā)布的應用，異構語言不再是桎梏團隊的枷鎖。
在 Docker 之后，微服務得以流行開來
微服務架構風格是一種將一個單一應用程序開發(fā)為一組小型服務的方法，每個服務運行在自己的進程中，服務間通信采用輕量級通信機制(通常用HTTP資源API)。這些服務圍繞業(yè)務能力構建并且可通過全自動部署機制獨立部署。這些服務共用一個最小型的集中式的管理，服務可用不同的語言開發(fā)，使用不同的數(shù)據(jù)存儲技術。
微服務優(yōu)勢
可擴展
可升級
易維護
故障和資源的隔離
微服務的問題
但是，世界上沒有完美無缺的事物，微服務也是一樣。著名軟件大師，被認為是十大軟件架構師之一的 Chris Richardson 曾一針見血地指出：“微服務應用是分布式系統(tǒng)，由此會帶來固有的復雜性。開發(fā)者需要在 RPC 或者消息傳遞之間選擇并完成進程間通訊機制。此外，他們必須寫代碼來處理消息傳遞中速度過慢或者不可用等局部失效問題。”
在微服務架構中，一般要處理以下幾類問題：
服務治理：彈性伸縮，故障隔離
流量控制：路由，熔斷，限速
應用觀測：指標度量、鏈式追蹤
解決方案 Spring Cloud（Netflix OSS）
這是一個典型的微服務架構圖
Spring Cloud 體系提供了服務發(fā)現(xiàn)、負載均衡、失效轉移、動態(tài)擴容、數(shù)據(jù)分片、調用鏈路監(jiān)控等分布式系統(tǒng)的核心功能，一度成為微服務的最佳實踐。
Spring Cloud 的問題
如果開始構建微服務的方法，肯定容易被 Netflix OSS/Java/Spring/SpringCloud 所吸引。但是要知道你不是Netflix，也不需要直接使用 AWS EC2，使得應用程序變得很復雜。如今使用 docker 和采用 memos/kubernetes 是明智之舉，它們已經(jīng)具備大量的分布式系統(tǒng)特性。在應用層進行分層，是因為 netflix 5年前面臨的問題，而不得不這樣做（可以說如果那時有了kubernetes，netflix OSS棧會大不相同）。
因此，建議謹慎選擇，按需選擇，避免給應用程序帶來不必要的復雜度。
的確 SpringCloud 方案看起來很美好，但是它具有非常強的侵入性，應用代碼中會包含大量的 SpringCloud 模塊，而且對其他編程語言也不友好。
Kubernetes 出現(xiàn)就是為了解決 SpringCloud 的問題，不侵入應用層，在容器層解決問題。
Kubernetes 起源
Kubernetes最初源于谷歌內部的Borg，提供了面向應用的容器集群部署和管理系統(tǒng)。
Kubernetes的目標旨在消除編排物理/虛擬計算，網(wǎng)絡和存儲基礎設施的負擔，并使應用程序運營商和開發(fā)人員完全將重點放在以容器為中心的原語上進行自助運營。
Kubernetes 也提供穩(wěn)定、兼容的基礎（平臺），用于構建定制化的 workflows 和更高級的自動化任務。Kubernetes 具備完善的集群管理能力，包括多層次的安全防護和準入機制、多租戶應用支撐能力、透明的服務注冊和服務發(fā)現(xiàn)機制、內建負載均衡器、故障發(fā)現(xiàn)和自我修復能力、服務滾動升級和在線擴容、可擴展的資源自動調度機制、多粒度的資源配額管理能力。
Kubernetes 還提供完善的管理工具，涵蓋開發(fā)、部署測試、運維監(jiān)控等各個環(huán)節(jié)。
Service Mesh 是對 Kubernetes 的增強，提供了更多的能力。
2018年9月1日，Bilgin Ibryam 在 InfoQ 發(fā)表了一篇文章 Microservices in a Post-Kubernetes Era，中文版見后 Kubernetes 時代的微服務（譯文有些錯誤，僅供參考）。
文中作者的觀點是：在后 Kubernetes 時代，服務網(wǎng)格（Service Mesh）技術已完全取代了使用軟件庫實現(xiàn)網(wǎng)絡運維（例如 Hystrix 斷路器）的方式。
如果說 Kubernetes 對 Spring Cloud 開了第一槍，那么 Service Mesh 就是 Spring Cloud 的終結者。
最后我們用一個流程圖來描述后端架構的發(fā)展歷程
每個關鍵節(jié)點的大概時間表
| 架構/技術 | 時間/年份 |
|---|---|
| 集中式架構 | ~ |
| 分布式架構 | ~ |
| Docker | 2013 |
| 微服務 | 2014 |
| Spring Cloud | 2014 |
| Kubernetes 成熟 | 2017 |
| Service Mesh | 2017 |
可以看出，微服務生態(tài)這里，Spring Cloud 為代表的這條路已經(jīng)后繼無人了，未來屬于 Service Mesh 。
Service Mesh 經(jīng)過2年的發(fā)展，目前 Service Mesh 已經(jīng)足夠成熟，已經(jīng)有生產(chǎn)落地的案例，我們接下來就看看 Service Mesh，在此之前，我們要先理解一個概念，云原生。
如何理解“云原生”？之所以將這個話題放在前面，是因為，這是對云原生概念的最基本的理解，而這會直接影響到后續(xù)的所有認知。
注意：以下云原生的內容將全部引用敖小劍的 暢談云原生（上）：云原生應用應該是什么樣子？ 這篇文章，圖畫得太好了。
云原生的定義一直在發(fā)展，每個人對云原生的理解都可能不同，就如莎士比亞所說：一千個人眼中有一千個哈姆雷特。
2018 年 CNCF (Cloud Native Computing Foundation)更新了云原生的定義。
那我們該如何理解云原生呢？我們嘗試一下，將 Cloud Native 這個詞匯拆開來理解，先看看什么是 Cloud。
快速回顧一下云計算的歷史，來幫助我們對云有個更感性的認識。
云計算的出現(xiàn)和虛擬化技術的發(fā)展和成熟密切相關，2000 年前后 x86 的虛擬機技術成熟后，云計算逐漸發(fā)展起來。
基于虛擬機技術，陸續(xù)出現(xiàn)了 IaaS/PaaS/FaaS 等形態(tài)，以及他們的開源版本。
2013 年 docker 出現(xiàn)，容器技術成熟，然后圍繞容器編排一場大戰(zhàn)，最后在 2017 年底，kubernetes 勝出。2015 年 CNCF 成立，并在近年形成了 cloud native 生態(tài)。
在這個過程中，云的形態(tài)一直變化，可以看到：供應商提供的功能越來越多，而客戶或者說應用需要自己管理的功能越來越少。
在回顧完云計算的歷史之后，我們對 Cloud 有更深的認識，接著繼續(xù)看一下：什么是 Native？
字典的解釋是：與生俱來的。
那 Cloud 和 native 和在一起，又該如何理解？
這里我們拋出一個我們自己的理解：云原生代表著原生為云設計。詳細的解釋是：應用原生被設計為在云上以最佳方式運行，充分發(fā)揮云的優(yōu)勢。
這個理解有點空泛，但是考慮到云原生的定義和特征在這些年間不停的變化，以及完全可以預料到的在未來的必然變化，我覺得，對云原生的理解似乎也只能回到云原生的出發(fā)點，而不是如何具體實現(xiàn)。
那在這么一個云原生理解的背景下，我再來介紹一下我對云原生應用的設想，也就是我覺得云原生應用應該是什么樣子。
在云原生之前，底層平臺負責向上提供基本運行資源。而應用需要滿足業(yè)務需求和非業(yè)務需求，為了更好的代碼復用，通用型好的非業(yè)務需求的實現(xiàn)往往會以類庫和開發(fā)框架的方式提供，另外在 SOA/ 微服務時代部分功能會以后端服務的方式存在，這樣在應用中就被簡化為對其客戶端的調用代碼。
然后應用將這些功能，連同自身的業(yè)務實現(xiàn)代碼，一起打包。
而云的出現(xiàn)，可以在提供各種資源之外，還提供各種能力，從而幫助應用，使得應用可以專注于業(yè)務需求的實現(xiàn)。
非業(yè)務需求相關的功能都被移到云，或者說基礎設施中去了，以及下沉到基礎設施的中間件。
以服務間通訊為例：需要實現(xiàn)上面列舉的各種功能。
SDK 的思路：在應用層添加一個胖客戶端，在這個客戶端中實現(xiàn)各種功能。
Service Mesh 的思路，體現(xiàn)在將 SDK 客戶端的功能剝離出來，放到 Sidecar 中。就是把更多的事情下沉，下沉到基礎設施中。
在用戶看來，應用長這樣：
云原生是我們的目標，Service Mesh 交出了自己的答卷，接下來我們可以回到 Service Mesh 這里了。
其中文譯名是服務網(wǎng)格，這個詞最早使用由開發(fā)Linkerd的Buoyant公司提出，并在內部使用。
定義
服務網(wǎng)格的基本構成
2017 年年底，當非侵入式的 Service Mesh 技術終于從萌芽到走向了成熟，當 Istio/Conduit 橫空出世，人們才驚覺：微服務并非只有侵入式一種玩法，更不是 Spring Cloud 的獨角戲！
解讀 2017 之 Service Mesh：群雄逐鹿烽煙起
文章總結一下：
創(chuàng)業(yè)公司 Buoyant 的產(chǎn)品 Linkerd 開局拿下一血；
Envoy 默默耕耘；
從 Google 和 IBM 聯(lián)手推出 Istio，Linkerd 急轉直下；
2017 年底 Buoyant 推出 Conduit 背水一戰(zhàn)；
Nginmesh 與 Kong 低調參與；
2018 年，Service Mesh 又多了哪些內容呢？在 2018 年，Service Mesh 在國內大熱，有多家公司推出自己的 Service Mesh 產(chǎn)品和方案，Service Mesh 更加熱鬧了。
詳細見這篇文章 下一代微服務！Service Mesh 2018 年度總結
文章總結一下：
Service Mesh 在國內大熱，有多家公司加入戰(zhàn)場；
Istio 發(fā)布1.0，成為最受歡迎的 Service Mesh 項目，獲得多方支持；
Envoy 繼續(xù)穩(wěn)扎穩(wěn)打，Envoy 被 Istio 直接采用為數(shù)據(jù)平面，有望成為數(shù)據(jù)平面標準；
Linkerd1.x 陷入困境，Conduit 小步快跑，但響應平平，Buoyant 公司決定合并產(chǎn)品線，Linkerd1.x + Conduit = Linkerd2.0；
更多的公司參與 Service Mesh，國外有 Nginx、Consul、Kong、AWS等，國內有螞蟻金服、新浪微博、華為，阿里 Dubbo，騰訊等；
聯(lián)系客服
