使用 Zadig 交付云原生微服務應用
前面我們介紹了使用 Zadig 交付一個非常簡單的應用示例，接下來我們來介紹下微服務項目如何在 Zadig 下進行交付。
微服務示例
我們這里使用到開源項目是 https://github.com/GoogleCloudPlatform/microservices-demo，該開源項目名叫 Online Boutique(https://onlineboutique.dev/)，是一個云原生微服務演示應用程序，其中包含 11 個微服務，該應用程序是一個基于 Web 的電子商務應用程序，用戶可以在其中瀏覽商品、將它們添加到購物車并購買它們。
基于該項目針對 Zadig 做了優(yōu)化修改，項目地址：https://github.com/cnych/microservices-demo
該項目由 11 個使用不同語言編寫的微服務組成，它們通過 gRPC 相互通信。架構如下所示。
每個服務的功能描述如下表所示。
Zadig 項目
接下來我們來使用 Zadig 來交付該微服務項目，使用方式和前面基本類似。
首先新建一個名為 microservices-demo 的項目，項目類型為 K8s YAML 項目。
點擊立即新建按鈕，然后進入項目初始化頁面。
點擊下一步進入到服務配置頁面，我們知道服務模板可以通過手動創(chuàng)建、代碼倉庫中同步或者現有 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 [email protected]: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 目前并不支持該功能，或許后續(xù)會支持吧！
代碼源配置后，最主要的是添加通用構建腳本。
我們這里其實就是配置如何構建鏡像，對應的腳本如下所示：
#!/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。
進入到服務根目錄下面后，我們只需要執(zhí)行 docker build 命令構建鏡像即可，每個服務的根目錄下面均配置了 Dockerfile 文件，構建的鏡像使用變量 $IMAGE 代替，會使用添加的默認的鏡像倉庫。
默認的鏡像命名規(guī)則如下所示，我們也可以自行定制。
構建配置完過后，記得保存構建，用同樣的方式配置所有服務的構建。
服務配置完成后下一步開始加入環(huán)境，同樣默認情況下會自動創(chuàng)建一套 dev 和 qa 的環(huán)境以及 3 條工作流。
加入環(huán)境后就可以看到對應的 3 條工作流了，點擊完成即可。
執(zhí)行工作流
這樣項目就創(chuàng)建成功了，現在我們先在 dev 環(huán)境來運行工作流。點擊執(zhí)行工作流，在服務中可以選擇我們要構建的服務，可以選擇一個也可以選擇多個服務。
同樣任務執(zhí)行后會執(zhí)行配置的通用腳本，然后將對應的服務部署到 K8s 集群中去。
將所有的服務執(zhí)行完成后在環(huán)境頁面可以看到所有服務的狀態(tài)和最新鏡像信息。
每個服務都正常部署到 dev 環(huán)境后，查看對應的 Pod 狀態(tài)：
$ 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 來訪問服務了。
觸發(fā)器
同樣我們也可以給服務添加觸發(fā)器來觸發(fā)任務，在工作流編輯頁面點擊左側的觸發(fā)器添加，勾選 Webhook -> 添加配置，我們可以先添加一個只針對 adservice 這個服務的觸發(fā)器，選擇對應的代碼庫、要部署的服務，最關鍵的是文件目錄部分的配置，也就是代碼倉庫中的什么文件變更才會觸發(fā)我們的任務，我們的配置為：
src/adservice/
!.md
!.gitignore
該段配置的表示當代碼倉庫中 src/adservice/ 目錄下面的代碼有變更，并且不是 .md 或者 .gitignore 文件則會觸發(fā)任務。
配置后記得保存。現在我們可以去修改下 adservice 服務中的代碼，修改代碼 src/adservice/src/main/java/hipstershop/AdService.java，比如我們將 177 行的 50%修改為 60%，然后提交代碼到 main 分支。
當我們將上述代碼 push 到 main 分支后，Zadig 就立即觸發(fā)了一次新的任務。
該任務執(zhí)行成功后我們可以去查看該產品的頁面是否生效。
到這里我就實現了該微服務項目的持續(xù)構建，同樣的我們可以去手動創(chuàng)建一個環(huán)境來進行交付，操作方式一樣的。
測試用例
此外我們還可以來新建一些測試用例，在測試頁面點擊新建測試按鈕即可開始創(chuàng)建測試用例。
比如我們這里對一個 go 服務做一次簡單的測試，在依賴的軟件包中可以選擇對應的依賴，如果沒有對應的軟件包，則可以新建一個。
比如我們需要一個 1.17 版本的 go 環(huán)境，可以通過 系統(tǒng)設置 -> 軟件包管理 新建一個軟件包。
然后我們重新去創(chuàng)建一個測試用例，選擇相應的依賴，同樣配置對應的代碼源和測試腳本。
創(chuàng)建后可以用同樣的方式來執(zhí)行該測試用例。
測試詳情頁面和工作流的任務頁面基本上一致。
同樣也可以看到對應的測試報告。
此外我們還可以將自動化測試和工作流關聯起來，當日常運行工作流更新環(huán)境后，會自動執(zhí)行自動化測試。可以實現只要環(huán)境有變更，就第一時間對其做自動化測試。
關聯后啟動工作流任務就可以看到有該測試用例了。
Zadig 還會為我們的構建數據進行統(tǒng)計，提供構建效能、部署效能等數據。
到這里我們就完成了使用 Zadig 來對微服務項目進行持續(xù)集成和交付，當然在實際的生產環(huán)境中和具體的項目業(yè)務有關系，這就需要能夠結合實際需求去實踐了。
今晚8點會在視頻號與大家對話 Zadig，會反饋大家對使用 Zadig 的相關問題，感興趣的朋友記得來哦~