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

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

[[207473]]

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

[[207474]]

圖 1

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

我們從社區(qū)里的用戶創(chuàng)建的筆記生成相關(guān)的標(biāo)簽，關(guān)聯(lián)相關(guān)商品，同時在商品頁面也展示社區(qū)內(nèi)的和這商品有關(guān)的用戶筆記。

小紅目前還處在創(chuàng)業(yè)階段，我們的技術(shù)團隊規(guī)模還不大，當(dāng)然運維本身也是一個小團隊，團隊雖小，運維有關(guān)的技術(shù)方面卻都得涉及。

小公司資源有限，一個是人力資源有限，二是我們很多業(yè)務(wù)往前趕。在如何做好 CI/CD，怎么務(wù)實的落地方面，我們的策略就是開源優(yōu)先，優(yōu)先選擇開源的產(chǎn)品，在開源的基礎(chǔ)上，發(fā)現(xiàn)不滿足需求的地方再自行開發(fā)。

小紅書應(yīng)用上線流程

圖 2

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

我們現(xiàn)在有一個運維平臺，所有服務(wù)器的部署都是由這個平臺來完成，平臺調(diào)用騰訊云 API 生成服務(wù)器，做環(huán)境初始化，配置監(jiān)控和報警，最后交付給開發(fā)的是一個標(biāo)準(zhǔn)化好的服務(wù)器。

圖 3

開發(fā)者拿到服務(wù)器準(zhǔn)備線上發(fā)布時，采用 Jenkins 觸發(fā)腳本的方式：用 Jenkins 的腳本做測試，執(zhí)行代碼推送。

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

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

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

以上的做法其實是大多數(shù)公司的現(xiàn)狀，但是對于我們已經(jīng)不太能適應(yīng)了，目前我們整個技術(shù)在做更迭，環(huán)境的復(fù)雜度越來越高。

如果還是維持現(xiàn)有的代碼上線模式，顯然會有失控的風(fēng)險，而且基于這樣的基礎(chǔ)架構(gòu)做例如自動容量管理等，都是很難做到的。

技術(shù)團隊的問題與需求

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

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

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

再加上電商每年大促銷，擴容在現(xiàn)有模式也很耗時耗力。所以現(xiàn)在的模式已經(jīng)很難持續(xù)下去。

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

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

快速實現(xiàn)容器化鏡像部署的方法

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

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

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

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

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

圖 4

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

這里重點介紹兩個比較新，現(xiàn)在相當(dāng)火的開源技術(shù)：

• Spinnaker，這是一個我個人認(rèn)為非常優(yōu)秀的開源的發(fā)布系統(tǒng)，它是由 Netflix 在去年開源的，是基于 Netflix 內(nèi)部一直在使用的發(fā)布系統(tǒng)做的開源，可以說是 Netflix 在 CD 方面的最佳實踐，整個社區(qū)非?；钴S，它對 Kubernetes 的環(huán)境支持非常好。
• Traefik，在我們的環(huán)境里用來取代 Nginx 反向代理，Traefik 是用 Go 寫的一個反向代理服務(wù)軟件。

01.Spinnaker

Spinnaker有如下幾個特點：

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

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

擁有較強的 Pipeline 表達能力。它的 Pipeline 可以復(fù)雜到非常復(fù)雜，Pipeline 之間還可以關(guān)聯(lián)。

有強大的表達式功能?？梢栽谌魏蔚沫h(huán)節(jié)里用表達式來替代靜態(tài)參數(shù)和值，在 Pipeline 開始的時候，生成的過程變量都可以被 Pipeline 的每個 stage 調(diào)用。

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

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

 

圖 5

圖 5 是 Spinnaker 的架構(gòu)，它是一個微服務(wù)的架構(gòu)，里面包含用戶界面 Deck，API 網(wǎng)關(guān) Gate 等。

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

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

圖 6

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

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

圖 7

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

這個步驟是某個用戶做某個審批，再分別執(zhí)行三個步驟其中的一個步驟，然后再執(zhí)行某個環(huán)節(jié)。也可以發(fā)布還是回退，發(fā)布是走發(fā)布的流程，回退就是回退的流程。

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

圖 8

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

例如當(dāng)前面的第一次發(fā)布里所有的實例都存活的時候，才執(zhí)行某個步驟?；蛘弋?dāng)前面的步驟達到了某個狀態(tài)，再執(zhí)行下一個步驟。

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

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

圖 9

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

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

圖 10

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

圖 11

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

02.Spinnaker 和 Kubernetes 的關(guān)系

圖 12

Spinnaker 和 Kubernetes 有什么關(guān)系?它有很多概念是一對一的，Spinnaker 有一個叫 Account 的，Account 對應(yīng)到 Kubernetes 是 Kubernetes Cluster。

我們的環(huán)境里現(xiàn)在有三個 Kubernetes 的 Cluster，分別對應(yīng)到開發(fā)、測試和生產(chǎn)，它也是對應(yīng)到 Spinnaker 的 三個 Account;Instance 對應(yīng)到 Kubernetes 里是 Pod，一個 Pod 就是一個運行的單元。

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

03.Traefik

圖 13

Traefik 的幾個亮點：

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

           traefik.backend.circuitbreaker:NetworkErrorRatio() > 0.5

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

traefik.backend.loadbalancer.method:drr

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

圖 14

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

04.為什么在 Kubernetes 環(huán)境里選擇了 Traefik?

Traefik 和 Kubernetes 有什么關(guān)系呢?為什么在 Kubernetes 環(huán)境里選擇了 Traefik?我們總結(jié)了如下幾點：

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

         Kubernetes 原來只有一個 Service 來實現(xiàn)服務(wù)發(fā)現(xiàn)和負載均衡，service 是四層的負載均衡，它做不到基于規(guī)則的轉(zhuǎn)發(fā)。

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

圖 15

圖 15 是新發(fā)布的一個流程或者是開發(fā)的流程。我們有如下三個環(huán)節(jié)：

• 開發(fā)階段。
• 集成測試。
• 上線。

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

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

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

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

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

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

這三個不同的階段構(gòu)建的鏡像 tag 不一樣，每生成一個新 tag， Spinnaker 會根據(jù) tag 的命名規(guī)則觸發(fā)不同的 Pipeline，做不同環(huán)境的部署。

05.Canary

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

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

• 穩(wěn)定版的流量用戶。
• Canary 版的用戶。

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

在這整個過程都有監(jiān)控數(shù)據(jù)可以看，任何時候如果有異常都可以通過 Spinnaker 進行回退。

 

圖 16

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

圖 17

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

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

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

 

圖 18

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

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

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

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

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

如果中途發(fā)現(xiàn)問題不能繼續(xù)，馬上就可以回退，所謂的回退就是把流量打回到線上版本去。

圖 19

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

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

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

未來發(fā)展

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

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

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

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

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

[[207478]]

孫國清

小紅書運維團隊負責(zé)人

 

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