作者：長淇

> 導讀
>
> 本文適合：
>
> 想了解 Serverless 灰度釋出的同學。
>
> 認為當前 Serverless 灰度釋出配置太複雜，尋求簡潔版灰度釋出流程的同學。
>
> 想了解 Serverless Devs 元件和外掛之間關係的同學。

## Serverless 灰度釋出

### 什麼是 Serverless ?

Serverless 顧名思義就是無伺服器，它是一種“來了就用，功能齊全，用完即走”的全新計算提供方式，使用者無需預製或管理伺服器即可執行程式碼，只需將程式碼從部署在伺服器上，轉換到部署到各廠商 Serverless 平臺上；同時享受 Serverless 按需付費，高彈性，低運維成本，事件驅動，降本提效等優勢。

### 什麼是 Serverless 灰度釋出？

灰度釋出又稱為金絲雀釋出( Canary Deployment )。過去，礦工們下礦井前，會先放一隻金絲雀到井內，如果金絲雀在礦井內沒有因缺氧、氣體中毒而死亡後，礦工們才會下井工作，可以說金絲雀保護了工人們的生命。

與此類似，在軟體開發過程中，也有一隻金絲雀，也就是灰度釋出（Gray release）：開發者會先將新開發的功能對部分使用者開放，當新功能在這部分使用者中能夠平穩執行並且反饋正面後，才會把新功能開放給所有使用者。金絲雀釋出就是從不釋出，然後逐漸過渡到正式釋出的一個過程。

那麼對於部署在 Serverless 平臺上的函式應該怎麼進行灰度釋出呢？

下文將以阿里雲函式計算 FC 為例，為各位展開介紹。

灰度釋出有一個流程，兩種方式。

### 一個流程

Serverless 灰度釋出是透過配置別名來實現的，別名可以配置灰度版本和主版本的流量比例，在呼叫函式時使用配置好的別名即可將流量按比例傳送到相應版本。

![1.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/b6d23f45830245aa8a9e66c9d6a26db0~tplv-k3u1fbpfcp-zoom-1.image "1.png")

配置灰度釋出的流程如下：

1.  Service 中釋出一個新版本。
1.  建立或更新別名，配置別名關聯新版本和穩定版本，新版本即為灰度版本。
1.  將觸發器 ( Trigger ) 關聯到別名。
1.  將自定義域名 ( Custom Domain ) 關聯到別名。
1.  在呼叫函式中使用別名，流量會按配置比例傳送到新版本和穩定版本。

### 傳統做法的兩種方式

1、阿里雲控制檯 web 介面：

a.釋出版本

![2.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/7c0122076cc7492a96a48b6e2f0c8d4b~tplv-k3u1fbpfcp-zoom-1.image "2.png")

b.建立別名

![3.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/4e32f8acf56d48e0b336780259e736cd~tplv-k3u1fbpfcp-zoom-1.image "3.png")

c.關聯觸發器

![4.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/36b391dee17145a3b5d2b584ba3a7855~tplv-k3u1fbpfcp-zoom-1.image "4.png")

d.關聯自定義域名

![5.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/4d4c98ef2724413a8d1a23fa0cf864c3~tplv-k3u1fbpfcp-zoom-1.image "5.png")

2、使用 Serverless Devs cli

a.釋出版本

```
s cli fc version publish --region cn-hangzhou --service-name fc-deploy-service --description "test publish version"
```

b.建立別名並設定灰度

```
s cli fc alias publish --region cn-hangzhou --service-name fc-deploy-service --alias-name pre --version-id 1 --gversion 3 --weight 20
```

c.關聯觸發器

需要到控制檯配置

d.關聯自定義域名

需要到控制檯配置可以看到，使用控制檯或 Serverless Devs 進行灰度釋出流程中的每一步，都需要使用者親自操作。並且由於配置繁多，極易出錯。除了這些弊端以外，客戶困擾的另一個問題是使用灰度釋出策略非常不方便。

