目錄

云原生的代表技術

云原生的技術范疇包括了以下幾個方面：

1. 第一部分是云應用定義與開發流程，這包括應用定義與鏡像制作、配置 CI/CD、訊息和 Streaming 以及資料庫等，

2. 第二部分是云應用的編排與管理流程，這也是 Kubernetes 比較關注的一部分，包括了應用編排與調度、服務發現治理、遠程呼叫、API 網關以及 Service Mesh，

3. 第三部分是監控與可觀測性，這部分所強調的是云上應用如何進行監控、日志收集、Tracing 以及在云上如何實作破壞性測驗，也就是混沌工程的概念，

4. 第四部分就是云原生的底層技術，比如容器運行時、云原生存盤技術、云原生網路技術等，

5. 第五部分是云原生工具集，在前面的這些核心技術點之上，還有很多配套的生態或者周邊的工具需要使用，比如流程自動化與配置管理、容器鏡像倉庫、云原生安全技術以及云端密碼管理等，

6. 最后則是 Serverless，Serverless 是一種 PaaS 的特殊形態，它定義了一種更為 “極端抽象” 的應用撰寫方式，包含了 FaaS 和 BaaS 這樣的概念，而無論是 FaaS 還是 BaaS，其最為典型的特點就是按實際使用計費（Pay as you go），因此 Serverless 計費也是重要的知識和概念，

容器

容器提供行程級的隔離，可以將作業系統管理的資源劃分到相互隔離的組中，在相互隔離的組之間解決資源使用存在沖突的問題，

容器為 IT 歷史帶來的顯著影響莫過于：改變了代碼交付的方式，它包含了一個應用運行所需的完整環境（整個作業系統的檔案系統），具有一致性、輕量級、可移植、語言無關等特性，實作 “一次發布，隨處運行”（開發、測驗、生產），使應用的構建、分發和交付完全標準化，它也是 “不可變基礎設施” 的核心基礎，

基于容器的不可變基礎設施

不可變基礎設施，是相對于可變基礎設施而言的，

• 可變基礎設施：在傳統的可變服務器基礎架構中，物理服務器會不斷更新和修改，使用此類基礎架構的工程師和管理員需要通過 SSH 連接到他們的物理服務器，手動升級或降級軟體包，逐個服務器地調整組態檔，以及將新代碼直接部署到現有服務器上，所有說，這些服務器是可變的，它們可以在創建后進行更改，

• 不可變基礎架構：是另一種基礎架構范例，其中的物理服務器在部署后永遠不會被修改，程式設計中不可變變數（ImmutableVariable）就是在完成賦值后就不能發生更改，只能創建新的來整體替換舊的，由于具有這樣的特性這種變數可以在并發環境下安全的使用，對于基礎設施的不可變性，最基本的就是指運行服務的物理服務器在完成部署后，就不在進行更改，

不可變基礎架構的好處，包括：基礎架構中更高的一致性和可靠性，以及更簡單，更可預測的部署程序，它可以緩解或完全防止可變基礎架構中常見的問題，例如：配置漂移和雪花服務器，但是，有效地使用它通常包括全面的部署自動化，云計算環境中的快速服務器配置，以及處理狀態或短暫資料（如日志）的解決方案，

微服務

微服務需要從兩個方面去理解：“微” 和 “服務”，

對此，亞馬遜 CEO Bezos 給出了一個很好的詮釋：單個服務的實作，所有參與人從設計、開發、測驗、運維所有人加起來只需要 2 個披薩就夠了（2 pizza 定律），

所謂服務，一定要區別于系統，服務是一個或一組相對較小且獨立的功能單元，是用戶可以感知最小功能集，傳統的單體架構，以整個系統為單位進行部署，而微服務，則是以每一個獨立組件為單位進行部署，

可以使用 Martin Fowler 的這張圖來解釋，圖中左邊是單體架構的集群，右邊是微服務集群，

Kubernetes

