雲原生思想
【導讀】雲原生是什麼？它是一個什麼概念、又應該如何藉助雲原生思想和能力讓業務跑得更快？本文做了詳細介紹。
雲原生 似乎已經是一個老生常談的概念了，相關的文章層出不窮。本人現在工作中負責雲原生服務管理平臺的研發（主要管理各類雲原生基礎設施，平臺服務和第三方託管應用），但即便如此，常被問起雲原生是什麼時，我也很難簡潔的向人表述清楚，導致自我也經常問一遍，雲原生究竟是什麼，我又在做什麼。
雲原生究竟是什麼
雲原生是一個組合詞，即 Cloud Native 。Pivotal （已被 VMware 收購）官網的 What is cloud native?[1] 一文中提到 ** 雲原生是一種構建和運行應用程序的方法，雲原生開發融合了 DevOps、持續交付、微服務和容器的概念在裏面。**CNCF （雲原生計算基金會）在 cncf/toc[2] 給出了雲原生 V1.0 的定義：
雲原生技術有利於各組織在公有云、私有云和混合雲等新型動態環境中，構建和運行可彈性擴展的應用。雲原生的代表技術包括容器、服務網格、微服務、不可變基礎設施和聲明式 API。這些技術能夠構建容錯性好、易於管理和便於觀察的松耦合系統。結合可靠的自動化手段，雲原生技術使工程師能夠輕鬆地對系統作出頻繁和可預測的重大變更。雲原生計算基金會（CNCF）致力於培育和維護一個廠商中立的開源生態系統，來推廣雲原生技術。我們通過將最前沿的模式民主化，讓這些創新爲大衆所用。
結合官方的定義，我個人對雲原生簡潔的理解就是：雲原生並不是某種具體技術，而是一類思想的集合，用來幫助快速構建和運行應用程序，其中既涵蓋着一整套技術體系（容器、服務網格、微服務、不可變基礎設施和聲明式 API），也包含着應用開發的管理要點（DevOps、持續交付、康威定律 [3]）。只要符合這類思想的應用就可以稱爲雲原生應用。
雲原生技術體系
雲原生的一整套技術體系其實是緊密聯繫的，這得從軟件架構的逐步演進說起。即 單體 -> 微服務 -> 基於 k8s 上的微服務 -> 服務網格單體架構，將所有的功能集成在一個工程裏，項目發展早期，應用的開發相對簡單，即使需要對應用進行大規模更改也很容易，測試、部署，包括橫向擴展都不是件難事，運行多個實例後，一個負載均衡器就可以搞定。隨着時間推移，一個成功的應用必然變得越來越臃腫，代碼庫隨之膨脹，團隊管理成本不斷提高，即俗話說的陷入單體地獄。面對單體地獄，開發者難以理解代碼全部，開發速度變緩慢，部署週期變長，而且橫向擴展也會遇到挑戰，因爲應用不同模塊對資源的需求是互相沖突的，有些可能需要的是更大內存，有些可能需要的是高性能 CPU，作爲單體應用，就必須都滿足這些需求。當出現一個問題，自然會有針對該問題的解決方案，雲原生技術體系之一的微服務架構就是針對單體地獄的解決方案。既然單體應用是將全部功能都集成在一個工程裏去編譯部署，那現在只要把各個功能拆分出來（通常是根據業務能力或者根據子域（子域圍繞 DDD 來組織服務）分解），將每個拆分的模塊作爲一個單獨的服務，獨立部署（服務之間通常通過 REST+JSON 或 gRPC+ProtoBuf 進行通信），這一個個的服務共同提供整個應用的功能不就好了嗎。但微服務也不是銀彈，引入微服務架構後，分佈式系統也帶來了各種複雜性，諸如配置中心，服務發現，網關，負載均衡等業務無關的基礎設施層面都需要開發者一一自行在業務層面實現。比如一個常見的微服務架構解決方案（圖源鳳凰架構 [4]），就需要開發者自行引入各種組件:
項目開發完成後終歸要到部署流程的，早期的傳統做法是把應用程序直接部署到服務器上，但服務器的系統、環境變量等是會不斷變化的，甚至安裝了新的應用，還會引起和其他應用的衝突，導致應用本身需要跟着用戶系統環境的改變而做出改變。爲了解決這個問題，不可變基礎設施的口號就喊響了。第一階段是將服務部署爲虛擬機，將作爲虛擬機鏡像打包的服務部署到生產環境中，每一個服務實例都是一個虛擬機。但大家都知道，虛擬機太笨重了，爲了減少開銷，第二階段，將服務部署爲容器，將作爲容器鏡像打包的服務部署到生產環境中，每一個服務實例都是一個容器。
不可變基礎設施：任何基礎設施的實例一旦創建之後變爲只讀狀態，如需要修改或升級，需要使用新的實例替換舊的。容器鏡像就是一種不可變基礎設施的具體實現。
現在容器已然成爲了微服務的好搭檔，服務實例隔離，資源也可以方便控制，但成千上百的容器，管理起來太麻煩了，於是，容器編排工具又出來了，Kubernetes 目前基本統一了容器編排的市場，實現了容器集羣的自動化部署、擴縮容和維護等功能。但 Kubernetes 可不只侷限於容器編排，還記得上文的微服務架構中需要開發者自行在應用層面解決業務無關的基礎設施層面的一系列問題嗎，現在 Kubernetes 就可以解決大部分問題，如圖（圖源鳳凰架構 [5]）：
Kubernetes 的編碼方式其實就是一種聲明式 API（指通過向工具描述自己想要讓事物達到的目標狀態，然後由這個工具自己內部去計算如何令這個事物達到目標狀態）。到這裏，我已經提到了雲原生技術體系中容器、服務網格、微服務、不可變基礎設施和聲明式 API 裏面的四種了。還剩下一個服務網格，緩口氣，繼續。其實你應該已經可以發現，一步步發展下來，都是爲了把 業務和基礎設施解耦 ，讓開發者可以快速開發自己的業務，無需關心底層基礎設施。服務網格也是想幹這事的，希望將更多業務無關的功能下沉到基礎設施，號稱微服務 2.0 。服務網格核心在於將客戶端 SDK 剝離，以 Proxy 組件方式獨立進程運行，每個服務都額外部署這個 Proxy 組件，所有出站入站的流量都通過該組件進行處理和轉發。這個組件被稱爲 Sidecar（邊車應用）。Sidecar 只負責網絡通信。還需要有個組件來統一管理所有 Sidecar 的配置。在服務網格中，負責配置管理的部分叫控制平面（control plane），負責網絡通信的部分叫數據平面（data plane）。數據平面和控制平面一起構成了服務網格的基本架構。
聽說再更進一步就是無服務（Serverless）了。
雲原生管理要點
DevOps（Development 和 Operations 的組合詞）是一組過程、方法與系統的統稱，用於促進開發（應用程序 / 軟件工程）、技術運營和質量保障（QA）部門之間的溝通、協作與整合。——百度百科 DevOps 的兩個核心理念是 CI（持續集成）和 CD（持續交付 / 部署）。本文對 DevOps 不做探討，推薦一個微軟的教程 [6] 可以去看看。
結尾
感謝閱讀到這裏，本文較爲粗糙的描述了雲原生作爲一種思想，其技術體系之間的聯繫，但可能有一些錯誤之處，如果你發現了，歡迎戳下方告知我！
參考資料
參考資料
[1]
What is cloud native?: https://tanzu.vmware.com/cloud-native
[2]
cncf/toc: https://github.com/cncf/toc/blob/main/DEFINITION.md
[3]
康威定律: https://zh.wikipedia.org/zh-my/%E5%BA%B7%E5%A8%81%E5%AE%9A%E5%BE%8B
[4]
鳳凰架構: http://icyfenix.cn/exploration/projects/microservice_arch_springcloud.html
[5]
鳳凰架構: http://icyfenix.cn/exploration/projects/microservice_arch_kubernetes.html
[6]
微軟的教程: https://azure.microsoft.com/zh-cn/overview/devops-tutorial/#understanding
Go 開發大全
參與維護一個非常全面的 Go 開源技術資源庫。日常分享 Go, 雲原生、k8s、Docker 和微服務方面的技術文章和行業動態。
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/JjykVNWp7NVFqaTy0rUdxg