常見的灰度釋出策略有 5 種：

1.  1.  **CanaryStep**: 灰度釋出，先灰度指定流量，間隔指定時間後再灰度剩餘流量。
    1.  **LinearStep**：分批發布，每批固定流量，間隔指定時間後再開始下一個批次。
    1.  **CanaryPlans**：自定義灰度批次，每批次設定灰度流量和間隔時間，間隔指定時間後按照設定的流量進行灰度。
    1.  **CanaryWeight**：手動灰度，直接對灰度版本設定對應的權重。
    1.  **FullWeight**: 全量釋出，全量釋出到某一版本。

這些灰度策略中，前三項都需要配置間隔時間，而使用者在控制檯或者使用 Serverless Devs 工具去配置灰度都沒有辦法透過自動程式來配置間隔時間，不得不透過鬧鐘等方式提醒使用者手動進行下一步灰度流程，這個體驗是非常不友好的。下面我們介紹個能夠幫您一鍵灰度釋出函式的外掛：FC-Canary 。

## 基於 Serverless Devs 外掛 FC-Canary 的灰度釋出

為了應對以上問題，基於 Serverless Devs 的外掛 FC-Canary 應運而生，該外掛可以幫助您透過 Serverless-Devs 工具和 FC 元件實現函式的灰度釋出能力，有效解決灰度釋出時引數配置繁雜、需要開發人員親自操作以及可用策略少等問題。

![6.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d31e9e3969f241e3b097cf8ef8abdb74~tplv-k3u1fbpfcp-zoom-1.image "6.png")

（內容配置及注意事項-部分截圖）

詳細流程請見：<https:>。

### FC-Canary 的優勢

#### 1、FC-Canary 支援超簡配置

使用者最短只需在 s.yaml 中增加 5 行程式碼程式碼即可開啟灰度釋出功能。

![7.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/03d217ab9c02479495da87b8b7515746~tplv-k3u1fbpfcp-zoom-1.image "7.png")

#### 2、FC-Canary 配置指引簡單清晰:

![8.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/0e688893d1cc45f9b11d4037a58d006e~tplv-k3u1fbpfcp-zoom-1.image "8.png")

#### 3、FC-Canary 支援多種灰度策略

-   灰度釋出，先灰度指定流量，間隔指定時間後再灰度剩餘流量。

此時流量變化為：20%流量到新版本，10 分鐘後 100%流量到新版本

![9.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d5952404d9994255993007c7c25e37ed~tplv-k3u1fbpfcp-zoom-1.image "9.png")

-   手動灰度，指定時直接將灰度版本設定對應的權重。

此時為 10%流量到新版本，90%到穩定版本

![10.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/5dca9f4a3cd24595ae3c7c6051c10bc7~tplv-k3u1fbpfcp-zoom-1.image "10.png")

-   自定義灰度，以陣列的方式配置灰度變化。

此時流量變化為：10%到新版本 -> (5 分鐘後) 30% 流量到新版本 -> (10 分鐘後) 100% 流量到新版本

![11.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/aba93700b3b846c29984341b1b095514~tplv-k3u1fbpfcp-zoom-1.image "11.png")

-   分批發布，不斷累加灰度比例直到 100%流量到新版本。

流量變化：40%到新版本 -> (10 分鐘後) 80%流量到新版本 -> (再 10 分鐘後) 100%流量到新版本

![12.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/1d3aea701a284b968b8bd5b2863d9c63~tplv-k3u1fbpfcp-zoom-1.image "12.png")

-   全量釋出，100%流量發到新版本

![13.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/5bb8c97dfd1a4bab9866d96ef70a9e4c~tplv-k3u1fbpfcp-zoom-1.image "13.png")

FC-Canary 外掛支援上述 5 種灰度策略，使用者選擇所需策略並進行簡單配置，即可體驗一鍵灰度釋出。

