摘要：本文將結(jié)合馬蜂窩容器化平臺(tái)賦能前端應(yīng)用構(gòu)建的實(shí)踐經(jīng)驗(yàn)，介紹整個(gè)平臺(tái)背后的設(shè)計(jì)和實(shí)現(xiàn)原理，取得的一些效果及問(wèn)題的優(yōu)化方案。如果使用容器化平臺(tái)就不會(huì)出現(xiàn)這方面的擔(dān)憂。

容器對(duì)前端開發(fā)真的有用嗎？答案是肯定的。

最初當(dāng)我向公司的前端同學(xué)「安利」容器技術(shù)的時(shí)候，很多人都會(huì)說(shuō)：「容器？這不是用在后端的技術(shù)嗎？我不懂啊，而且前端開發(fā)用不上吧?！?/p>

但其實(shí)，今天我們討論的「前端」已經(jīng)不是傳統(tǒng)意義上的「前端」, 首先體現(xiàn)在終端類型的多樣性，比如 iOS，Android，小程序等；另外，伴隨著 Node.js 等技術(shù)的興起，前端開發(fā)的邊界也在逐漸服務(wù)端延伸。來(lái)到大前端時(shí)代，如何以工程化、服務(wù)化和自動(dòng)化的方式來(lái)進(jìn)行應(yīng)用開發(fā)，實(shí)現(xiàn)業(yè)務(wù)的持續(xù)迭代、高可用、高并發(fā)是每一個(gè)成功的互聯(lián)網(wǎng)產(chǎn)品不斷探索的事情，而漸為成熟的容器技術(shù)大大提高了這個(gè)過(guò)程的效率。

本文將結(jié)合馬蜂窩容器化平臺(tái)賦能前端應(yīng)用構(gòu)建的實(shí)踐經(jīng)驗(yàn)，介紹整個(gè)平臺(tái)背后的設(shè)計(jì)和實(shí)現(xiàn)原理，取得的一些效果及問(wèn)題的優(yōu)化方案。

一般來(lái)說(shuō)前端的開發(fā)流程是這樣的：創(chuàng)建服務(wù)/項(xiàng)目 → 本地開發(fā) → 開發(fā)環(huán)境測(cè)試 → 生產(chǎn)環(huán)境測(cè)試? → 生產(chǎn)灰度 → 上線。

基于容器化平臺(tái)進(jìn)行前端開發(fā)的優(yōu)勢(shì)在于，前端和后端完全分離，我們只需要關(guān)注前端的項(xiàng)目構(gòu)建，而不需要和后端代碼一起打包。每個(gè)構(gòu)建版本及每個(gè)訪問(wèn)規(guī)則也都是獨(dú)立的，一個(gè)版本構(gòu)建失敗并不影響其他版本的構(gòu)建及訪問(wèn)。

那么，容器和前端的結(jié)合點(diǎn)在哪里？容器的優(yōu)勢(shì)在前端應(yīng)用研發(fā)的哪個(gè)環(huán)節(jié)發(fā)生作用？我們可以從開發(fā)、測(cè)試、生產(chǎn)這三個(gè)階段分別來(lái)看。

容器消除了線上線下的環(huán)境差異，保證了應(yīng)用生命周期的環(huán)境一致性標(biāo)準(zhǔn)化。而對(duì)于前端開發(fā)來(lái)說(shuō)，要完成的任務(wù)往往是完成內(nèi)容的呈現(xiàn)和響應(yīng)用戶的輸入，處理的是 HTML、JS、CSS 等靜態(tài)資源，文件直接發(fā)送到客戶端，不需要一個(gè)運(yùn)行環(huán)境，這里好像用不上容器。

那 Build 的時(shí)候呢？畢竟不同的項(xiàng)目是用不同的 Node 版本在做構(gòu)建，不同的容器可以進(jìn)入不同的 Node 版本，這樣就不會(huì)污染本機(jī)的 Node 環(huán)境。但其實(shí)沒(méi)有容器，前端還可以用 NVM 去管理 Node 版本，切換起來(lái)很隨意，也就是一兩行命令就能搞定的事情。而且本地開發(fā)很方便，看起來(lái)真的沒(méi)有必要用容器。

