自容器推出以來，它給軟件開發帶來了極具傳染性的振奮和創新，并獲得了來自各個行業、各個領域的巨大的支持——從大企業到初創公司，從研發到各類 IT 人員等等。

知名跨境電商平臺小紅書隨著業務的鋪開，線上部署單元的數量急劇增加，以 Jenkins 調用腳本進行文件推送的部署模式已經不能適應需求。

[[207473]]

本文介紹小紅書如何以最小的投入，最低的開發量快速的實現容器化鏡像部署，以及由此帶來的收益。

[[207474]]

圖 1

小紅書是一個從社區做起來的跨境電商，目前已經有 5 千萬的用戶，電商平臺的 SKU 已經上到了十萬級。用戶喜歡在我們的平臺上發布關于生活、健身、購物體驗、旅游等相關帖子，每日有 1 億次筆記曝光。

我們從社區里的用戶創建的筆記生成相關的標簽，關聯相關商品，同時在商品頁面也展示社區內的和這商品有關的用戶筆記。

小紅目前還處在創業階段，我們的技術團隊規模還不大，當然運維本身也是一個小團隊，團隊雖小，運維有關的技術方面卻都得涉及。

小公司資源有限，一個是人力資源有限，二是我們很多業務往前趕。在如何做好 CI/CD，怎么務實的落地方面，我們的策略就是開源優先，優先選擇開源的產品，在開源的基礎上，發現不滿足需求的地方再自行開發。

小紅書應用上線流程

圖 2

如圖 2 是之前應用上線的過程，開發向運維提需求，需要多少臺服務器，運維依據需求去做初始化并交付給開發。

我們現在有一個運維平臺，所有服務器的部署都是由這個平臺來完成，平臺調用騰訊云 API 生成服務器，做環境初始化，配置監控和報警，最后交付給開發的是一個標準化好的服務器。

圖 3

開發者拿到服務器準備線上發布時，采用 Jenkins 觸發腳本的方式：用 Jenkins 的腳本做測試，執行代碼推送。

當需要新加一臺服務器或者下線一臺服務器，要去修改這個發布腳本。發布流程大概是：Jenkins 腳本先往 Beta 環境發布，開發者在 Beta 環境里做自測，自測環境沒有問題就全量發布。

我們遇到不少的情況都是在開發者自測的時候沒有問題，然后在線上發，線上都是全量發，結果就掛了。

回退的時候，怎么做呢?只能整個流程跑一遍，開發者回退老代碼，再跑一次 Jenkins 腳本，整個過程最長需要 10 來分鐘，這段過程線上故障一直存在，所以這個效率很低。

以上的做法其實是大多數公司的現狀，但是對于我們已經不太能適應了，目前我們整個技術在做更迭，環境的復雜度越來越高。

如果還是維持現有的代碼上線模式，顯然會有失控的風險，而且基于這樣的基礎架構做例如自動容量管理等，都是很難做到的。

技術團隊的問題與需求

首先，我們整個技術團隊人數在增加，再加上技術棧在變。以前都是純 Python 的技術環境，現在不同的團隊在嘗試 Java、Go、Node。

還有就是我們在做微服務的改造，以前的單體應用正在加速拆分成各個微服務，所以應用的數量也增加很多。

拆分微服務后，團隊也變得更細分了，同時我們還在做前后端的拆分，原來很多 APP 的頁面是后端渲染的，現在在做前后端的拆分，后端程序是 API，前端是展示頁面，各種應用的依賴關系也變得越來越多。

再加上電商每年大促銷，擴容在現有模式也很耗時耗力。所以現在的模式已經很難持續下去。

我們團隊在兩三個月以前就思考怎么解決這些問題，怎么把線上環境和代碼發布做得更好一點。我們需要做如下幾點：

• 重構“從代碼到上線”的流程。
• 支持 Canary 發布的策略，實現流量的細顆粒度管理。
• 能快速回退。
• 實踐自動化測試，要有一個環境讓自動化測試可以跑。
• 要求服務器等資源管理透明化，不要讓開發者關心應用跑在哪個服務器上，這對開發者沒有意義，他只要關心開發就可以了。
• 要能夠方便的擴容、縮容。

