使用 Zadig 交付雲原生微服務應用
微服務示例
我們這裏使用到開源項目是 https://github.com/GoogleCloudPlatform/microservices-demo，該開源項目名叫 Online Boutique(https://onlineboutique.dev/)，是一個雲原生微服務演示應用程序，其中包含 11 個微服務，該應用程序是一個基於 Web 的電子商務應用程序，用戶可以在其中瀏覽商品、將它們添加到購物車併購買它們。
基於該項目針對 Zadig 做了優化修改，項目地址：https://github.com/cnych/microservices-demo
該項目由 11 個使用不同語言編寫的微服務組成，它們通過 gRPC 相互通信。架構如下所示。
微服務架構
每個服務的功能描述如下表所示。
服務功能
Zadig 項目
接下來我們來使用 Zadig 來交付該微服務項目，使用方式和前面基本類似。
首先新建一個名爲 microservices-demo 的項目，項目類型爲 K8s YAML 項目。
新建項目
點擊立即新建按鈕，然後進入項目初始化頁面。
項目初始化
點擊下一步進入到服務配置頁面，我們知道服務模板可以通過手動創建、代碼倉庫中同步或者現有 K8s 資源中導入而來。我們這裏服務模板在代碼倉庫中，所以選擇從代碼庫中進行同步，選擇對應的代碼倉庫、分支和對應的資源清單目錄，然後點擊同步按鈕即可將對應的服務同步到 Zadig 中來。
同步服務
可以看到我們這裏同步過來後包含了 12 個服務，每個服務的模板也都直接展示出來了，但是由於是通過倉庫同步的，模板是隻讀模式，右側會自動讀取到服務對應的鏡像信息。
注意：Zadig 讀取資源清單後，會以 K8s YAML 中的容器名作爲唯一的 key 進行去重，所以在編寫 K8s YAML 的時候不要讓容器名重複，否則導入後會丟失服務。
服務模板
點擊右側讀取到的鏡像服務組件後面的添加構建按鈕，前往配置該服務的鏡像是如何進行構建的。
首先需要添加服務代碼源信息，我們這裏的代碼在 GitLab 上面，所以添加對應的代碼倉庫以及分支信息。我們這裏的所有服務代碼都位於代碼倉庫根目錄下面的 src 目錄下。
代碼結構
這屬於典型的 Monorepo 類型的倉庫（單體），而裏面的每個服務我們也並未配置成 submodule，所以每個服務構建的時候均要將整個代碼倉庫 Clone 下來，但其實我們只需要其中的一個服務即可，Git 是支持這種操作的，比如我們現在只想要獲取 adservice 這個服務的數據，可以通過下面的方式來獲取。
$ mkdir microservices-demo && cd microservices-demo
$ git init
$ git remote add origin git@git.k8s.local:course/microservices-demo.git
$ git config core.sparsecheckout true
$ git sparse-checkout set "src/adservice"
$ git pull --depth 1 origin main
remote: Enumerating objects: 307, done.
remote: Counting objects: 100% (307/307), done.
remote: Compressing objects: 100% (234/234), done.
remote: Total 307 (delta 72), reused 185 (delta 39), pack-reused 0
Receiving objects: 100% (307/307), 9.55 MiB | 5.28 MiB/s, done.
Resolving deltas: 100% (72/72), done.
From git.k8s.local:course/microservices-demo
* branch main -> FETCH_HEAD
* [new branch] main -> origin/main
$ ls -la src
total 0
drwxr-xr-x 3 cnych staff 96 Jul 15 14:10 .
drwxr-xr-x 4 cnych staff 128 Jul 15 14:10 ..
drwxr-xr-x 12 cnych staff 384 Jul 15 14:10 adservice通過上面的方式可以只獲取指定目錄的代碼，但是遺憾的是 Zadig 目前並不支持該功能，或許後續會支持吧！
代碼源配置後，最主要的是添加通用構建腳本。
構建服務
我們這裏其實就是配置如何構建鏡像，對應的腳本如下所示：
#!/bin/bash
set -e
cd $WORKSPACE/$REPONAME_0/src/adservice
docker build -t $IMAGE -f Dockerfile .
docker push $IMAGE首先需要進入到當前服務的代碼根目錄下面，我們這裏使用的是 cd $WORKSPACE/$REPONAME_0/src/adservice 命令，其中的 $WORKSPACE、$REPONAME_0、$IMAGE 均爲內置的構建變量，$WORKSPACE 表示工作根目錄，而 $REPONAME_0 表示配置的第一個代碼倉庫的名稱，也就是 microservices-demo。
構建變量
進入到服務根目錄下面後，我們只需要執行 docker build 命令構建鏡像即可，每個服務的根目錄下面均配置了 Dockerfile 文件，構建的鏡像使用變量 $IMAGE 代替，會使用添加的默認的鏡像倉庫。
默認的鏡像命名規則如下所示，我們也可以自行定製。
鏡像命令規則
構建配置完過後，記得保存構建，用同樣的方式配置所有服務的構建。
服務配置完成後下一步開始加入環境，同樣默認情況下會自動創建一套 dev 和 qa 的環境以及 3 條工作流。
加入環境
加入環境後就可以看到對應的 3 條工作流了，點擊完成即可。
工作流
執行工作流
這樣項目就創建成功了，現在我們先在 dev 環境來運行工作流。點擊執行工作流，在服務中可以選擇我們要構建的服務，可以選擇一個也可以選擇多個服務。
執行任務
同樣任務執行後會執行配置的通用腳本，然後將對應的服務部署到 K8s 集羣中去。
任務詳情
將所有的服務執行完成後在環境頁面可以看到所有服務的狀態和最新鏡像信息。
dev 環境
每個服務都正常部署到 dev 環境後，查看對應的 Pod 狀態：
$ kubectl get pods -n microservices-demo-env-dev
NAME READY STATUS RESTARTS AGE
adservice-5b5b97cf59-b7d6g 1/1 Running 0 21m
cartservice-7d66bd5c4-wxd6v 1/1 Running 0 15m
checkoutservice-6dbc8cdc46-fqrnx 1/1 Running 0 14m
currencyservice-54fccf7b9f-c29h5 1/1 Running 0 13m
emailservice-844b6c9b58-j5smc 1/1 Running 0 13m
frontend-649699cc5-s5ggp 1/1 Running 0 12m
loadgenerator-565cdbb5dc-6dtrb 1/1 Running 0 5m42s
paymentservice-fd8f95f79-4889n 1/1 Running 0 11m
productcatalogservice-775db476b6-l4s2t 1/1 Running 0 6m47s
recommendationservice-79f558bc9b-jx69n 1/1 Running 0 6m47s
redis-cart-f9bdd7959-qtc9n 1/1 Running 0 34m
shippingservice-f789c4494-ktbnz 1/1 Running 0 6m43s
$ kubectl get svc -n microservices-demo-env-dev
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
adservice ClusterIP 10.96.40.23 <none> 9555/TCP 41m
cartservice ClusterIP 10.110.0.136 <none> 7070/TCP 41m
checkoutservice ClusterIP 10.109.209.29 <none> 5050/TCP 41m
currencyservice ClusterIP 10.98.43.229 <none> 7000/TCP 41m
emailservice ClusterIP 10.101.67.47 <none> 5000/TCP 41m
frontend ClusterIP 10.96.37.222 <none> 80/TCP 41m
frontend-external LoadBalancer 10.109.168.181 192.168.0.53 80:30090/TCP 41m
paymentservice ClusterIP 10.105.223.48 <none> 50051/TCP 41m
productcatalogservice ClusterIP 10.102.112.64 <none> 3550/TCP 41m
recommendationservice ClusterIP 10.99.127.143 <none> 8080/TCP 41m
redis-cart ClusterIP 10.111.15.205 <none> 6379/TCP 41m
shippingservice ClusterIP 10.104.122.207 <none> 50051/TCP 41m該服務最後是通過 frontend-external 這個 LoadBalancer 類型的 Service 來暴露的服務，我們可以直接通過分配的 IP 192.168.0.53 來訪問服務了。
frontend external
觸發器
同樣我們也可以給服務添加觸發器來觸發任務，在工作流編輯頁面點擊左側的觸發器添加，勾選 Webhook -> 添加配置，我們可以先添加一個只針對 adservice 這個服務的觸發器，選擇對應的代碼庫、要部署的服務，最關鍵的是文件目錄部分的配置，也就是代碼倉庫中的什麼文件變更纔會觸發我們的任務，我們的配置爲：
src/adservice/
!.md
!.gitignore該段配置的表示當代碼倉庫中 src/adservice/ 目錄下面的代碼有變更，並且不是 .md 或者 .gitignore 文件則會觸發任務。
觸發器
配置後記得保存。現在我們可以去修改下 adservice 服務中的代碼，修改代碼 src/adservice/src/main/java/hipstershop/AdService.java，比如我們將 177 行的 50% 修改爲 60%，然後提交代碼到 main 分支。
修改代碼
當我們將上述代碼 push 到 main 分支後，Zadig 就立即觸發了一次新的任務。
webhook trigger
該任務執行成功後我們可以去查看該產品的頁面是否生效。
驗證修改
到這裏我就實現了該微服務項目的持續構建，同樣的我們可以去手動創建一個環境來進行交付，操作方式一樣的。
測試用例
此外我們還可以來新建一些測試用例，在測試頁面點擊新建測試按鈕即可開始創建測試用例。
新建測試
比如我們這裏對一個 go 服務做一次簡單的測試，在依賴的軟件包中可以選擇對應的依賴，如果沒有對應的軟件包，則可以新建一個。
軟件依賴
比如我們需要一個 1.17 版本的 go 環境，可以通過 系統設置 -> 軟件包管理 新建一個軟件包。
新建軟件包
然後我們重新去創建一個測試用例，選擇相應的依賴，同樣配置對應的代碼源和測試腳本。
測試腳本
創建後可以用同樣的方式來執行該測試用例。
執行測試
測試詳情頁面和工作流的任務頁面基本上一致。
測試詳情
同樣也可以看到對應的測試報告。
測試報告
此外我們還可以將自動化測試和工作流關聯起來，當日常運行工作流更新環境後，會自動執行自動化測試。可以實現只要環境有變更，就第一時間對其做自動化測試。
關聯工作流
關聯後啓動工作流任務就可以看到有該測試用例了。
測試用例
工作流
Zadig 還會爲我們的構建數據進行統計，提供構建效能、部署效能等數據。
構建效能
到這裏我們就完成了使用 Zadig 來對微服務項目進行持續集成和交付，當然在實際的生產環境中和具體的項目業務有關係，這就需要能夠結合實際需求去實踐了。
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/sdhJHVpeBBYPnJmB_zfFCg