雲原生五大技術

導讀	雲原生!它終於來了。毫無疑問，雲必將是未來數字世界最重要、也是最必不可少的基礎設施，每個程式設計師都應該要了解它，因為你的程式碼大概率會執行在雲上。

雲原生!它終於來了。毫無疑問，雲必將是未來數字世界最重要、也是最必不可少的基礎設施，每個程式設計師都應該要了解它，因為你的程式碼大概率會執行在雲上。接下來，我將以系列專題的形式從雲原生的關鍵技術、微服務間通訊方式、Serverless 架構等方面以淺顯易懂的語言來介紹雲領域的相關知識，目的只有一個：當有人再整概念的時候，不管是乾貨還是水貨，我們都能鑑別出來。

雲原生不是一項具體的技術，它是一種行為方式和設計理念。凡是能夠提高雲上資源利用率和應用交付效率的行為或方式都可以稱之為雲原生的。雲原生由一系列技術支撐起來的，代表技術包括容器、服務網格、微服務、不可變基礎設施和宣告式 API。

容器帶來的好處，不用多說，用過的都知道。容器使得應用服務能從底層架構中分離出來，實現了完全的可移植性(在任何作業系統或環境上執行應用的能力)，當應用程式有很多獨立元件構成，也可以為每個元件分配一個容器。

微服務是為了解決傳統單體應用的缺點而誕生的，它是一種分散式架構設計理念。它把應用程式中的具體功能獨立出來，抽象為『服務』。一個微服務就是一個獨立的實體，可以獨立的部署在 PAAS 平臺上，也可以作為一個獨立的程式在主機中執行。為了推動細粒度服務的使用，這些服務要能協同工作，每個服務都有自己的生命週期。服務之間可以通過閘道器 API、RPC(遠端服務呼叫)、SideCar(後續文章會介紹) 等多種方式訪問，修改一個服務不會影響其它服務。關於微服務，我之前的文章比較詳細地介紹過：從單體到微服務，論軟體系統如何逐步地進行解耦

服務網格(英文名：Service Mesh)是一個基礎設施層，用於處理服務間的通訊，雲原生應用有著複雜的服務拓撲，服務網格負責在這些拓撲中實現請求的可靠傳遞，在實踐中，服務網格通常實現為一組輕量級的網路代理，它們與應用程式部署在一起，但對應用程式透明。

SideCar 由控制面和資料面構成，典型代表是istio，其中控制面採用的是envoy

Service Mesh 並不是指一項具體的技術，它是應用了某種技術(比如 SideCar)後呈現的形態。服務網格利用容器之間的網路設定來控制或改變應用程式中不同元件之間的互動。

綠色表示純業務應用，藍色就是 SideCar

我們來看一個具體的例子：

假如你想測試 Nginx 的新版本，檢查它是否與你的 Web 應用相容。你用新的 Nginx 版本建立了一個新的容器 (Container2)，並從當前容器 (Container1) 中複製了當前的 Nginx webserver 配置。但你不想影響組成 web 應用的其他微服務(假設每個容器對應一個單獨的微服務)—— 就是 MySQL 資料庫、Node.js 前端、負載均衡器等。

所以使用服務網格，你可以立即只把 webserver 微服務改成 Container2(新 Nginx 版本的那個)進行測試。如果確定它不能工作，比如因為它導致網站出現一些相容性問題，那麼你就呼叫服務網格來快速切換回原來的 Container1。而這一切都不需要對其他容器進行任何配置變更 —— 這些變更對其他容器是完全透明的。

如果沒有服務網格，對容器來說這項工作將十分繁瑣，因為這涉及到逐一更改所有其他容器上的配置，將它們所包含的服務從 Container1 指向 Container2，然後在測試失敗後，將它們全部改回來。

K8s 中的不可變基礎設施就是 Pod，容器技術就是不可變基礎設施的一種具體實現。Chad Fowler 於 2013 年提出的一個很有前瞻性的構想：在這種模式中，任何基礎設施的例項(包括伺服器、容器等各種軟硬體)一旦建立之後便成為一種只讀狀態，不可對其進行任何更改。如果需要修改或升級某些例項，唯一的方式就是建立一批新的例項以替換。

所以，不可變基礎設施是一個自包含、自描述可以完全在不同環境中遷移的東西。

Declarative(宣告式設計)是相對 Imperative 或 Procedural(過程式設計)而言的。在 Declarative 中，我們描述的是目標狀態(Goal State)，而在 Imperative 模式中，我們描述的是一系列的動作。這一系列的動作如果被正確的順利執行，最終結果是這個事物達到了我們期望的目標狀態的。SQL 其實就是一種常見的宣告式『程式語言』，它能夠讓開發者自己去指定想要的資料是什麼。

我們來看下述兩條 ：

docker service create --name nginx --replicas 2 nginx 
docker service update --image nginx:1.7.9 nginx

用 Docker Swarm 啟動了兩個 Nginx 容器例項。其中，第一條 create  建立了這兩個容器，而第二條 update 命令則把它們『滾動更新』變成了一個新的映象。

那麼，像上面這樣的建立和更新兩個 Nginx 容器的操作，在 K8s 裡是怎麼做的呢?

首先，需要在本地編寫一個 Deployment 的 yaml 檔案：

apiVersion: apps/v1 
kind: Deployment 
metadata: 
name: nginx-deployment 
selector: 
matchLabels: 
app: nginx 
replicas: 2 
template: 
metadata: 
labels: 
app: nginx 
spec: 
containers: 
- name: nginx 
image: nginx 
ports: 
- container Port: 80

接下來，使用 kubectl apply 命令來建立這個 Deployment：

kubectl apply -f nginx.yaml

這樣，Nginx 的 Deployment 就被建立了出來。然後，再修改一下 nginx.yaml 裡定義的映象：

... 
spec: 
containers: 
- name: nginx 
image: nginx:1.7.9

在修改完這個 yaml 檔案之後，繼續執行如下 kubectl apply 命令：

kubectl apply -f nginx.yaml

這時，K8s 就會立即觸發這個 Deployment 的『滾動更新』。kubectl apply 相當於執行了一個對原有 API 物件的 PATCH 操作。總結下：

所謂『宣告式』，指的就是我只需要提交一個定義好的 API 物件來『宣告』我所期望的狀態是什麼樣子，具體該怎麼操作才能達到我想要的狀態由工具內部實現;

『宣告式』 API 允許有多個 API 寫端，以 PATCH 的方式對 API 物件進行修改，而無需關心本地原始 yaml 檔案的內容。

雲原生帶來的好處顯而易見：

1. 敏捷

1. 可靠

1. 高彈性

1. 易擴充套件

1. 故障隔離保護

1. 不中斷業務持續更新

它能提升研發效率、加速日常迭代、加速新技術落地應用、方便自動化測試、降低運維成本，同時，面向微服務設計和動態資源管理，能夠讓叢集資源得到最高效的利用。

原文來自：