可以說(shuō)，容器本身并沒(méi)有幫助前端在開發(fā)階段變得更加便利。因此如果對(duì)容器技術(shù)不熟悉，開發(fā)階段沒(méi)有必要非要用容器。

過(guò)去我們用虛擬機(jī)進(jìn)行測(cè)試的一個(gè)常見(jiàn)的方案是，前端研發(fā)把自己的代碼上傳到虛擬機(jī)的一個(gè)目錄下，QA 可以直接通過(guò)域名進(jìn)行測(cè)試。但問(wèn)題是，公司有很多的產(chǎn)品線，可能會(huì)存在很多項(xiàng)目同時(shí)提測(cè)的情況。虛擬機(jī)對(duì)系統(tǒng)資源的消耗比較大，數(shù)量有限，并且難擴(kuò)容，影響測(cè)試效率。

如果使用容器化平臺(tái)就不會(huì)出現(xiàn)這方面的擔(dān)憂。因?yàn)槿萜鞣浅］p量，消耗低、啟動(dòng)快，可以迅速擴(kuò)容，不用擔(dān)心不夠用的問(wèn)題。

容器的另一個(gè)優(yōu)勢(shì)是它可以實(shí)現(xiàn)應(yīng)用程序的版本控制。比如我們?cè)谏暇€之后發(fā)現(xiàn)版本有問(wèn)題需要回滾，這種情況不可避免，傳統(tǒng)的做法是通過(guò) Git 或者 SVN 回滾，一旦合入的代碼想回退或者拆分就很難操作，而且重新部署也很耗時(shí)。

基于容器化的平臺(tái)，我們可以直接通過(guò)流控，把流量切到舊的版本上去，幾需要幾秒鐘的時(shí)間，回滾效率大大提升。

再如，前端性能的一個(gè)重要指標(biāo)是頁(yè)面加載時(shí)間，如果出現(xiàn)首頁(yè)白屏是非常破壞用戶體驗(yàn)的，特別是在做活動(dòng)的時(shí)候，我們把幾乎所有流量都引導(dǎo)到活動(dòng)頁(yè)，出現(xiàn)白屏?xí)浅Ｗ屓俗タ?。找到運(yùn)維排查之后發(fā)現(xiàn)有臺(tái)服務(wù)器掛了，只能通過(guò)重啟來(lái)解決。但是重啟機(jī)器存在很多不確定性，有可能這臺(tái)機(jī)器就起不來(lái)了，這種情況很常見(jiàn)。

但如果運(yùn)行在容器化平臺(tái)上，一個(gè)容器就是一個(gè)進(jìn)程，一臺(tái)機(jī)器如果宕機(jī)，集群會(huì)快速?gòu)牧硗庖粋€(gè)節(jié)點(diǎn)把服務(wù)拉起，而且是秒級(jí)的，基本不用擔(dān)心用戶的訪問(wèn)會(huì)出現(xiàn)問(wèn)題。

總結(jié)來(lái)看，容器與虛擬機(jī)相比主要的優(yōu)勢(shì)體現(xiàn)在可以實(shí)現(xiàn)快速擴(kuò)容、秒級(jí)回滾和穩(wěn)定保活。因此容器化對(duì)于前端開發(fā)來(lái)說(shuō)，更重要的意義是能夠保證服務(wù)的快速迭代，以及線上服務(wù)的穩(wěn)定性。

通過(guò)上面的介紹，相信大家已經(jīng)對(duì)容器技術(shù)為前端開發(fā)帶來(lái)了哪些變化有了一些感受。那么為了更好地應(yīng)用這項(xiàng)技術(shù)，前端同學(xué)也應(yīng)該掌握一些容器的基礎(chǔ)知識(shí)。

首先我們來(lái)看容器到底是什么，它為什么輕量、高性能。通過(guò)下面這張圖片，我們可以將虛擬機(jī)和容器進(jìn)行一個(gè)更加直觀的對(duì)比：