有了容器，就需要編排管理容器的生命周期，Kubernetes 則是這方面的事實標準，Kubernetes 這個單詞來自于希臘語，含義是舵手或領航員，Kubernetes 并不是一件全新的發明，它是谷歌根據其內部使用的 Borg 改造成的一個通用容器編排調度器，于 2014 年 6 月開源，可以說，Kubernetes 是云計算和云原生時代的 Linux，

Kubernetes 采用宣告式的 API 與可擴展（CRD + Controller）的編程介面，先進的設計思想使其在容器編排大戰中（Kubernetes、Swarm、Mesos）處于王者地位，成為容器編排系統的事實標準，

Kubernetes 作為云應用的部署標準，直接面向業務應用，大大提高了云應用的可移植性，解決云廠商鎖定的問題，讓云應用可以在跨云之間無縫遷移，甚至用來管理混合云，成為企業 IT 云平臺的新標準，

通過采用 Kubernetes 平臺，用戶不必操心資源管理問題，使基礎設施更加標準化，復雜度降低，資源使用率提升，同時 Kubernetes 也簡化了混合云，多云，邊緣云等跨資料中心的部署成本，

宣告式 API

宣告式（Declarative）的編程方式一直都會被工程師們拿來與命令式（Imperative）進行對比，命令式編程：要求我們描述為了達到某一個效果或者目標所需要完成的指令，常見的編程語言：Go、Ruby、C++ 都是命令式的編程方法，

宣告式 API 和命令式 API 是兩種截然不同的編程方式：

• 命令式 API：我們可以直接發出服務器要執行的命令，例如：“運行容器”、“停止容器” 等，
• 宣告式 API：我們宣告系統要執行的操作，系統將不斷向該狀態驅動，

簡而言之，命令式編程是第一人稱，我要做什么，我要怎么做，是單純的被動執行；而宣告式編程則類似于 “第二人稱”，也就是：你要做什么，是一種主動向目前前進的執行方式，

基于 Kubernetes 的云應用編排理論

云應用編排理論，當前的實作方式就是 Google 所提出來的 “容器設計模式”，

服務網格（Service Mesh）

對許多公司來說，Docker 和 Kubernetes 這樣的工具已經解決了云原生應用部署的問題，但他們還沒有解決微服務運行時的問題，這就是服務網格（Service Mesh）的由來，

Service Mesh 一般用于微服務應用的可配置基礎架構層（Configurable infrastructure layer），以處理服務與服務之間通信，最早與 2016 年 9 月由 Buoyant 公司提出，而 Istio（由 Google、IBM、Lyft 支持）則是目前最廣為人知的一款服務網格架構，Kubernetes 是目前 Istio 唯一支持的容器組織框架，

Service Mesh 核心是業務邏輯與非業務邏輯解耦，實作開發只需關注業務邏輯的偉大目標，將一大堆和業務邏輯無關的客戶端 SDK，如：服務發現，路由，負載均衡，限流降級等從業務應用中剝離出來，放到單獨的 Proxy（Sidecar） 行程中，之后下沉到基礎設施中間件 Mesh（類似 TDDL 到 DRDS 的模式），針對應用減少了系統框架變更帶來的風險、瘦身后變的干凈和輕量化，加快了應用的啟動速度，使得應用往 Serverless 架構遷移變得輕松，針對 Mesh 可以根據自身需求自行迭代和升級功能，更加利于全域服務治理、灰度發布、監控等，同時，Mesh 邊界可以擴展到 DB Mesh，Cache Mesh、Msg Mesh等，真正做到服務通信的標準化即服務之間通信的 TCP/IP，

Service Mesh 的出現，彌補了 Kubernetes 在微服務的連接、管理和監控方面的短板，為 Kubernetes 提供更好的應用和服務管理，因此，Istio 一經推出，就被認為是可以和 Kubernetes 雙劍合璧的微服務管理的利器，而受到了業界的推崇，