個推Node.js 微服務實踐：基於容器的一站式命令列工具鏈

作者：個推Node.js 開發工程師 之諾

背景與摘要

由於工程數量的快速增長，個推在實踐基於 Node.js 的微服務開發的過程中，遇到了如下問題：

1. 每次新建專案都需要安裝一次依賴，這些依賴之間基本相似卻又有微妙的區別；

2. 每次新建專案都要配置一遍相似的配置（比如 tsconfig、lint 規則等）；

3. 本地 Mac 環境與線上 Docker 內的 Linux 環境不一致（尤其是有 C++ 依賴的情況）。

為了解決上述問題，個推內部開發了一個命令列小工具來標準化專案初始化流程、簡化配置甚至是零配置，提供基於 Docker 的一致構建、執行環境。

CLI: init, build, test & pack

新建一個 Node.js 專案的時候，我們一般會：

1. 安裝許多開發依賴：TypeScript、Jest、TSLint、benchmark、typedoc 等；

2. 配置 tsconfig、lint 規則、.prettierrc 等；

3. 安裝眾多專案依賴：koa、lodash、sequelize、ioredis、zipkin、node-fetch 等；

4. 初始化目錄結構；

5. 配置CI 指令碼。

通常，我們會選擇複製一個現成的專案進行修改，導致出現眾多看似相似卻又不完全相同的專案，比如十個專案可能會對應十種配置組合。對於同時跨多個工程的開發人員來說，眾多配置組合會增加他們的工作難度。而且，當安全審計發現某些 npm package 出現安全隱患時，開發人員則需要對每個引用這些包的專案逐一檢查和修正。

在確定的開發場景下，幾乎所有專案的開發依賴都差不多，開發配置也非常相似，因此我們基於 commander.js 寫了一個 init 工具，它會開個命令列的嚮導，自動安裝依賴、初始化專案目錄結構和配置。從而建立專案，並按照場景將所有配置收縮為特定幾種模板，進行統一處理。

隨後，我們有了 build、test、pack 命令，託管了 tsconfig、jest 配置、打包配置，自動呼叫 tsc 編譯，構建測試環境，然後呼叫 Jest 進行測試，進行標準化打包， CI 指令碼基本可以簡化為幾行標準指令碼。

CLI: Docker Build

在介紹這個命令前需要先簡單瞭解一下個推的映象體系：

前面提到我們將大部分依賴封裝到了一個 npm 包，這一層封裝也反映在個推的 Docker 映象體系內，可以簡單表述為下面的 Dockerfile：

# 公共依賴層的 Dockerfile
FROM node:10
RUN mkdir -p /usr/local/lib/webnode/node_modules \
  && cd /usr/local/lib/webnode \
  && npm install webnode
ENV NODE_PATH /usr/local/lib/webnode/node_modules
# 專案的 Dockerfile
FROM getui/webnode:1.2.3
COPY package*.json ./
RUN npm install
COPY . .
複製程式碼

當把這層依賴直接做進 Docker 映象時，雖然每個映象的 SIZE 還是 1G 多，但是每個映象的 UNIQUE SIZE 都是極小的，僅有數M的差分層。

一個簡單的對比，比如有 800M 公共系統依賴 + 每個服務平均 200M 的 npm 依賴 + 1M 的服務程式碼，那麼由於原先每個服務都會 npm install 大量重複依賴，20 個服務，就會有 800M + 200M * 20 + 1M * 20 = 4.82G 的總 UNIQUE SIZE。而採用依賴分層共享，則僅有 800M + 200M + 1M * 20 = 1.02G 的總 UNIQUE SIZE。在考慮應用的多版本之後，依賴分層共享帶來在儲存上的優勢會更加明顯。

我們以一定的依賴鎖定週期和控制為代價，換取了：

• 減少依賴組合、依賴版本組合的可能性，開發者選擇包的簡化、初始化專案的簡化；審計簡化、安全更新簡化 。
• CI 顯著提速，節省等待時間。
• 傳輸和儲存的壓力減少許多。
• 公共依賴被多個專案使用，得到了更加充分的測試。

webnode docker build 命令可以幫助簡化 Docker image 的構建過程，它內建了一個 Dockerfile 和dockerignore，該命令執行時，會基於這兩個檔案和當前的 Context，自動構建docker 映象。其中 Dockerfile 內含一些優化和我們的最佳實踐，開發人員只需要專注 Node.js 的專案的開發，這個命令則可以負責配置檔案許可權等操作以及生成標準化的、優化的 Docker 映象。

其設計目標是：

• 快：合理的依賴分層，最大程度應用 Docker 快取機制，通過 .dockerignore 裁剪不必要的 Context，因此可以實現飛快的構建速度 。
• 小：依據變更頻度做 Docker 分層設計、應用 multi-stage build，盡最大可能縮小一個映象的 UNIQUE SIZE 。
• 可重現：同樣的內容總是構建出相同的結果。

以 node_modules 依賴優化為例，下面兩種 Dockerfile 其實會有很大的區別：

FROM getui/webnode:1.2.3
COPY . .
RUN npm install

FROM getui/webnode:1.2.3
COPY package*.json ./
RUN npm install
COPY . .
複製程式碼