虛擬機(jī)通過(guò)在物理服務(wù)器上層通過(guò)運(yùn)行 Hypervisor 模擬硬件系統(tǒng)，來(lái)提升服務(wù)器的能力和容量。每個(gè)虛擬機(jī)中有一個(gè)內(nèi)核，運(yùn)行著不同的操作系統(tǒng)，啟動(dòng)之后會(huì)做進(jìn)程管理、內(nèi)存管理之類的事情。但對(duì)于前端應(yīng)用的構(gòu)建來(lái)說(shuō)，可能只是需要一個(gè) Nginx 做靜態(tài)服務(wù)器，這種場(chǎng)景下使用虛擬機(jī)就太重了。

容器之所以輕量，是因?yàn)槿萜鳑](méi)有 Hypervisor 層和內(nèi)核層，每個(gè)容器都共享宿主機(jī)的內(nèi)核和系統(tǒng)調(diào)用。因此一個(gè)容器內(nèi)包含的僅僅是一個(gè)程序運(yùn)行所需要的最少文件，啟動(dòng)容器就是啟動(dòng)進(jìn)程，對(duì)資源的開銷更小，維護(hù)起來(lái)更簡(jiǎn)單。

這是大家在聊到容器技術(shù)的時(shí)候經(jīng)常會(huì)提到的三個(gè)詞，下面來(lái)說(shuō)下它們各自的概念以及之間的聯(lián)系是什么。

鏡像：可以簡(jiǎn)單理解為一層層文件系統(tǒng)的集合，或者說(shuō)一些目錄的集合。比如對(duì)于我們的前端代碼，最下面那層目錄可能是 Nginx 運(yùn)行所需要的二進(jìn)制，然后在上面再加一層目錄是我們的代碼，比如說(shuō) index.html。這個(gè)鏡像分層所有的分層生成以后，都是只讀的，每一層文件不可修改。

容器：其實(shí)就是在上面的目錄上再加一層目錄。但它其實(shí)是一個(gè)空目錄，區(qū)別就在于容器最上面一層是可讀可寫的，也就是說(shuō)容器 = 鏡像 + 讀寫層。

比如我如果想修改之前的 index.html ，是通過(guò)把新的版本累加在之前的鏡像上。也就是說(shuō)生成容器以后，所有的變更都發(fā)生在頂層的鏡像可寫層，下面的這些層是不允許往里面寫東西的，但是可以累加，就像堆積木一樣，一直加上去，而原來(lái)的鏡像不會(huì)被容器修改，這也是鏡像可以被多個(gè)容器共享的原因。?

Docker：容器技術(shù)其實(shí)早就存在，Docker 是用來(lái)實(shí)現(xiàn)容器化技術(shù)的一種工具，也是目前業(yè)界最通用的一種方式，來(lái)幫我們制作鏡像，然后把鏡像運(yùn)行成為容器并管理起來(lái)。

介紹完簡(jiǎn)單的概念，我們就和大家一起來(lái)看馬蜂窩容器化平臺(tái)的整體架構(gòu)，我們是如何為前端賦能，以及賦予什么樣的能力。

我們基于 Docker 和 Kubernetes 搭建了容器云平臺(tái)，將應(yīng)用的構(gòu)建、部署、資源調(diào)度、應(yīng)用管理等能力抽象出來(lái)，以服務(wù)的方式提供給研發(fā)人員，提升線上服務(wù)的穩(wěn)定性和研發(fā)效率。下圖從應(yīng)用的角度出發(fā)，展示了前端應(yīng)用在容器化平臺(tái)的生命周期：

應(yīng)用是容器云平臺(tái)的基本操作對(duì)象。云平臺(tái)一個(gè)非常大的好處是屏蔽了項(xiàng)目的類型，不分前端或后端。于是在應(yīng)用的外殼下，不管是前端的代碼，還是后端的代碼，都可以享受同樣的服務(wù)。比如傳統(tǒng)意義上應(yīng)用在后端的限流、熔斷、服務(wù)治理等能力一樣可以賦予前端，使前端同學(xué)聚焦在業(yè)務(wù)開發(fā)上，而不需要關(guān)注底層的實(shí)現(xiàn)。