快速實現容器化鏡像部署的方法

我們一開始就考慮到容器化，就是用 Kubernetes 的框架做容器化的管理。

為什么是容器化?因為容器和微服務是一對“好朋友”，從開發環境到線上環境可以做到基本一致。

為什么用 Kubernetes?這和運行環境和部署環境有關系，我們是騰訊云的重度用戶，騰訊云又對 Kubernetes 提供了非常到位的原生支持。

所謂原生支持是指它有如下幾個方面的實現：

• 網絡層面，Kubernetes 在裸金屬的環境下，要實現 Overlay 網絡，或者有 SDN 網絡的環境，而在騰訊云的環境里。它本身就是軟件定義網絡，在網絡上的實現可以做到在容器環境里和原生的網絡一樣的快，沒有任何的性能犧牲。
• 在騰訊云的環境里，負載均衡器和 Kubernetes 里的 service 可以捆綁，可以通過創建 Kubernetes 的 service 去維護云服務的 L4 負載均衡器。
• 騰訊云的網盤可以被 Kubernetes 管理，實現 PVC 等，當然 Kubernetes 本身提供的特性是足夠滿足我們的需求的。

圖 4

我們作為創業公司都是以開源為主，在新的環境里應用了這樣的一些開源技術(圖 4)，Jenkins、GitLab、Prometheus 和 Spinnaker。Jenkins 和 GitLab 大家應該都聽說過，并且都在用，Prometheus、Docker 也都是目前很主流的開源產品。

這里重點介紹兩個比較新，現在相當火的開源技術：

• Spinnaker，這是一個我個人認為非常優秀的開源的發布系統，它是由 Netflix 在去年開源的，是基于 Netflix 內部一直在使用的發布系統做的開源，可以說是 Netflix 在 CD 方面的最佳實踐，整個社區非常活躍，它對 Kubernetes 的環境支持非常好。
• Traefik，在我們的環境里用來取代 Nginx 反向代理，Traefik 是用 Go 寫的一個反向代理服務軟件。

01.Spinnaker

Spinnaker有如下幾個特點：

Netflix 的開源項目。Netflix 的開源項目在社區一直有著不錯的口碑。

有開放性和集成能力。它原生就可以支持 Jenkins、GitLab 的整合，它還支持 Webhook，就是說在某一個環境里，如果后面的某個資源的控制組件，本身是個 API，那它就很容易整合到 Spinnaker 里。

擁有較強的 Pipeline 表達能力。它的 Pipeline 可以復雜到非常復雜，Pipeline 之間還可以關聯。

有強大的表達式功能。可以在任何的環節里用表達式來替代靜態參數和值，在 Pipeline 開始的時候，生成的過程變量都可以被 Pipeline 的每個 stage 調用。

比如說這個 Pipeline 是什么時候開始的，觸發時的參數是什么，某一個步驟是成功還是失敗了，此次要部署的鏡像是什么，線上目前是什么版本，這些都可以通過變量訪問到。

界面友好，支持多種云平臺。目前支持 Kubernetes、OpenStack、亞馬遜的容器云平臺。

 

圖 5

圖 5 是 Spinnaker 的架構，它是一個微服務的架構，里面包含用戶界面 Deck，API 網關 Gate 等。

API 網關是可以對外開放的，我們可以利用它和其他工具做一些深度整合。Rosco 是它做鏡像構建的組件，我們也可以不用 Rosco 來做鏡像構建。Orca 是它的核心，就是流程引擎。

Echo 是通知系統，Igor 是用來集成 Jenkins 等 CI 系統的一個組件。Front52 是存儲管理，Cloud driver 是它用來適配不同的云平臺的，比如 Kubernetes 就有專門的 Cloud driver，也有亞馬遜容器云的 Cloud driver。Fiat 是它一個鑒權的組件。

圖 6

圖 6 是 Spinnaker 的界面，界面一眼看上去挺亂，實際上它還是有很好的邏輯性。