前者，每次 docker build 時，只要專案內任何程式碼變了，npm install 的快取都會失效，需要重新安裝，而後者僅當 package*.json 發生改變之時才會觸發重新 npm install。另外，我們還會對 package.json 進行預編譯，僅保留依賴相關的欄位，避免出現修改 package.json 的版本號就重新 npm install的情況。

webnode docker build 不僅可以幫助開發者進行統一化的映象構建、統一實踐最佳優化，節約資源，還能避免所有開發人員都需要接觸優化細節，省時省力。

CLI: Webnode Docker Start

在本地除錯開發的過程中，我們遇到了一些環境差異引起的問題：

• 生產環境與本地開發環境 Node.js 版本不一致。
• 一些含有 C++ 程式碼的 npm 依賴執行的跨平臺問題 。
• 檔案許可權配置、系統目錄結構與線上執行環境不完全一致 。
• 啟動初始化流程不一致（比如配置預拉取）。
• 開發本地常常缺少一些二進位制工具或版本不一致（比如 consul-template、nc 等）。

與本地直接啟動 Node.js 程式有所不同，這個命令會優先基於當前專案利用上面的 webnode docker build 命令構建 Docker 映象，然後啟動映象。

Docker 可以幫助消解環境差異：

• 便捷地攜帶與生產環境一致的Node.js 版本以及其他二進位制依賴。
• 一致的初始化流程。
• 輕鬆執行含有 C++ 的 npm 依賴。
• 檔案許可權、目錄結構與線上執行環境一致。

容器化的Node.js除錯方法有些許變化，需要暴露Node.js的Inspector埠，然後配一下Visual Studio Code的localRoot和remoteRoot：

WEBNODE_HOST=${WEBNODE_HOST:-127.0.0.1}
WEBNODE_PORT=${WEBNODE_PORT:-3000}
DOCKER_RUN_OPTIONS="$DOCKER_RUN_OPTIONS \ 
   -it \
   --rm \
   --network=\"getui-dev\"
   -p $WEBNODE_HOST:$WEBNODE_PORT:3000 \
   -p 127.0.0.1:9229:9229 \
   -e NODE_FLAGS=--inspect=0.0.0.0:9229 \
   --name $CONTAINER"
docker run \
   $DOCKER_RUN_OPTIONS \
   $DOCKER_IMAGE_TAG
{
   "version": "0.2.0",
   "configurations": [
       {
           "type": "node",
           "request": "attach",
           "name": "Attach Local WebNode",
           "address": "127.0.0.1",
           "port": 9229,
           "restart": true,
           "protocol": "inspector",
           "localRoot": "${workspaceFolder}",
           "remoteRoot": "YOUR_REMOTE_ROOT",
           "sourceMaps": true
       },
   ]
}
複製程式碼

基於容器開發 CLI 工具

基於容器的開發可以帶來諸多好處。一是便於分發，基於 Docker 的 Tag，開發者可以很方便地做基於小版本、大版本、分支的分發，可以像 nvm 一樣去切換版本。

二是CLI 指令碼不用處處考慮跨平臺相容的問題，比如：

• sed 在 Linux 和 Mac 下工作行為不一致的問題之類的。
• 有的環境有 Python 3 有的環境只有 Python 2

所有的依賴通過容器帶進來，簡潔而高效。

在基於 Docker 的工具開發的過程中，我們也遇到一些問題：

一是容器內外 UID/GID 不一致，如果是以非 ROOT 使用者執行 docker run，會導致容器內程式在掛載的目錄產生的檔案許可權與當前使用者不一致。

Docker for Mac對於檔案許可權有一些特別的行為，具體可以參見：docs.docker.com/docker-for-…

對於 Host 是 Linux 的情況，尤其在 CI 時，需要考慮 UID/GID 的問題。對於這種情況，我們選擇覆蓋掉了 entrypoint ，然後用 gosu 去做降權來處理。

CLI_EXEC_UID=${CLI_EXEC_UID:-0}
CLI_EXEC_GID=${CLI_EXEC_GID:-0}

exec gosu $CLI_EXEC_UID:$CLI_EXEC_GID env "$@"
複製程式碼

其實RedHat 旗下用於設計container runtime 的daemonless （例如 podman），就很適合做CLI工具，可以 rootless 執行，又尊重系統的許可權配置。然而其目前尚未成熟，業界採用率也不高，仍需要繼續觀望。

二是有時候 docker run 速度較慢，個推的解決方案是在首次啟動時啟動一個 docker run --detach，然後後續的 CLI 執行完全通過 docker exec 來進行，這樣避免掉了每次執行命令時啟動的開銷，速度提升明顯。

小結

以上便是個推 Node.js 微服務開發實踐中關於 CLI 工具的實踐，個推試圖示準化、優化專案結構以及映象構建，減少組合的可能性，有效降低了儲存、傳輸、構建的成本，讓開發人員更加省時省力。

後續我們還會繼續為大家介紹個推的 Docker 映象體系設計以及Node.js 微服務開發框架，敬請期待。

參考

• docs.docker.com/docker-for-…
  
• docs.docker.com/develop/dev…
• www.projectatomic.io/blog/2018/0…
• www.slideshare.net/AkihiroSuda…
• www.debian.org/doc/manuals…