這是應(yīng)用中心的一個(gè)創(chuàng)建頁(yè)面，只需要幾步，一個(gè)應(yīng)用就可以創(chuàng)建完成，并且托管到我們的云平臺(tái)上：

創(chuàng)建完應(yīng)用之后就要開始構(gòu)建版本。通過(guò)使用容器，我們將應(yīng)用程序、配置和依賴關(guān)系等打包成一個(gè)個(gè)代碼鏡像，然后去告訴線上服務(wù)器怎么讓它們用容器化的方式運(yùn)行起來(lái)。因此版本管理包含代碼鏡像和運(yùn)行時(shí)配置兩部分內(nèi)容。

1. 代碼鏡像

我們使用基于 Pipeline + Docker 的 Drone 作為 CI 工具，它非常靈活，容易擴(kuò)展。Drone 的靈活性體現(xiàn)在 Pipeline 的配置上，可以通過(guò)設(shè)置 .drone.yml 文件的方式在項(xiàng)目中控制構(gòu)建鏡像的過(guò)程。?

為了更好地支持公司級(jí)別的應(yīng)用，我們向鏡像注入一些內(nèi)部經(jīng)常用到的包來(lái)構(gòu)建一個(gè)通用的基礎(chǔ)鏡像。在構(gòu)建的同時(shí)會(huì)做一些 CI，比如單元測(cè)試、漏洞檢測(cè)等。?

2. 運(yùn)行時(shí)配置

運(yùn)行時(shí)配置分成 Nginx 配置和部署運(yùn)行時(shí)的配置兩個(gè)部分

（1）Nginx 配置

Nginx 配置主要針對(duì) Node 前端項(xiàng)目來(lái)說(shuō)。將 Nginx 配置開放給應(yīng)用有這么幾點(diǎn)好處：

前端同學(xué)可以自己去配置 history 模式，不需要再去找服務(wù)端來(lái)配合。

自定義多個(gè) location。在面對(duì)多頁(yè)應(yīng)用時(shí)，可以通過(guò)配置 Nginx 把請(qǐng)求轉(zhuǎn)發(fā)到指定的入口文件，實(shí)現(xiàn)指定路由。

自定義 cache 緩存策略。緩存策略選擇更靈活，提升用戶體驗(yàn)，降低服務(wù)器處理請(qǐng)求的壓力。

（2）部署運(yùn)行配置

部署運(yùn)行配置是要告訴系統(tǒng)平臺(tái)要如何運(yùn)行版本包。這里其實(shí)也就為后續(xù)部署到 Kubernetes KVM 宿主機(jī)等多種平臺(tái)留好了擴(kuò)展。

總結(jié)來(lái)看，在版本管理的部分我們實(shí)現(xiàn)了以下幾點(diǎn)能力：

配置文件驅(qū)動(dòng)，一個(gè)應(yīng)用多份靈活好擴(kuò)展

Nginx 配置等開放給應(yīng)用，遵循 DevOps 思想，高效賦能

標(biāo)準(zhǔn)化版本產(chǎn)物，一處構(gòu)建，處處運(yùn)行

接下來(lái)我們需要把已經(jīng)構(gòu)建好的版本包部署到集群上去運(yùn)行。

在線上可能會(huì)有許多臺(tái)機(jī)器，V1、V2、V3 指的是各種版本。這個(gè)版本可以有多個(gè)實(shí)例。如果服務(wù)出現(xiàn)故障，我們主要通過(guò)兩種方式來(lái)保證穩(wěn)定高活：

高效調(diào)度：通過(guò) Kubernetes 調(diào)度器將指定運(yùn)行的容器調(diào)度到資源滿足要求、最合適的節(jié)點(diǎn)上去

多副本支撐：自動(dòng)部署一個(gè)容器應(yīng)用的多份副本，并持續(xù)監(jiān)控。如果容器掛掉自動(dòng)啟動(dòng)副本

