目錄
雲原生的代表技術
雲原生的技術範疇包括了以下幾個方面：
-
第一部分是雲應用定義與開發流程。這包括應用定義與鏡像製作、配置 CI/CD、消息和 Streaming 以及數據庫等。
-
第二部分是雲應用的編排與管理流程。這也是 Kubernetes 比較關注的一部分，包括了應用編排與調度、服務發現治理、遠程調用、API 網關以及 Service Mesh。
-
第三部分是監控與可觀測性。這部分所強調的是雲上應用如何進行監控、日誌收集、Tracing 以及在雲上如何實現破壞性測試，也就是混沌工程的概念。
-
第四部分就是雲原生的底層技術，比如容器運行時、雲原生存儲技術、雲原生網絡技術等。
-
第五部分是雲原生工具集，在前面的這些核心技術點之上，還有很多配套的生態或者周邊的工具需要使用，比如流程自動化與配置管理、容器鏡像倉庫、雲原生安全技術以及雲端密碼管理等。
-
最後則是 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 雙劍合璧的微服務管理的利器，而受到了業界的推崇。