這里每一個塊都有三種顏色來表示 Kubernetes 環境里的某個實例的當前狀態。綠色代表是活著的實例，右邊是實例的信息，包括實例的 YML 配置，實例所在的集群，實例的狀態和相關 event。

圖 7

圖 7 是 Pipeline 的界面。首先，我覺得這個界面很好看很清晰。二是 Pipeline 可以做得非常靈活，可以在執行了前幾個步驟之后，等所有的步驟執行完了再執行某個步驟。

這個步驟是某個用戶做某個審批，再分別執行三個步驟其中的一個步驟，然后再執行某個環節。也可以發布還是回退，發布是走發布的流程，回退就是回退的流程。

總之在這里，你所期待的 Pipeline 的功能都可以提供，如果實在不行，還有 Webhook 的模式讓你方便和外部系統做整合。

圖 8

圖 8 是 Pipeline 步驟的類型。左上 Check Precondltions 前置條件滿足的時候才執行某個步驟。

例如當前面的第一次發布里所有的實例都存活的時候，才執行某個步驟。或者當前面的步驟達到了某個狀態，再執行下一個步驟。

Deploy 是在 Kubernetes 環境里生成的 Replication Set，可以在 Deploy 里更新一個服務器組、禁用一個集群、把集群的容量往下降、往上升等等。

也可以跑某一個腳本，這個腳本是在某一個容器里，有時候可能有這樣的需求，比如說 Java，這個 Java 跑起來之后并不是馬上能夠接入流量，可能要到 Java 里跑一個 job，從數據庫加載數據并做些初始化工作后，才開始承接流量。

圖 9

Pipeline 表達式很厲害，它的表達式是用 Grovvy 來做的。Grovvy 是一個動態語言，凡是 Grovvy 能用的語法，在有字符串的地方都可以用。

所以，這些步驟中，可以說這個步驟參數是來自表達式;也可以說有條件的執行，生成環境的時候才做這樣的東西;也可以有前置條件，當滿足這個條件的時候，這個流程和 stage 可以繼續走下去。

圖 10

如圖 10 是各種類型的表達式，從現在來看，基本上各種需求我們都能滿足了。

圖 11

Pipeline 可以自動觸發(圖 11)，可以每天、每周、每月、每年，某一天的時候被自動觸發，做一個自動發布等等;也可以在鏡像有新 tag 推送到鏡像倉庫時，Pipeline 去做發布。

02.Spinnaker 和 Kubernetes 的關系

圖 12

Spinnaker 和 Kubernetes 有什么關系?它有很多概念是一對一的，Spinnaker 有一個叫 Account 的，Account 對應到 Kubernetes 是 Kubernetes Cluster。

我們的環境里現在有三個 Kubernetes 的 Cluster，分別對應到開發、測試和生產，它也是對應到 Spinnaker 的 三個 Account;Instance 對應到 Kubernetes 里是 Pod，一個 Pod 就是一個運行的單元。

還有 Server Group，這個 Server Group 對應的是 Replica Set 或者是 Deepionment。然后是 Load Balance，在 Spinnaker 里稱之為 Load Balance 的東西在 Kubernetes 里就是 Service。

03.Traefik

圖 13

Traefik 的幾個亮點：

• 配置熱加載，無需重啟。為什么我們用 Traefik 而不用 Nginx 做反向代理呢?首先 Traefik 是一個配置熱加載，用 Nginx 時更新路由規則，做后端服務器的上線、下線都需要重載，但 Traefik 不需要。
• 自帶熔斷功能。Traefik 自帶熔斷功能，可以定義后端某個實例錯誤率超過比如 50% 的時候，主動熔斷它，請求再也不發給它了。

           traefik.backend.circuitbreaker:NetworkErrorRatio() > 0.5

• 動態權重的輪詢策略。它會記錄 5 秒鐘之內所有后端實例對請求的響應時間或連接數，如果某個后端實例響應特別慢，那接下來的 5 秒鐘就會將這個后端的權重降低，直到它恢復到正常性能，這個過程是在不斷的調整中，這是我們需要的功能。

