使用Zadig交付云原生微服务应用

前面我们介绍了一个非常简单的使用Zadig交付的应用示例。接下来介绍下Zadig下微服务项目是如何交付的。微服务示例我们这里使用的开源项目是https://github.com/GoogleCloudPlatform/microservices-demo。开源项目名为OnlineBoutique(https://onlineboutique.dev/)，这是一个云原生微服务演示应用程序，包含11个微服务，是一个基于Web的电子商务应用程序，用户可以在其中浏览商品，将它们添加到购物车，然后购买。Zadig在这个项目的基础上进行了优化和修改。项目地址：https://github.com/cnych/microservices-demo该项目由11个用不同语言编写的微服务组成，它们之间通过gRPC进行通信。架构如下所示。微服务架构中各个服务的功能描述如下表所示。服务功能Zadig项目接下来我们使用Zadig来交付微服务项目，使用方法和上一个基本类似。首先新建一个项目，名称为microservices-demo，项目类型为K8sYAML项目。要创建一个新项目，现在点击CreateNew按钮，然后进入项目初始化页面。项目初始化点击下一步进入服务配置页面。我们知道服务模板可以手动创建，也可以同步到代码仓库，也可以从已有的K8s资源中导入。我们这里的服务模板在代码仓库中，所以选择从代码仓库同步，??选择对应的代码仓库、分支和对应的资源列表目录，然后点击同步按钮，将对应的服务同步到Zadig。同步服务可以看到我们这里同步了12个服务，每个服务的模板也直接显示出来了，但是因为是通过仓库同步的，所以模板是只读的，服务会自动读取右边对应的图片信息。注意：Zadig读取资源列表后，会使用K8sYAML中的容器名作为去重的唯一key，所以写K8sYAML时不要让容器名重复，否则导入后服务丢失。ServiceTemplate点击右侧图片服务组件后面的AddBuild按钮，配置服务图片的构建方式。首先需要添加服务代码源信息。我们这里的代码是在GitLab上的，所以添加相应的代码仓库和分支信息。我们这里所有的服务代码都位于代码仓库根目录下的src目录下。代码结构这是一个典型的Monorepo类型的仓库（单体），我们并没有把里面的每一个服务配置成一个子模块，所以我们需要在每一个服务构建的时候clone整个代码仓库，但实际上我们只需要其中的一个services就够了，Git支持这种操作。比如我们只想获取adservice服务的数据，可以通过以下方法获取。$mkdirmicroservices-demo&&cdmicroservices-demo$gitinit$gitremoteaddorigingit@git.k8s.local:course/microservices-demo.git$gitconfigcore.sparsecheckouttrue$gitsparse-checkoutset"src/adservice"$gitpull--depth1originmainremote:枚举对象:307,done.remote:计数对象:100%(307/307),done.remote:压缩对象:100%(234/234),done.remote:总计307（delta72），重复使用185（delta39），打包重复使用0接收对象：100%（307/307），9.55MiB|5.28MiB/s，完成。解析增量：100%(72/72)，完成。来自git.k8s.local:course/microservices-demo*branchmain->FETCH_HEAD*[newbranch]main->origin/main$ls-lasrctotal0drwxr-xr-x3cnychstaff96Jul1514:10.drwxr-xr-x4cnychstaff128Jul1514:10..drwxr-xr-x12cnychstaff384Jul1514:10adservice通过上述方法只能获取到指定目录的code，可惜Zadig目前是这样的not不支持这个功能，说不定以后会支持！代码源配置好之后，最重要的就是添加一个通用的构建脚本。构建服务这里我们实际上是在配置如何构建镜像。对应的脚本如下：#!/bin/bashset-ecd$WORKSPACE/$REPONAME_0/src/adservicedockerbuild-t$IMAGE-fDockerfile.dockerpush$IMAGE首先需要进入当前服务的代码根目录，我们这里使用cd$WORKSPACE/$REPONAME_0/src/adservice命令，其中$WORKSPACE、$REPONAME_0、$IMAGE为内置构建变量，$WORKSPACE代表工作根目录，$REPONAME_0代表第一个名字配置好的代码仓库，也就是microservices-demo。build变量进入服务根目录后，我们只需要执行dockerbuild命令就可以构建镜像了。Dockerfile配置在各个服务的根目录下。构建的镜像被变量$IMAGE替换，它将使用添加的默认镜像存储库。默认的图片命名规则如下，我们也可以自己自定义。镜像命令规则构建配置完成后，记得保存构建，所有服务的构建都用同样的方法配置。服务配置完成后，接下来就是加入环境了。同样默认情况下，将自动创建一组开发和质量检查环境以及3个工作流。加入环境加入环境后，可以看到对应的3个工作流，点击Finish即可。工作流执行工作流，使项目创建成功。现在我们首先在开发环境中运行工作流。点击ExecuteWorkflow，在服务中，可以选择我们要构建的服务，可以选择一个或者多个服务。执行任务执行完相同的任务后，会执行配置的通用脚本，然后将相应的服务部署到K8s集群中。任务详情所有服务执行完毕后，您可以在环境页面看到所有服务的状态和最新的镜像信息。dev环境中的各个服务正常部署到dev环境后，查看对应的Pod状态：$kubectlgetpods-nmicroservices-demo-env-devNAMEREADYSTATUSRESTARTSAGEadservice-5b5b97cf59-b7d6g1/1Running021mcartservice-7d66bd5c4-wxd6v1/1正在运行015mcheckoutservice-6dbc8cdc46-fqrnx1/1正在运行014mcurrencyservice-54fccf7b9f-c29h51/1正在运行013memailservice-844b6c9b58-j5smc1/1正在运行013mfrontend-649699cc5-s5crator015dmcrator15dcrator1/6正在运行-6dtrb1/1运行05m42spaymentservice-fd8f95f79-4889n1/1运行011mproductcatalogservice-775db476b6-l4s2t1/1运行06m47srecommendationservice-79f558bc9b-jx69n1/1运行06m47sredis-cart1dc7运行9n50bd34mshippingservice-f789c4494-ktbnz1/1运行06m43s$kubectlgetsvc-nmicroservices-demo-env-devNAME类型CLUSTER-IP外部IP端口（S）AGEadserviceClusterIP10.96.40.23<无>9555/TCP41mcartserviceClusterIP10.110。0.136<无>7070/TCP41mcheckoutserviceClusterIP10.109.209.29<无>5050/TCP41mcurrencyserviceClusterIP10.98.43.229<无>7000/TCP41memailserviceClusterIP10.101.67.47<无>5000/TCP41nonecluster26IP8Cluster26TCP41mfrontend-外部负载均衡器10.109.168.181192.168.0.5380:30090/TCP41mpaymentserviceClusterIP10.105.223.48<无>50051/TCP41MProductCatalogServiceclusterip10.102.112.643550/TCP41MRECORMENDATICTIANSEVICECLUSTICECLUSTERIP10.99.127.1438080/TCP41MREDIS41MREDIS41MREDIS-CART-CART-CARTcARTcARTcARTcLUSTIP10.111.15.205<无>6379/TCP41MSHIPP41MSHIPP41MSHIPP41MSHIPP41MSHIPP2022最后是通过frontend-external的LoadBalancer类型Service暴露出来的服务，我们可以通过分配的IP192.168.0.53直接访问该服务。前端外部触发器也可以添加到服务中以触发任务。在流量编辑页面，点击左侧的trigger添加，勾选Webhook->Addconfiguration，我们可以先只为adservice服务添加一个trigger，选择对应的代码库，要部署的服务，最重要的thing是文件目录部分的配置，也就是代码仓库里面有什么文件变化会触发我们的任务。我们的配置是：src/adservice/!.md!.gitignore。如果代码发生变化，并且不是.md或.gitignore文件，任务将被触发。触发配置后记得保存。现在我们可以修改adservice服务中的代码，修改代码src/adservice/src/main/java/hipstershop/AdService.java，比如我们将177行的50%修改为60%，然后提交代码到主要分支。修改代码当我们将上面的代码推送到主分支时，Zadig立即触发了一个新的任务。webhooktrigger任务执行成功后，我们可以检查产品页面是否有效。验证修改后，实现了微服务项目的持续构建。同样的，我们也可以手动创建一个环境进行投放，操作方法是一样的。测试用例此外，我们还可以创建一些新的测试用例。单击测试页面上的新建测试按钮开始创建测试用例。创建一个新的测试。比如这里我们对一个go服务做一个简单的测试。可以在依赖的软件包中选择对应的依赖。如果没有对应的软件包，可以新建一个。软件依赖例如我们需要一个1.17版本的go环境，可以通过系统设置->包管理新建一个软件包。新建一个软件包然后新建一个测试用例，选择相应的依赖，同时配置相应的代码源和测试脚本。创建测试脚本后，可以用同样的方式执行测试用例。执行测试测试详情页面与工作流的任务页面基本相同。测试详情还可以查看相应的测试报告。测试报告此外，我们还可以将自动化测试与工作流关联起来。当日常工作流更新环境时，会自动执行自动化测试。可以实现只要环境发生变化，第一时间自动测试。关联工作流后，启动工作流任务，即可看到测试用例。测试用例工作流程Zadig也会对我们的构建数据进行统计，提供构建性能、部署性能等数据。构建性能至此，我们已经完成了使用Zadig持续集成和交付微服务项目。当然在实际生产环境中，与具体的项目业务有一定关系，需要结合实际需求进行实践。