#### 4、FC-Canary 灰度階段提示清晰

![14.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f752eff80b9c4d6ba1d7b321754d6e8e~tplv-k3u1fbpfcp-zoom-1.image "14.png")

外掛對每一個里程碑都會以 log 的方式展現出來，給開發者足夠的信心。

#### 5、FC-Canary 支援釘釘群組機器人提醒

![15.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/7435cd515abd4c2b9faea310635fc8d8~tplv-k3u1fbpfcp-zoom-1.image "15.png")

配置釘釘機器人即可在群中收到相關提醒，例如：

![16.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/54cefc0859904a9fab31dd831f6dbbd9~tplv-k3u1fbpfcp-zoom-1.image "16.png")

## FC-Canary 最佳實踐

使用 FC-Canary 外掛灰度釋出 nodejs 12 的函式。

程式碼倉庫：

<https:>

### 初始化配置

-   **程式碼配置**

![17.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d3f7f88a892247b4bd228bf0b1afd268~tplv-k3u1fbpfcp-zoom-1.image "17.png")

-   **yaml 配置**

![18.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c1d67a71deb343528ee08a561c78de67~tplv-k3u1fbpfcp-zoom-1.image "18.png")

我們採用 canaryWeight 的灰度策略：灰度釋出後，50%的流量到新版本，50%的流量到舊版本。

### 進行第一次釋出

1.  執行釋出

在 terminal 中輸入: s deploy --use-local

2.  檢視結果

命令列輸出的 log 中可以看到：

![19.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/9184037e494141cca512fc2cb111814e~tplv-k3u1fbpfcp-zoom-1.image "19.png")

由於是第一次釋出，專案中不存在歷史版本，所以即使配置了灰度釋出策略 ，FC-Canary 外掛也會進行全量釋出，即流量都傳送到版本 1。

### 修改程式碼，第二次釋出

1.  在第二次釋出前，我們修改一下程式碼，讓程式碼丟擲錯誤。

![20.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/ebd3dfc43cee4d99bc29528604350ded~tplv-k3u1fbpfcp-zoom-1.image "20.png")

2.  執行釋出

在terminal中輸入: s deploy --use-local

3.  結果

命令列輸出 log 中可以看到：

![21.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/b54d1eb95f954a019fb235522dcecd76~tplv-k3u1fbpfcp-zoom-1.image "21.png")

第二次釋出，應用了灰度釋出策略，即  50%流量傳送到版本 1, 50%的流量傳送到版本 2。

### 測試

獲取 log 中輸出的 domain，訪問 domain 100 次後檢視控制檯監控大盤。

![22.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/0789b07f902d4671b61f46a46f78c8a1~tplv-k3u1fbpfcp-zoom-1.image "22.png")

可以看到呼叫了函式 100 次，錯誤的函式有 49 次，正確的函式有 100 - 49 = 51 次，正確和錯誤的函式都約佔總呼叫數的 50%。

分析：函式版本 1 為正確函式，函式版本 2 為錯誤函式，我們的灰度配置為流量 50% 到版本 1，50% 到版本 2，所以呼叫過程中，錯誤函式和正確函式應該各佔 50%，圖中結果符合我們的假設，這證明我們的灰度策略是成功的。

## 總結

我們可以發現相比使用控制檯進行灰度釋出，使用 FC-Canary 外掛免去了使用者手動建立版本、釋出別名、關聯觸發器和管理自定義域名的麻煩，使用起來非常方便。

## 引申閱讀

### Serverless Devs 元件和外掛的關係

-   **元件是什麼？**

> 根據 Serverless Devs Model v0.0.1 中說明， 元件 Component: 是由 Package developer 開發併發布的符合 Serverless Package Model 規範的一段程式碼，通常這段程式碼會在應用中被引用，並在 Serverless Devs 開發者工具中被載入，並按照預定的規則進行執行某些動作。例如，將使用者的程式碼部署到 Serverless 平臺；將 Serverless 應用進行構建和打包；對 Serverless 應用進行除錯等。