traefik.backend.loadbalancer.method:drr

因為上了容器之后，我們很難保證一個應用的所有實例都部署在相同處理能力的節點上，云服務商采購服務器也是按批量來的，每一批不可能完全一致，很難去保證所有的節點性能都是一致的。

圖 14

圖 14 是 Traefik 自帶的界面。我們定義的規則，后端實例的情況都可以實時的展現。

04.為什么在 Kubernetes 環境里選擇了 Traefik?

Traefik 和 Kubernetes 有什么關系呢?為什么在 Kubernetes 環境里選擇了 Traefik?我們總結了如下幾點：

• Kubernetes 集群中的 Ingress Controller。Traefik 在 Kubernetes 是以 Ingress Controller 存在，大家知道 Kubernetes 到 1.4 之后就引進了 Ingress 的概念。

         Kubernetes 原來只有一個 Service 來實現服務發現和負載均衡，service 是四層的負載均衡，它做不到基于規則的轉發。

• 動態加載 Ingress 更新路由規則。在 Kubernetes 里 Ingress 是屬于七層 HTTP 的實現，當然 Kubernetes 本身不去做七層的負載均衡，它是通過 Ingress Controller 實現的，Traefik 在 Kubernetes 里就是一種 Ingress Controller。
• 根據 Service 的定義動態更新后端 Pod。它可以動態加載 Kubernetes 里的 Ingress 所定義的路由規則，Ingress 里也定義了一個路由規則所對應的 Service，而 Service 又和具體的 Pod 相關。
• 根據 Pod 的 Liveness 檢查結果動態調整可用 Pod。Pod列表是根據 Pod 的 Liveness 和 Readiness 狀態做動態的調整。
• 請求直接發送到 Pod。Traefik 據此可以將請求直接發送給目標 Pod，無需通過 Service 所維護的 iptables 來做轉發。

圖 15

圖 15 是新發布的一個流程或者是開發的流程。我們有如下三個環節：

• 開發階段。
• 集成測試。
• 上線。

開發階段，開發者在迭代開始時生成一個 Feature 分支，以后的每次更新都將這個 Feature 分支推送到 GitLab 。

GitLab 里配置的 Webhook 觸發一個 Jenkins job，這個 job 做單元測試和鏡像構建，構建成一個 Feature 分支的鏡像，給這個鏡像一個特定的 tag。生成新的鏡像之后，觸發 Spinnaker 的部署，這個部署只在開發環境里。

開發者怎么訪問剛剛部署的開發環境呢?如果這是個 HTTP 應用，假設應用叫做 APP1，而分支名稱叫 A，那開發者就通過 APP1-A.dev.xiaohongshu.com 就可以訪問到 Feature A 的代碼。

在整個周期里可以不斷的迭代，最后開發者覺得完成了這個 Feature 了，就可以推送到 release。一旦把代碼推往 release 就觸發另一個構建，基本上和前面的過程差不多。

最后會有一個自動化的測試，基本上是由測試團隊提供的自動化測試的工具，用 Spinnaker 調用它，看結果是什么樣。

如果今天很有信心了，決定往生產發了，可以在 Git 上生成一個 tag，比如這個 tag 是 0.1.1，今天要發 0.1.1 版了，同樣也會觸發一個鏡像的構建。

這三個不同的階段構建的鏡像 tag 不一樣，每生成一個新 tag， Spinnaker 會根據 tag 的命名規則觸發不同的 Pipeline，做不同環境的部署。

05.Canary

最重要的是我們有一個 Canary 的發布過程，我們在 Spinnaker 的基礎上，開發了一套 Canary 的機制。

Canary 和 Beta 差不多，但 Canary 是真實引入流量，它把線上用戶分為兩組：

• 穩定版的流量用戶。
• Canary 版的用戶。

他們會率先使用新版本，我們的具體策略是先給公司、先給我們自己辦公室的人來用，這個灰度如果沒問題了，用戶反饋 OK，看看監控數據也覺得沒有問題，再按照 1%-10%-20%-50%-100% 的階段隨機挑選線上用戶繼續灰度。

