Online Boutique 微服务扩展指南为 microservices-demo 添加新服务的完整流程【免费下载链接】microservices-demoSample cloud-first application with 10 microservices showcasing Kubernetes, Istio, and gRPC.项目地址: https://gitcode.com/GitHub_Trending/mi/microservices-demo导读本文以 Google Cloud 开源示例应用 Online Boutiquemicroservices-demo的官方文档 docs/adding-new-microservice.md 为主线系统讲解如何向这个由 10 个微服务组成的云原生电商系统添加第 11 个微服务。你将掌握从src/源码目录创建、Dockerfile 容器化到 Kustomize 组件注册、Skaffold 构建清单、Helm Chart 模板同步再到文档更新的完整 8 步落地流程并学会以仓库中真实存在的shoppingassistantserviceAI 购物助手为例进行端到端实践。图为 Online Boutique 的微服务架构总览新添加的服务需要作为独立节点融入这套 gRPC 服务网格之中。一、前置认知Online Boutique 的两套清单 一套图表机制在动手添加微服务之前先理解这个仓库的组织方式。从仓库根目录看每个微服务都以src/service-name/目录为圆心向外辐射三套注册信息文件/目录作用说明src/service/源码 Dockerfile服务的唯一代码来源构建镜像的上下文kustomize/components/service/Kustomize 组件清单可选组件通过components:字段挂载到基础层之上kubernetes-manifests/service.yaml基础部署清单被skaffold.yaml直接引用的默认部署资源helm-chart/templates/service.yamlHelm 模板提供 Helm 方式部署时的渲染模板skaffold.yaml构建与部署编排声明镜像构建 artifact 与 manifest 来源cloudbuild.yamlCI 流水线在 GKE 上调用 skaffold 完成一键部署添加一个新微服务本质就是让这个服务在这三套系统中都有名有姓。仓库中的 shoppingassistantservice基于 AlloyDB 的 RAG 购物助手正是官方文档点名推荐的参考范例下文将围绕它展开。二、步骤 1在src/下创建服务目录在src/目录中新建一个与微服务同名的目录例如src/shoppingassistantservice/。目录名即服务名它会贯穿镜像名、Kubernetes 资源名、Helm values key 的全部命名链路因此建议统一使用小写驼峰式命名。查看现有服务的目录结构可以观察到两个惯例大多数服务目录直接包含源码与构建文件例如 src/emailservice/Python个别服务存在一层嵌套如 src/cartservice/ 将 C# 工程放在src/cartservice/src/下——这一点在 docs/releasing/make-docker-images.sh 中有专门的分支处理说明发布脚本默认假设构建目录与目录名一一对应特殊结构需要特殊处理。三、步骤 2添加源码遵循既有服务的目录约定将服务源码放入新目录结构应遵循既有微服务的约定。官方文档以 Python 服务为例给出了最小文件集README.md服务的描述与文档main.py应用入口点requirements.inPython 依赖清单Dockerfile容器化构建文件。以仓库中的真实 Python 服务为参照shoppingassistantservice的目录结构如下src/shoppingassistantservice/shoppingassistantservice.py主程序对应main.py的约定requirements.in声明式依赖清单内容为flask、langchain、langchain-google-genai、langchain-google-alloydb-pg、google-cloud-secret-manager、pillow等见 requirements.inrequirements.txt由requirements.in生成、含固定版本号的锁定文件供 Dockerfile 安装Dockerfile容器化构建文件。同样地src/emailservice/ 的结构也印证了这一约定email_server.py为入口、requirements.in声明grpcio、google-cloud-profiler等依赖、templates/存放邮件模板。惯用约定入口文件、依赖清单、Dockerfile 三者齐备是任何语言实现的服务进入 Online Boutique 的门槛Go 服务如 src/frontend/则以go.mod、genproto.sh用于生成 gRPC 桩代码等文件对应这一约定。四、步骤 3创建 Dockerfile在服务目录中创建Dockerfile定义容器镜像的构建步骤。官方文档推荐参考 src/frontend/Dockerfile 并按需调整。不过对 Python 服务而言shoppingassistantservice的 Dockerfile 是更贴切的模板其关键设计点包括# 定义默认构建平台避免跨平台构建时为空 ARG BUILDPLATFORMlinux/amd64 # 使用固定 digest 的 base 镜像保证可复现 FROM --platform$BUILDPLATFORM python:3.14.6-slimsha256:b877e50bd... AS base # builder 阶段安装编译依赖并预装 Python 包 FROM base AS builder RUN apt-get -qq update \ apt-get install -y --no-install-recommends g \ rm -rf /var/lib/apt/lists/* COPY requirements.txt . RUN pip install -r requirements.txt # 运行阶段只复制已装好的包与应用代码镜像更精简 FROM base ENV PYTHONUNBUFFERED1 WORKDIR /shoppingassistantservice COPY --frombuilder /usr/local/lib/python3.14/ /usr/local/lib/python3.14/ COPY . . ENV PORT8080 EXPOSE 8080 ENTRYPOINT [python, shoppingassistantservice.py]值得学习的实践多阶段构建builder阶段安装g等编译工具运行阶段不保留这些工具显著缩小镜像体积固定 digestpython:3.14.6-slimsha256:...锁定镜像内容保证每次构建的可复现性统一端口约定Online Boutique 所有服务默认监听8080容器内由环境变量PORT控制——这一点被 kubernetes-manifests 中的 emailservice 清单 以及 helm-chart/templates/emailservice.yaml 的- name: PORT value: 8080反复印证。五、步骤 4创建 Kubernetes manifestsKustomize 组件在仓库根目录的kustomize/components/下为你的微服务新建一个组件目录放入必要的 Kubernetes YAML 文件。通常至少包含Deployment管理服务的 Pod 副本Service将微服务暴露给集群内其他服务。以 kustomize/components/shopping-assistant/ 为例其组件由 kustomization.yaml 组织resources引入shoppingassistantservice.yamlpatches则通过 Strategic Merge Patch 给frontend的 Deployment 注入ENABLE_ASSISTANTtrue环境变量——这演示了新服务除了自成一派还可能通过 patch 反向影响既有服务的高级用法。组件内的 shoppingassistantservice.yaml 是一个完整的参考实现值得逐段拆解Deploymentmetadata.name、selector.matchLabels、template.labels统一使用app: shoppingassistantservicesecurityContext设置runAsNonRoot: true、runAsUser: 1000容器级securityContext设置allowPrivilegeEscalation: false并drop: [ALL]端口与探针containerPort: 8080配合readinessProbe/livenessProbegRPC 或 HTTP 探针见 kubernetes-manifests/emailservice.yaml 的periodSeconds: 5资源配额requests: cpu 100m / memory 64Milimits: cpu 200m / memory 128Mi这是仓库所有服务的标准资源档位Servicetype: ClusterIPport: 80映射targetPort: 8080供集群内部服务发现ServiceAccount配合 Workload Identity 注解iam.gke.io/gcp-service-account实现最小权限访问云资源。注意官方文档强调 Deployment 中指定的镜像必须与cloudbuild.yaml和skaffold.yaml中构建的镜像一致。在 shopping-assistant 的清单中镜像名被写成裸名shoppingassistantservice这是因为 Skaffold/Kustomize 在渲染时会用--default-repo自动补全镜像仓库前缀——这也是部署命令必须携带--default-repo参数的原因。六、步骤 5将组件注册到根kustomization.yaml编辑根目录的 kustomize/kustomization.yaml把新组件加入components:列表使其进入部署流水线apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization resources: - base components: # - components/cymbal-branding # - components/google-cloud-operations # - components/alloydb - components/shopping-assistant # ← 取消注释即可启用你的组件 # - components/spanner # 下面这些必须最后执行且保持顺序 # - components/container-images-tag # - components/container-images-tag-suffix # - components/container-images-registry从仓库注释可以读出三条关键规则默认关闭、按需启用大多数组件以注释形式存在避免默认部署引入外部依赖如 AlloyDB、Spanner 等存在顺序依赖container-images-tag、container-images-tag-suffix、container-images-registry等镜像改写类组件必须最后执行且保持顺序组件可叠加shopping-assistant与alloydb配套使用AI 助手依赖 AlloyDB 商品目录说明组件之间存在组合关系。另外注意 kubernetes-manifests/kustomization.yaml 是另一份被skaffold.yaml直接引用的清单同样预留了components:的注释位——两份文件需要保持一致具体取决于你使用哪套渲染入口。七、步骤 6将服务注册到根skaffold.yamlSkaffold 是 Online Boutique 的构建与部署编排核心参考 docs/development-guide.md。在根目录 skaffold.yaml 中完成两处注册① 在build.artifacts中声明镜像构建产物每个 artifact 由image镜像名与context构建上下文即src/下的目录组成build: platforms: [linux/amd64, linux/arm64] artifacts: - image: emailservice context: src/emailservice - image: productcatalogservice context: src/productcatalogservice # ... 其他服务 - image: shoppingassistantservice # ← 你的新服务 context: src/shoppingassistantservice # ... tagPolicy: gitCommit: {} local: useDockerCLI: true useBuildkit: true从仓库可以观察到两个例外处理的模式cartservice的context指向src/cartservice/src并单独指定了docker.dockerfile: Dockerfile见 skaffold.yamlloadgenerator不在主 Config 中而是作为独立的第二个 Configname: loadgenerator通过requires: [app]依赖主配置使用rawYaml直接引用 kubernetes-manifests/loadgenerator.yaml。② 确认manifests引用了你的清单主 Config 使用kustomize.paths指向kubernetes-manifests目录因此只需在 kubernetes-manifests/kustomization.yaml 的resources列表中追加你的service.yaml即可被自动拾取。此外仓库的 skaffold.yaml 还展示了可选的 profiles 机制gcb将构建转移到 Google Cloud Build磁盘 300GB、N1_HIGHCPU_32机器、4000s 超时debug替换 cartservice 的 Dockerfile 以支持调试network-policies通过 patch 追加 Kustomize 路径——如果新服务需要特殊构建参数可以仿照这些 profile 定义。八、步骤 7更新 Helm Chart 模板与默认值Online Boutique 同时提供 Helm 部署方式需要把新服务同步到 helm-chart/ 中改动点有三处① 新增模板文件在 helm-chart/templates/ 下创建service.yaml。以 emailservice.yaml 为模板它展示了 Online Boutique Helm 模板的完整骨架用{{- if .Values.emailService.create }}控制是否渲染该服务Deployment 内通过{{ .Values.images.repository }}/{{ .Values.emailService.name }}:{{ .Values.images.tag | default .Chart.AppVersion }}拼装镜像地址条件渲染 ServiceAccount、NetworkPolicynetworkPolicies.create、Istio Sidecarsidecars.create与 AuthorizationPolicyauthorizationPolicies.create——这正是 Chart.yaml 中version: 0.10.6/appVersion: v0.10.6所配套的功能开关体系。② 在 values.yaml 中增加配置块。既有服务的 values 结构高度一致例如emailService: create: true name: emailservice resources: requests: cpu: 100m memory: 64Mi limits: cpu: 200m memory: 128Mi新服务应仿照此结构增加serviceName:配置块create、name、resources为必填字段如需接入 OpenTelemetry、Cloud Profiler 等可观测能力还需配合模板中opentelemetryCollector.create、googleCloudOperations.*等全局开关。③ 更新 Chart 元数据参考 docs/releasing/make-helm-chart.sh 的做法发布时用gsed将新版本号写入Chart.yaml的appVersion与version然后helm package .打包、helm push推送。九、步骤 8更新项目文档最后同步更新项目文档官方文档列出的可选项包括若新服务带来显著新功能在根 README.md 增加章节更新 docs/img/ 目录下的架构图若服务需要详细解释在docs/目录新增独立文档。仓库中的范例是 kustomize/components/shopping-assistant/README.md它用一整页篇幅说明了服务的背景RAG 购物助手 AlloyDB、完整的 GCP 前置准备创建 GKE Autopilot 集群、Artifact Registry 仓库、运行 1_deploy_alloydb_infra.sh 部署基础设施、通过 generate_sql_from_products.py 将 src/productcatalogservice/products.json 灌入 AlloyDB、API Key 配置以及最终部署命令。经验法则任何需要外部基础设施、多步初始化或特殊环境变量的服务都应在组件目录内提供配套 README 与初始化脚本。十、端到端验证构建、部署与清理完成上述 8 步后按以下顺序验证# 1. 本地渲染检查确认 Kustomize 正确聚合你的组件 kubectl kustomize kubernetes-manifests # 2. 本地集群部署首次构建较慢约 20 分钟见 docs/development-guide.md skaffold run # 3. 开发模式代码改动自动触发重建 skaffold dev # 4. 验证 Pod 与前端入口 kubectl get pods kubectl port-forward deployment/frontend 8080:8080 # 5. GKE 场景推送镜像到 Artifact Registry 并部署 skaffold run --default-repous-docker.pkg.dev/PROJECT_ID/microservices-demo # 6. 清理 skaffold delete仓库中的 cloudbuild.yaml 展示了 CI 集成方式Cloud Build 使用gcr.io/k8s-skaffold/skaffold镜像获取 GKE 凭据后执行skaffold run --default-repogcr.io/$PROJECT_ID整个构建在N1_HIGHCPU_8机器上、3600s 超时内完成。而 docs/releasing/make-docker-images.sh 则提供了另一个视角——它会自动遍历src/下所有目录逐一构建推送镜像这意味着只要你的服务目录命名规范、Dockerfile 齐备发布脚本无需改动即可覆盖新服务。十一、关键实践清单与注意事项命名一致性目录名、镜像名、Kubernetes 资源名、Helm values key 应完全一致否则会在skaffold镜像补全或 Helm 渲染时出现隐性断裂镜像名与仓库解耦清单中写裸镜像名仓库前缀由--default-repo在部署时注入切勿硬编码仓库地址除非在container-images-registry组件中统一管理见 kustomize/components/container-images-registry/README.md安全基线默认启用runAsNonRoot、drop: [ALL]、allowPrivilegeEscalation: false这是所有服务清单的公共安全模板端口与探针容器内统一监听8080Service 端口 80 → 8080探针周期 5s保持与既有服务一致资源配额新服务先采用100m/64Mirequest与200m/128Milimit的默认档位再根据压测结果调整组件顺序镜像改写类组件必须位于components:列表最后且彼此保持tag → tag-suffix → registry的顺序可选项与核心服务分离官方在 docs/development-guide.md 中明确指出核心微服务集合已基本稳定新增服务应作为可选组件存在——这也解释了为什么shopping-assistant在根 kustomization 中默认被注释需配合 AlloyDB 组件手动启用。通过以上流程你可以在保持 Online Boutique 既有架构规范、安全基线与可观测性能力的前提下以最小成本将新的微服务平滑融入这套云原生示例系统。【免费下载链接】microservices-demoSample cloud-first application with 10 microservices showcasing Kubernetes, Istio, and gRPC.项目地址: https://gitcode.com/GitHub_Trending/mi/microservices-demo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Online Boutique 微服务扩展指南：为 microservices-demo 添加新服务的完整流程
Online Boutique 微服务扩展指南为 microservices-demo 添加新服务的完整流程【免费下载链接】microservices-demoSample cloud-first application with 10 microservices showcasing Kubernetes, Istio, and gRPC.项目地址: https://gitcode.com/GitHub_Trending/mi/microservices-demo导读本文以 Google Cloud 开源示例应用 Online Boutiquemicroservices-demo的官方文档 docs/adding-new-microservice.md 为主线系统讲解如何向这个由 10 个微服务组成的云原生电商系统添加第 11 个微服务。你将掌握从src/源码目录创建、Dockerfile 容器化到 Kustomize 组件注册、Skaffold 构建清单、Helm Chart 模板同步再到文档更新的完整 8 步落地流程并学会以仓库中真实存在的shoppingassistantserviceAI 购物助手为例进行端到端实践。图为 Online Boutique 的微服务架构总览新添加的服务需要作为独立节点融入这套 gRPC 服务网格之中。一、前置认知Online Boutique 的两套清单 一套图表机制在动手添加微服务之前先理解这个仓库的组织方式。从仓库根目录看每个微服务都以src/service-name/目录为圆心向外辐射三套注册信息文件/目录作用说明src/service/源码 Dockerfile服务的唯一代码来源构建镜像的上下文kustomize/components/service/Kustomize 组件清单可选组件通过components:字段挂载到基础层之上kubernetes-manifests/service.yaml基础部署清单被skaffold.yaml直接引用的默认部署资源helm-chart/templates/service.yamlHelm 模板提供 Helm 方式部署时的渲染模板skaffold.yaml构建与部署编排声明镜像构建 artifact 与 manifest 来源cloudbuild.yamlCI 流水线在 GKE 上调用 skaffold 完成一键部署添加一个新微服务本质就是让这个服务在这三套系统中都有名有姓。仓库中的 shoppingassistantservice基于 AlloyDB 的 RAG 购物助手正是官方文档点名推荐的参考范例下文将围绕它展开。二、步骤 1在src/下创建服务目录在src/目录中新建一个与微服务同名的目录例如src/shoppingassistantservice/。目录名即服务名它会贯穿镜像名、Kubernetes 资源名、Helm values key 的全部命名链路因此建议统一使用小写驼峰式命名。查看现有服务的目录结构可以观察到两个惯例大多数服务目录直接包含源码与构建文件例如 src/emailservice/Python个别服务存在一层嵌套如 src/cartservice/ 将 C# 工程放在src/cartservice/src/下——这一点在 docs/releasing/make-docker-images.sh 中有专门的分支处理说明发布脚本默认假设构建目录与目录名一一对应特殊结构需要特殊处理。三、步骤 2添加源码遵循既有服务的目录约定将服务源码放入新目录结构应遵循既有微服务的约定。官方文档以 Python 服务为例给出了最小文件集README.md服务的描述与文档main.py应用入口点requirements.inPython 依赖清单Dockerfile容器化构建文件。以仓库中的真实 Python 服务为参照shoppingassistantservice的目录结构如下src/shoppingassistantservice/shoppingassistantservice.py主程序对应main.py的约定requirements.in声明式依赖清单内容为flask、langchain、langchain-google-genai、langchain-google-alloydb-pg、google-cloud-secret-manager、pillow等见 requirements.inrequirements.txt由requirements.in生成、含固定版本号的锁定文件供 Dockerfile 安装Dockerfile容器化构建文件。同样地src/emailservice/ 的结构也印证了这一约定email_server.py为入口、requirements.in声明grpcio、google-cloud-profiler等依赖、templates/存放邮件模板。惯用约定入口文件、依赖清单、Dockerfile 三者齐备是任何语言实现的服务进入 Online Boutique 的门槛Go 服务如 src/frontend/则以go.mod、genproto.sh用于生成 gRPC 桩代码等文件对应这一约定。四、步骤 3创建 Dockerfile在服务目录中创建Dockerfile定义容器镜像的构建步骤。官方文档推荐参考 src/frontend/Dockerfile 并按需调整。不过对 Python 服务而言shoppingassistantservice的 Dockerfile 是更贴切的模板其关键设计点包括# 定义默认构建平台避免跨平台构建时为空 ARG BUILDPLATFORMlinux/amd64 # 使用固定 digest 的 base 镜像保证可复现 FROM --platform$BUILDPLATFORM python:3.14.6-slimsha256:b877e50bd... AS base # builder 阶段安装编译依赖并预装 Python 包 FROM base AS builder RUN apt-get -qq update \ apt-get install -y --no-install-recommends g \ rm -rf /var/lib/apt/lists/* COPY requirements.txt . RUN pip install -r requirements.txt # 运行阶段只复制已装好的包与应用代码镜像更精简 FROM base ENV PYTHONUNBUFFERED1 WORKDIR /shoppingassistantservice COPY --frombuilder /usr/local/lib/python3.14/ /usr/local/lib/python3.14/ COPY . . ENV PORT8080 EXPOSE 8080 ENTRYPOINT [python, shoppingassistantservice.py]值得学习的实践多阶段构建builder阶段安装g等编译工具运行阶段不保留这些工具显著缩小镜像体积固定 digestpython:3.14.6-slimsha256:...锁定镜像内容保证每次构建的可复现性统一端口约定Online Boutique 所有服务默认监听8080容器内由环境变量PORT控制——这一点被 kubernetes-manifests 中的 emailservice 清单 以及 helm-chart/templates/emailservice.yaml 的- name: PORT value: 8080反复印证。五、步骤 4创建 Kubernetes manifestsKustomize 组件在仓库根目录的kustomize/components/下为你的微服务新建一个组件目录放入必要的 Kubernetes YAML 文件。通常至少包含Deployment管理服务的 Pod 副本Service将微服务暴露给集群内其他服务。以 kustomize/components/shopping-assistant/ 为例其组件由 kustomization.yaml 组织resources引入shoppingassistantservice.yamlpatches则通过 Strategic Merge Patch 给frontend的 Deployment 注入ENABLE_ASSISTANTtrue环境变量——这演示了新服务除了自成一派还可能通过 patch 反向影响既有服务的高级用法。组件内的 shoppingassistantservice.yaml 是一个完整的参考实现值得逐段拆解Deploymentmetadata.name、selector.matchLabels、template.labels统一使用app: shoppingassistantservicesecurityContext设置runAsNonRoot: true、runAsUser: 1000容器级securityContext设置allowPrivilegeEscalation: false并drop: [ALL]端口与探针containerPort: 8080配合readinessProbe/livenessProbegRPC 或 HTTP 探针见 kubernetes-manifests/emailservice.yaml 的periodSeconds: 5资源配额requests: cpu 100m / memory 64Milimits: cpu 200m / memory 128Mi这是仓库所有服务的标准资源档位Servicetype: ClusterIPport: 80映射targetPort: 8080供集群内部服务发现ServiceAccount配合 Workload Identity 注解iam.gke.io/gcp-service-account实现最小权限访问云资源。注意官方文档强调 Deployment 中指定的镜像必须与cloudbuild.yaml和skaffold.yaml中构建的镜像一致。在 shopping-assistant 的清单中镜像名被写成裸名shoppingassistantservice这是因为 Skaffold/Kustomize 在渲染时会用--default-repo自动补全镜像仓库前缀——这也是部署命令必须携带--default-repo参数的原因。六、步骤 5将组件注册到根kustomization.yaml编辑根目录的 kustomize/kustomization.yaml把新组件加入components:列表使其进入部署流水线apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization resources: - base components: # - components/cymbal-branding # - components/google-cloud-operations # - components/alloydb - components/shopping-assistant # ← 取消注释即可启用你的组件 # - components/spanner # 下面这些必须最后执行且保持顺序 # - components/container-images-tag # - components/container-images-tag-suffix # - components/container-images-registry从仓库注释可以读出三条关键规则默认关闭、按需启用大多数组件以注释形式存在避免默认部署引入外部依赖如 AlloyDB、Spanner 等存在顺序依赖container-images-tag、container-images-tag-suffix、container-images-registry等镜像改写类组件必须最后执行且保持顺序组件可叠加shopping-assistant与alloydb配套使用AI 助手依赖 AlloyDB 商品目录说明组件之间存在组合关系。另外注意 kubernetes-manifests/kustomization.yaml 是另一份被skaffold.yaml直接引用的清单同样预留了components:的注释位——两份文件需要保持一致具体取决于你使用哪套渲染入口。七、步骤 6将服务注册到根skaffold.yamlSkaffold 是 Online Boutique 的构建与部署编排核心参考 docs/development-guide.md。在根目录 skaffold.yaml 中完成两处注册① 在build.artifacts中声明镜像构建产物每个 artifact 由image镜像名与context构建上下文即src/下的目录组成build: platforms: [linux/amd64, linux/arm64] artifacts: - image: emailservice context: src/emailservice - image: productcatalogservice context: src/productcatalogservice # ... 其他服务 - image: shoppingassistantservice # ← 你的新服务 context: src/shoppingassistantservice # ... tagPolicy: gitCommit: {} local: useDockerCLI: true useBuildkit: true从仓库可以观察到两个例外处理的模式cartservice的context指向src/cartservice/src并单独指定了docker.dockerfile: Dockerfile见 skaffold.yamlloadgenerator不在主 Config 中而是作为独立的第二个 Configname: loadgenerator通过requires: [app]依赖主配置使用rawYaml直接引用 kubernetes-manifests/loadgenerator.yaml。② 确认manifests引用了你的清单主 Config 使用kustomize.paths指向kubernetes-manifests目录因此只需在 kubernetes-manifests/kustomization.yaml 的resources列表中追加你的service.yaml即可被自动拾取。此外仓库的 skaffold.yaml 还展示了可选的 profiles 机制gcb将构建转移到 Google Cloud Build磁盘 300GB、N1_HIGHCPU_32机器、4000s 超时debug替换 cartservice 的 Dockerfile 以支持调试network-policies通过 patch 追加 Kustomize 路径——如果新服务需要特殊构建参数可以仿照这些 profile 定义。八、步骤 7更新 Helm Chart 模板与默认值Online Boutique 同时提供 Helm 部署方式需要把新服务同步到 helm-chart/ 中改动点有三处① 新增模板文件在 helm-chart/templates/ 下创建service.yaml。以 emailservice.yaml 为模板它展示了 Online Boutique Helm 模板的完整骨架用{{- if .Values.emailService.create }}控制是否渲染该服务Deployment 内通过{{ .Values.images.repository }}/{{ .Values.emailService.name }}:{{ .Values.images.tag | default .Chart.AppVersion }}拼装镜像地址条件渲染 ServiceAccount、NetworkPolicynetworkPolicies.create、Istio Sidecarsidecars.create与 AuthorizationPolicyauthorizationPolicies.create——这正是 Chart.yaml 中version: 0.10.6/appVersion: v0.10.6所配套的功能开关体系。② 在 values.yaml 中增加配置块。既有服务的 values 结构高度一致例如emailService: create: true name: emailservice resources: requests: cpu: 100m memory: 64Mi limits: cpu: 200m memory: 128Mi新服务应仿照此结构增加serviceName:配置块create、name、resources为必填字段如需接入 OpenTelemetry、Cloud Profiler 等可观测能力还需配合模板中opentelemetryCollector.create、googleCloudOperations.*等全局开关。③ 更新 Chart 元数据参考 docs/releasing/make-helm-chart.sh 的做法发布时用gsed将新版本号写入Chart.yaml的appVersion与version然后helm package .打包、helm push推送。九、步骤 8更新项目文档最后同步更新项目文档官方文档列出的可选项包括若新服务带来显著新功能在根 README.md 增加章节更新 docs/img/ 目录下的架构图若服务需要详细解释在docs/目录新增独立文档。仓库中的范例是 kustomize/components/shopping-assistant/README.md它用一整页篇幅说明了服务的背景RAG 购物助手 AlloyDB、完整的 GCP 前置准备创建 GKE Autopilot 集群、Artifact Registry 仓库、运行 1_deploy_alloydb_infra.sh 部署基础设施、通过 generate_sql_from_products.py 将 src/productcatalogservice/products.json 灌入 AlloyDB、API Key 配置以及最终部署命令。经验法则任何需要外部基础设施、多步初始化或特殊环境变量的服务都应在组件目录内提供配套 README 与初始化脚本。十、端到端验证构建、部署与清理完成上述 8 步后按以下顺序验证# 1. 本地渲染检查确认 Kustomize 正确聚合你的组件 kubectl kustomize kubernetes-manifests # 2. 本地集群部署首次构建较慢约 20 分钟见 docs/development-guide.md skaffold run # 3. 开发模式代码改动自动触发重建 skaffold dev # 4. 验证 Pod 与前端入口 kubectl get pods kubectl port-forward deployment/frontend 8080:8080 # 5. GKE 场景推送镜像到 Artifact Registry 并部署 skaffold run --default-repous-docker.pkg.dev/PROJECT_ID/microservices-demo # 6. 清理 skaffold delete仓库中的 cloudbuild.yaml 展示了 CI 集成方式Cloud Build 使用gcr.io/k8s-skaffold/skaffold镜像获取 GKE 凭据后执行skaffold run --default-repogcr.io/$PROJECT_ID整个构建在N1_HIGHCPU_8机器上、3600s 超时内完成。而 docs/releasing/make-docker-images.sh 则提供了另一个视角——它会自动遍历src/下所有目录逐一构建推送镜像这意味着只要你的服务目录命名规范、Dockerfile 齐备发布脚本无需改动即可覆盖新服务。十一、关键实践清单与注意事项命名一致性目录名、镜像名、Kubernetes 资源名、Helm values key 应完全一致否则会在skaffold镜像补全或 Helm 渲染时出现隐性断裂镜像名与仓库解耦清单中写裸镜像名仓库前缀由--default-repo在部署时注入切勿硬编码仓库地址除非在container-images-registry组件中统一管理见 kustomize/components/container-images-registry/README.md安全基线默认启用runAsNonRoot、drop: [ALL]、allowPrivilegeEscalation: false这是所有服务清单的公共安全模板端口与探针容器内统一监听8080Service 端口 80 → 8080探针周期 5s保持与既有服务一致资源配额新服务先采用100m/64Mirequest与200m/128Milimit的默认档位再根据压测结果调整组件顺序镜像改写类组件必须位于components:列表最后且彼此保持tag → tag-suffix → registry的顺序可选项与核心服务分离官方在 docs/development-guide.md 中明确指出核心微服务集合已基本稳定新增服务应作为可选组件存在——这也解释了为什么shopping-assistant在根 kustomization 中默认被注释需配合 AlloyDB 组件手动启用。通过以上流程你可以在保持 Online Boutique 既有架构规范、安全基线与可观测性能力的前提下以最小成本将新的微服务平滑融入这套云原生示例系统。【免费下载链接】microservices-demoSample cloud-first application with 10 microservices showcasing Kubernetes, Istio, and gRPC.项目地址: https://gitcode.com/GitHub_Trending/mi/microservices-demo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考