舉個例子：

如果想要使用 Serverless Devs 管理阿里雲函式計算的函式計算資源，則需要在 yaml 配置檔案中宣告阿里雲 FC 元件，之後便可以使用阿里雲 FC 元件的能力。

> FC 元件可以提供管理阿里雲函式計算資源的能力，包括：管理服務、函式、版本、別名 等功能。元件地址：<https:>

-   **外掛是什麼？**

> 外掛作為元件的補充，提供元件的原子性功能。

舉個例子：

1.  使用 FC 元件 deploy 的功能部署函式，可以在部署結束後採用 FC-Canary 外掛對部署的函式進行灰度釋出。
1.  使用 FC 元件 deploy 的功能部署函式，可以在部署開始前採用 layer-fc 外掛來降低部署過程中上傳程式碼的耗時：即 layer-fc 可以讓函式直接使用公共依賴庫（遠端）中的依賴，從而在部署時不再需要上傳這些遠端存在的依賴。

-   **元件和外掛的關係？**

![23.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/684fbcb6223b4eadbe9e1ad89b532bff~tplv-k3u1fbpfcp-zoom-1.image "23.png")

-   在 Serverless Devs Model 中，元件是佔據核心地位，外掛是輔助地位，也就是說，外掛的目的是提升元件能力，提供給元件一些可選的原子性功能。

-   Serverless Devs 管理元件和外掛的生命週期，如果是 pre 外掛，則會讓其在元件執行前執行，反之，post 外掛則會在元件後完成一些收尾工作。

-   一個元件可以同時使用多個外掛, 其中元件外掛的執行順序是：

1.  1.  外掛按照 yaml 順序執行， 前一個外掛的執行結果為後一個外掛的入參
    1.  最後一個 pre 外掛的輸出作為元件的入參
    1.  元件的輸出作為第一個 post 外掛的入參

### 相關概念

-   FC 函式 (Function) 是系統排程和執行的單位，由函式程式碼和函式配置構成。FC 函式必須從屬於服務，同一個服務下的所有函式共享一些相同的設定，例如服務授權、日誌配置。函式的相關操作，請參見 管理函式。函式計算支援事件函式和 HTTP 函式兩種函式型別，關於二者的區別，請參見 函式型別。

-   服務 (Service) 可以和微服務對標 ( 有版本和別名 )，多個函式可以共同組成服務單元。建立函式前必須先建立服務，同一個服務下的所有函式共享一些相同的設定，例如服務授權、日誌配置。

-   觸發器 (Trigger) 的作用是觸發函式執行的。函式計算提供了一種事件驅動的計算模型。函式的執行可以透過函式計算控制檯或 SDK 觸發，也可以由其他一些事件源來觸發。您可以在指定函式中建立觸發器，該觸發器描述了一組規則，當某個事件滿足這些規則，事件源就會觸發關聯的函式。

-   自定義域名(Custom Domain) 是函式計算提供為 Web 應用繫結域名的能力。

-   版本 (Version) 是服務的快照，包括服務的配置、服務內的函式程式碼及函式配置，不包括觸發器，當釋出版本時，函式計算會為服務生成快照，並自動分配一個版本號與其關聯，以供後續使用。

-   別名 (Alias) 結合版本，幫助函式計算實現軟體開發生命週期中的持續整合和釋出。

最後，歡迎大家一起來貢獻更多的開源外掛！

***參考連結：***

**Serverless Devs：**

**<https:></https:>**

**FC 元件地址：**

**<https:>**

**FC-Canary 外掛具體資訊及其使用請參考：**

**<https:>**

**FC 函式管理：**

**<https:>**

**FC 函式型別：**

**<https:>**</https:></https:></https:></https:></https:></https:></https:>

如何用一個外掛解決 Serverless 灰度釋出難題？

相關文章