在這整個過程都有監控數據可以看，任何時候如果有異常都可以通過 Spinnaker 進行回退。

 

圖 16

這個是 Canary 的示意圖，線上用戶被分成兩組，大部分用戶訪問老版本，特定用戶通過負載均衡轉發到特定的版本里，后臺有監控數據方便去比較兩個版本之間的差異。

圖 17

這是我們在容器環境里實現的 Canary 的架構(圖 17)，用戶請求從前面進來，首先打到 Traefik，如果沒有做 Canary 的過程，Traefik 是直接把請求打到組實例。

如果要發布一個新的版本，有一個 HTTP 的 API 控制 project service，決定把什么樣的流量可以打到這個里面版本。

我們的策略可能是把辦公室用戶，可以通過 IP 看到 IP，或者把線上的安卓用戶，或者線上 1% 的安卓用戶打給它，這些都是可以定義的。

 

圖 18

如圖 18 所示是線上真實的部署流程。首先是要設置一個 Canary 策略，這個策略可以指定完全隨機還是根據用戶的特定來源。

比如說是一個辦公室用戶，或者所有上海的用戶等等，然后去調整參數，是 1% 的上海用戶，還是所有的上海用戶。

然后開始部署服務，接下來把這個 Canary 實例做擴展，在流量進來之前，實例的容量一定要先準備好。

進來之后把流量做重新定向，把流量從原來直接打給后端的 Pod 改成打到 Canary 代理服務上，由 Canary 代理服務根據策略和用戶來源做進一步的流量分發。

整個過程不斷的迭代，有 1% 的線上用戶開始慢慢到達 100%。在達到 100% 后，就采用紅黑的策略替換掉所有舊版本：先把所有的新版本實例生成出來，等所有的新版本通過健康檢查，都在線了，舊的版本再批量下線，這樣完成一個灰度。

如果中途發現問題不能繼續，馬上就可以回退，所謂的回退就是把流量打回到線上版本去。

圖 19

如上圖(圖 19)是我們的 Canary 策略。這是我們自己實現的一套東西，圖中的例子是把來自指定網段一半的 iPhone 用戶進行 Canary。

用戶分組的維度還可以有其他規則，現在我們支持的是完全隨機/特定 IP/特定設備類型，這些規則可以組合起來。

我們的用戶分組是有一致性保證的，一旦為某個用戶分組了，那在當前灰度期間，這個用戶的分組不會變，否則會影響用戶體驗。

未來發展

我們下一步打算做兩件事情：

• 做自動灰度分析，叫 ACA，現在 AIOps 概念很熱門，自動灰度分析可以說是一個具體的 AIOps 落地。

         在灰度的過程中，人肉判斷新版本是否正常，如果日志采集夠完整的話，這個判斷可以由機器來做，機器根據所有數據來為新版本做評分，然后發布系統根據評分結果自動繼續發布或者終止發布并回退。

• 再往下可以做自動的容量管理，當然是基于 Kubernetes 的基礎上，做自動容量管理，以便更好的善用計算資源。

最后總結一下：一個好的 CD 系統應該能夠控制發布帶來的風險;我們在人力資源有限的情況下傾向于采用開源的方法解決問題，如果開源不滿足的話，我們再開發一些適配的功能。

[[207478]]

孫國清

小紅書運維團隊負責人

 

浙大計算機系畢業，曾在傳統企業 IT 部門工作多年，最近幾年開始在互聯網行業從事技術及技術管理工作，曾就職于攜程基礎架構，負責 Linux 系統標準化及分布式存儲的研究和落地，目前在小紅書帶領運維團隊，負責業務應用、基礎架構以及IT支持。個人接觸的技術比較雜，從開發到運維的一些領域都有興趣，是 Scala 語言的愛好者，曾翻譯了“The Neophyte's Guide to Scala”，有上千 Scala 開發者從中受益，到小紅書后開始負責系統化落地 DevOps 和提高運維效率。