結(jié)合我們之前說(shuō)到的主頁(yè)白頁(yè)的例子具體說(shuō)明，我們會(huì)在容器化平臺(tái)上持續(xù)看管容器，如果服務(wù)掛了，就在迅速在別的節(jié)點(diǎn)上啟動(dòng)起來(lái)。這里需要注意的是，「多份」不僅僅是說(shuō)在兩臺(tái)機(jī)器上啟動(dòng)就叫多份，如果兩臺(tái)機(jī)器都在一個(gè)機(jī)柜上，甚至在一個(gè)機(jī)房里，那么啟動(dòng)多份也沒(méi)有意義。

到這里，我們已經(jīng)把服務(wù)部署到線上，并且實(shí)現(xiàn)穩(wěn)定運(yùn)行。但是完成部署，不代表用戶就能訪問(wèn)，也不代表就能訪問(wèn)到正確的版本，所以接下來(lái)就到服務(wù)治理的環(huán)節(jié)。

服務(wù)治理是一個(gè)比較大的概念，可以應(yīng)用的場(chǎng)景也很多。它的其中一個(gè)內(nèi)容是讓用戶訪問(wèn)到指定的一線上版本。

技術(shù)方案

首先介紹下實(shí)現(xiàn)原理：

我們采用的是一個(gè) 支持 xds 協(xié)議的網(wǎng)關(guān)。當(dāng)新的配置通過(guò) xds 協(xié)議推送給網(wǎng)關(guān)時(shí)，它就會(huì)自動(dòng)進(jìn)行熱更新、熱重啟，然后去適應(yīng)新的配置。比如說(shuō)開始網(wǎng)關(guān)指向的是 V1 版本，如果我們現(xiàn)在希望指向 V2 版本，只需要把最新的配置通過(guò) xds 協(xié)議推送給網(wǎng)關(guān)，它就會(huì)應(yīng)用新的配置，通過(guò)這種方式就可以將指定版本部署到線上。

推送這里我們用的是 Pilot 組件，并針對(duì)推送速度進(jìn)行了優(yōu)化。Pilot 組件會(huì)不斷監(jiān)聽數(shù)據(jù)，發(fā)現(xiàn)有變更后就會(huì)取出。

應(yīng)用場(chǎng)景

針對(duì)這種設(shè)計(jì)，我們主要將其應(yīng)用在三個(gè)場(chǎng)景中：回滾、分流和 ABTest。

1. 回滾

所謂回滾其實(shí)就是流控，比如一開始網(wǎng)關(guān)指向的是 V2 版本：

如果發(fā)現(xiàn)有問(wèn)題，我只需要給網(wǎng)關(guān)推送一個(gè)新的配置，它就可以指向之前那個(gè)版本，非?？焖伲?/p>

2. 分流

分流主要應(yīng)用在文章開始說(shuō)到的提測(cè)場(chǎng)景中。過(guò)去使用虛擬機(jī)，由于不同的虛擬機(jī)有不同的域名，前端同學(xué)在測(cè)試的時(shí)候要么就是為了適配虛擬機(jī)去修改代碼，要么就是需要測(cè)試同學(xué)或者產(chǎn)品同學(xué)自己去修改自己本機(jī)的 host，非常不方便。

而使用容器化的方式，如說(shuō)現(xiàn)在默認(rèn)訪問(wèn)的是 V2 版本，但我們現(xiàn)在需要測(cè)試 V1 或 V3 版本，就可以推出一個(gè)配置給網(wǎng)關(guān)，告訴它說(shuō)如果請(qǐng)求里面的 cookie 含有標(biāo)識(shí) V=V1，就把請(qǐng)求轉(zhuǎn)發(fā)至 V1 版本；同樣如果 cookie 包含 V=V3，就將請(qǐng)求轉(zhuǎn)發(fā)到 V3, 所有的轉(zhuǎn)發(fā)都在網(wǎng)關(guān)層完成。

