雲原生思想 — 關鍵技術

目錄

文章目錄

• 目錄
• 雲原生的表明技術
• 容器
• 基於容器的不可變基礎設施
• 微服務
• Kubernetes
• 聲明式 API
• 基於 Kubernetes 的雲應用編排理論
• 服務網格（Service Mesh）

雲原生的表明技術

雲原生的技術範疇包括瞭如下幾個方面：

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 雙劍合璧的微服務管理的利器，而受到了業界的推崇。