為了使服務(wù)更易用，我們提供了一個(gè)插件去自動(dòng)識(shí)別云平臺(tái)部署的服務(wù)和版本。QA 和 產(chǎn)品同學(xué)在測(cè)試的時(shí)候，只需要點(diǎn)選版本就可以，系統(tǒng)會(huì)自動(dòng)完成 cookie 注入。然后向服務(wù)端發(fā)送請(qǐng)求時(shí)，網(wǎng)關(guān)就會(huì)發(fā)現(xiàn)這個(gè)攜帶了某個(gè)版本的 cookie，自動(dòng)完成轉(zhuǎn)發(fā)：

3. ABTest

同樣的原理，我們可以通過(guò)配置指定用戶的 UID，控制用戶去訪問(wèn) ABTest 中的不同版本，這里支持的方式有很多，比如注入 cookie、不同的 head 頭、不同的請(qǐng)求方式等等，非常靈活。

以上是服務(wù)治理的內(nèi)容?？偟膩?lái)說(shuō)，我們能夠自動(dòng)化部署訪問(wèn)規(guī)則，可能只需要前端同學(xué)做一個(gè) git-push tag 的操作，就已經(jīng)打好版本并部署到開發(fā)環(huán)境甚至是生產(chǎn)環(huán)境，而整個(gè)過(guò)程對(duì)于平臺(tái)的使用者來(lái)說(shuō)是無(wú)感知的：?

自動(dòng)化部署訪問(wèn)規(guī)則，完整 CI/CD

靈活的分流策略，帶來(lái)秒級(jí)回滾，灰度，abtest 等功能

結(jié)合 chrome 插件，體驗(yàn)流暢

以上介紹了基于容器化云平臺(tái)我們可以為前端賦予哪些能力。經(jīng)過(guò)一些時(shí)間的探索，目前我們的流程已經(jīng)比較通暢，但不可避免還是會(huì)遇到一些問(wèn)題。

這種情況對(duì)用戶體驗(yàn)來(lái)說(shuō)非常糟糕。經(jīng)過(guò)排查后我們發(fā)現(xiàn)問(wèn)題出現(xiàn)在為了做到高可用，我們的網(wǎng)關(guān)配置了多個(gè)。

因?yàn)榫W(wǎng)關(guān)的轉(zhuǎn)發(fā)配置是通過(guò)推送下發(fā)的，多個(gè)網(wǎng)關(guān)之前就會(huì)存在時(shí)間差。有的網(wǎng)關(guān)先收到新的推送，有的后收到。當(dāng)用戶的請(qǐng)求打到了其中一個(gè)網(wǎng)關(guān)拿到了一個(gè) html，會(huì)告訴它應(yīng)該訪問(wèn)哪個(gè) hash 的 js。但如果不巧的是 hash 的 js 卻訪問(wèn)到了另外一個(gè)網(wǎng)關(guān)，然后轉(zhuǎn)發(fā)到另外一個(gè)版本，也就是另外一個(gè)容器，那么 hash 值肯定就不一樣了，找不到對(duì)應(yīng)的文件，導(dǎo)致 404。

這個(gè)問(wèn)題不僅云平臺(tái)會(huì)存在，只要是分布式的部署方案都可能存在時(shí)差的問(wèn)題。我們的解決方案是讓所有網(wǎng)關(guān)都連接到同一個(gè) Pilot。因?yàn)榫W(wǎng)關(guān)的數(shù)量是有限的，這時(shí)配置的下發(fā)就是由一個(gè)組件去負(fù)責(zé)推送所有的網(wǎng)關(guān)，因?yàn)?xds 協(xié)議本身是基于 GRPC 實(shí)現(xiàn)的，是一個(gè)長(zhǎng)連接的操作，所以速度非?？?。當(dāng)由一個(gè)節(jié)點(diǎn)去做推送，所有網(wǎng)關(guān)接收到配置的時(shí)差可以控制在在毫秒間，幾乎沒(méi)有影響。也就是 A 網(wǎng)關(guān)接收到新配置的同時(shí)，基本上 B 網(wǎng)關(guān)也已經(jīng)接收到新配置，這時(shí)候所有請(qǐng)求無(wú)論打到哪個(gè)網(wǎng)關(guān)，他們都會(huì)指向同一個(gè)版本，這個(gè)時(shí)候線上就不會(huì)再出現(xiàn) 404 的請(qǐng)求。

之前說(shuō)到，我們的灰度方案是應(yīng)用插件做 cookie，理論上來(lái)說(shuō)只要 cookie 的配置正確，就可以轉(zhuǎn)發(fā)到指定的版本上去。那么既然我的 html 已經(jīng)沒(méi)問(wèn)題了，為什么 js 還會(huì)出現(xiàn) 404？?

排查后發(fā)現(xiàn)，因?yàn)?js 請(qǐng)求的時(shí)候有一個(gè)標(biāo)簽叫「匿名標(biāo)簽」，如果我們?cè)谟?js 的時(shí)候打了匿名的標(biāo)簽，瀏覽器在發(fā) js 請(qǐng)求時(shí)就不會(huì)攜帶任何身份的標(biāo)識(shí)，網(wǎng)關(guān)就會(huì)認(rèn)為訪問(wèn)到一個(gè)默認(rèn)版本，也就是線上的版本，這個(gè)時(shí)候如果請(qǐng)求再到 V2 版本就會(huì) 404。?

目前我們構(gòu)建鏡像的方式主要是用 npm install 和 npm run build 兩個(gè)命令。之后我們會(huì)盡可能去釋放 Pipeline，包括基礎(chǔ)鏡像、Node 版本等，讓前端同學(xué)可以實(shí)現(xiàn)更多自定義的需求。

目前我們構(gòu)建鏡像的方案沒(méi)有很好地利用 Docker 的緩存機(jī)制，因此會(huì)影響構(gòu)建的時(shí)間。我們目前也在做優(yōu)化，盡可能減少甚至消滅大部分 npm install 的時(shí)間和 build 的時(shí)間。

目前我們已經(jīng)完成了一部分監(jiān)控告警能力的建設(shè)，主要是由平臺(tái)維護(hù)團(tuán)隊(duì)在使用，去監(jiān)控 QPS 狀況、服務(wù)是否穩(wěn)定，有沒(méi)有重啟等，團(tuán)隊(duì)內(nèi)部也會(huì)收到很多告警。但我們認(rèn)為這種報(bào)警其實(shí)更應(yīng)該發(fā)送給服務(wù)的負(fù)責(zé)人，后面我們慢慢要將這部分能力釋放出來(lái)，并且不斷完善和優(yōu)化告警規(guī)則。

最后簡(jiǎn)單總結(jié)：

容器化之后到底給前端賦能了什么？

提高測(cè)試效率

服務(wù)更加穩(wěn)定，運(yùn)維高效

馬蜂窩云平臺(tái)如何進(jìn)一步給前端賦能？

應(yīng)用中心：一步上云，無(wú)差別享受云平臺(tái)帶來(lái)的服務(wù)

版本管理：實(shí)踐 DevOps思想，賦能 Nginx 配置；配置驅(qū)動(dòng)，靈活好擴(kuò)展?

部署管理：智能調(diào)度，穩(wěn)定高活?

服務(wù)治理：秒級(jí)回滾，秒級(jí)恢復(fù)，灰度訪問(wèn)，ABTest等眾多功能

目前我們?cè)谌绾瓮ㄟ^(guò)容器化的方式幫助前端完成應(yīng)用研發(fā)有了一定的探索，并且通過(guò)云平臺(tái)的方式上做到更進(jìn)一步的賦能，希望能帶給大家一些技術(shù)思維上的啟發(fā)。

本文作者：周磊，馬蜂窩旅游網(wǎng)基礎(chǔ)平臺(tái)服務(wù)化研發(fā)工程師。

（題圖來(lái)源于網(wǎng)絡(luò)）

關(guān)注馬蜂窩技術(shù)，找到更多你想要的內(nèi)容