超级会员免费看
使用 Argo CD 进行 GitOps 部署及微服务变更管理
1. Argo CD 简介与登录
在之前，我们创建了 Helm 图表，它为我们将微服务部署到 Kubernetes 集群提供了更便捷的方式。Helm 具备向 Kubernetes 集群进行部署的能力，我们已经有足够的条件将航班信息服务部署到暂存环境中。然而，目前的部署方式非常手动，每次部署都需要使用 Helm CLI，并且我们还需要跟踪已部署服务的当前状态和版本，以便在部署仓库更新时确定是否需要进行新的部署。
Argo CD 是一个 GitOps 部署工具，它将 Git 仓库作为工作负载和服务所需部署状态的来源。当它检查我们指定的仓库时，会判断我们定义的目标状态是否与环境中的运行状态匹配。如果不匹配，Argo CD 可以“同步”部署，使其与我们在 Helm 图表中声明的内容一致。
在使用 Argo CD 之前，我们需要登录。具体步骤如下：
-
获取管理员密码
：Argo CD 将默认密码设置为其运行所在的 Kubernetes 对象的名称。运行以下 kubectl 命令查找 Argo CD Pod：
$ kubectl get pods -n "argocd" | grep argocd-server
例如，输出结果可能如下：
NAME READY STATUS RESTARTS AGE
msur-argocd-server-c6d4ffcf-9z4c2 1/1 Running 0 51s
将 Pod 的名称复制下来，这将作为我们登录的密码。
-
设置端口转发
：为了访问登录页面并使用我们的凭证，需要设置端口转发规则。运行以下命令：
$ kubectl port-forward svc/msur-argocd-server 8443:443 -n "argocd"
输出结果可能如下：
Forwarding from 127.0.0.1:8443 -> 8080
Forwarding from [::1]:8443 -> 8080
-
登录 Argo CD
：现在可以在浏览器中访问
localhost:8443。可能会收到一个警告，提示该网站不可信，这是正常的。让浏览器继续访问，你将看到登录屏幕。输入admin作为用户 ID，并使用之前记录的密码登录。如果登录成功，你将看到一个仪表盘屏幕。
2. 同步和部署微服务
在 Argo CD 中，需要部署的微服务或工作负载被称为应用程序。要部署航班信息微服务，我们需要创建一个新的“应用程序”，并使用引用我们之前创建的 Git 仓库中 Helm 包的值进行配置。具体步骤如下：
-
创建应用程序
：在仪表盘屏幕上点击“Create Application”或“New App”按钮。点击后，一个网页表单将从屏幕右侧滑入，需要填写该表单。在这里，我们定义应用程序的元数据和 Helm 包的位置。我们希望 Argo CD 从部署单仓库及其内部的
ms-flights
目录中获取 Helm 包。
使用以下表格中的值来设置航班信息微服务的部署：
| 部分 | 键 | 值 |
| — | — | — |
| 常规 | 应用程序名称 | flight-info |
| 常规 | 项目 | default |
| 常规 | 同步策略 | manual |
| 源 | 仓库 URL | YOUR_DEPLOYMENTS_REPOSITORY_URL（请替换为实际的部署仓库 URL） |
| 源 | 路径 | ms-flights |
| 目标 | 集群 | in-cluster (https://kubernetes.default.svc) |
| 目标 | 命名空间 | microservices |
填写完表单后，点击“Create”按钮。如果遇到任何问题，可以参考 Argo CD 文档获取设置应用程序的说明。
-
同步应用程序
：如果成功创建了应用程序，Argo CD 将在仪表盘中列出
flight-info应用程序。但此时应用程序尚未与部署声明同步，集群中的flight-info应用程序与我们包中的描述不匹配，因为 Argo CD 尚未实际进行部署。要完成部署，点击刚刚创建的flight-info应用程序，点击“Sync”按钮，然后在滑入的窗口中点击“Synchronize”按钮。
3. 测试航班服务
航班微服务现在已经在 AWS 托管的暂存环境中运行。为了使用请求消息测试该服务，我们需要访问 Traefik 的负载均衡器，它将把我们的请求路由到容器化服务。具体步骤如下：
-
获取负载均衡器地址
：运行以下 kubectl 命令获取负载均衡器的网络地址：
$ kubectl get svc ms-traefik-ingress
输出结果可能如下：
NAME TYPE CLUSTER-IP EXTERNAL-IP
ms-traefik-ingress LoadBalancer 172.20.149.191 ab.elb.amazonaws.com
记录下
EXTERNAL-IP
，这是 Traefik 负载均衡器的地址。
-
发送测试请求
：使用
curl
发送测试请求消息到航班服务。运行以下
curl
命令（将
{TRAEFIK-EXTERNAL-IP}
替换为你的负载均衡器地址）：
curl --header "Host: flightsvc.com" \
{TRAEFIK-EXTERNAL-IP}/flights?flight_no=AA2532
如果一切顺利，你将以 JSON 格式的响应获得该航班的详细信息。你也可以使用专门的 API 测试工具（如 Postman 或 SoapUI）来获得更友好格式的响应消息。
4. 清理资源
为了避免为未使用的 AWS 资源付费，我们需要清理基础设施。使用本地 Terraform 客户端来拆除基础设施。确保你位于暂存 Terraform 文件所在的目录，并运行以下命令：
infra-staging-env $ terraform destroy
成功完成后，基于 Kubernetes 的暂存环境将被销毁。你可以使用 AWS CLI 或基于浏览器的 AWS 控制台检查资源是否已被销毁。
5. 微服务系统中的变更
在微服务系统中，变更应该是一个特性，而不是问题或错误。我们应该能够更改系统以使其更好，并从所构建的软件中获得更多价值。软件变更通常有外在驱动因素和内在驱动因素。
外在驱动因素
：
- 支持新产品发布
- 解决影响用户体验的逻辑错误
- 与新合作伙伴集成
内在驱动因素
：
- 拆分微服务以降低代码复杂度
- 重新部署基础设施以避免与基础设施代码出现偏差
- 优化 CI/CD 管道以更快地交付变更
为了从系统中获得最佳价值，我们需要同时规划和执行内在变更。采用持续改进思维的一个好方法是使用数据和测量来指导决策。
6. 以数据为导向
在软件开发中，过度设计和过早优化是常见问题。在微服务系统中也是如此，因此使用数据和测量来指导变更决策是个好主意。特别是对于内在改进，没有数据，我们只能猜测，可能会花费大量精力改进实际上不需要帮助的系统部分，而其他紧迫的问题区域可能会被忽视。
我们可以收集以下项目、设计和运行时指标，以更好地了解改进机会：
- 每个微服务的变更时间
- 每个微服务的变更频率
- 每个变更请求中更改的微服务数量
- 微服务中的代码行数（作为数据点，而非约束）
- 每个微服务的运行时延迟
- 微服务之间的依赖关系
这些分析指标可以让我们更全面地了解哪些地方可以进行改进，然后我们可以决定将精力投入到何处。当然，我们还需要平衡改进的可能性与变更带来的影响。
7. 变更的影响
软件变更可能会带来多种潜在影响，其中有四种对现代组织影响较大：
-
实施时间
：这是任何变更成本的核心部分，包括理解当前状态、进行所需更改、测试更改以及更新生产环境所需的时间。要更改的组件的可读性、可学习性和可维护性是影响实施时间的重要因素。
-
协调时间
：实施变更时，团队之间几乎总是需要进行某种形式的沟通。协调时间是实施时间的一部分，但值得单独强调。它可能包括获取资源访问权限、获得变更活动的许可和协议所花费的时间，以及在大型组织中工作产生的“组织摩擦”。协调时间通常与组织设计和结构有关。
-
停机时间
：停机时间是指系统或系统组件在进行变更时不可用的时间。过去，停机时间是软件变更过程中被接受的一部分，但现在技术团队面临着越来越大的压力，需要尽量减少变更所需的停机时间。在微服务系统中，通常追求“零停机”变更模型，即系统始终保持可用。
-
消费者影响
：这是一个常被忽视的影响，指变更对系统用户造成的成本。停机时间只是消费者影响的一种形式，即使在“零停机”模型中，也可能存在本可避免的高昂影响。例如，对基础设施模块的更改可能会对微服务开发团队产生广泛影响，对接口的更改可能会破坏使用该接口的每个组件的代码。
软件架构在变更的成本和影响中起着重要作用，而变更的应用方式也是其中的一部分。微服务架构、云基础设施和 DevOps 实践推动了一些先进的实践，下面介绍三种部署模式。
8. 三种部署模式
8.1 蓝绿部署
在蓝绿部署中，会维护两个并行的环境。一个环境处于活动状态并接收流量，另一个环境处于空闲状态。变更应用到空闲环境，准备好后，将流量路由到已更改的环境。两个环境交换角色，空闲环境变为活动环境，活动环境变为空闲环境，为下一次变更做准备。
这种部署模式的优点是可以在生产环境中安全地进行更改，切换流量意味着无需在活动系统中重复更改。该模式的关键是两个环境在活动和空闲之间互换角色，而环境的实际颜色并不重要。它可以大大减少停机时间，甚至实现零停机模型。但维护两个环境需要谨慎处理数据库等持久系统，持久的、不断变化的数据需要进行同步、复制或完全在蓝绿模型之外进行维护。
8.2 金丝雀部署
金丝雀部署与蓝绿部署类似，但不是维护两个完整的环境，而是并行发布两个组件。在这种模式中，新发布的版本就像“煤矿中的金丝雀”，能提前警示危险。例如，要对一个 Web 应用程序进行金丝雀部署，会在原 Web 应用程序继续运行的同时发布一个新的金丝雀版本。
与蓝绿模式一样，金丝雀部署需要流量管理和路由逻辑。部署应用程序的新版本后，部分流量会被路由到新版本。到达金丝雀版本的流量可以是总负载的一定百分比，也可以基于唯一的标头或特殊标识符。随着时间的推移，更多的流量会被路由到金丝雀版本，直到它最终晋升为正式生产状态。
金丝雀部署的优点是更细粒度，我们可以专注于较小的、有边界的变更，并在运行的系统中进行这些变更。但如果部署的金丝雀版本影响到系统的其他部分，可能会导致问题。例如，如果金丝雀部署以新的方式改变了共享系统资源，即使只处理 1% 的流量也可能产生灾难性影响。在为独立部署而设计的系统中，金丝雀模式可以很好地工作。
8.3 多版本部署
多版本部署模式将用户和客户端视为变更过程的一部分，即并行运行多个版本。前面提到的蓝绿部署和金丝雀部署模式也会临时并行运行实例（有时称为扩展和收缩模式），但在这两种情况下，通常会私下运行新旧实例，不与外界共享详细信息。而多版本部署模式则考虑了用户和客户端在变更过程中的参与。
以下是这三种部署模式的对比表格：
| 部署模式 | 环境数量 | 流量切换方式 | 优点 | 缺点 |
| — | — | — | — | — |
| 蓝绿部署 | 2 个并行环境 | 直接切换 | 安全更改，可实现零停机 | 需处理持久系统同步 |
| 金丝雀部署 | 并行发布组件 | 逐步增加流量 | 细粒度变更，提前发现问题 | 可能影响其他部分 |
| 多版本部署 | 并行运行多个版本 | 按需分配流量 | 考虑用户参与 | 管理复杂度较高 |
通过上述对 Argo CD 的使用和微服务系统变更管理的介绍，我们可以更高效地部署和管理微服务系统，同时更好地应对系统中的各种变更。
使用 Argo CD 进行 GitOps 部署及微服务变更管理
9. 部署模式的选择与应用场景
不同的部署模式适用于不同的场景，我们需要根据具体的需求和系统特点来选择合适的部署模式。以下是一个简单的决策流程图：
graph TD;
A[是否需要零停机部署?] -->|是| B[是否可以维护两个完整环境?];
A -->|否| C[是否需要细粒度变更测试?];
B -->|是| D[蓝绿部署];
B -->|否| C;
C -->|是| E[金丝雀部署];
C -->|否| F[多版本部署];
- 蓝绿部署的应用场景 ：当系统对停机时间非常敏感，且有足够的资源来维护两个完整的环境时，蓝绿部署是一个不错的选择。例如，对于一些大型的电商网站，在进行重大功能更新时，为了避免影响用户体验，可以采用蓝绿部署，确保在更新过程中用户始终能够正常访问网站。
- 金丝雀部署的应用场景 ：如果我们需要对新功能进行小规模的测试，以验证其稳定性和性能，金丝雀部署就非常合适。比如，在推出一个新的推荐算法时，可以先将少量流量导向新算法，观察用户的反馈和系统的运行情况，再决定是否全面推广。
- 多版本部署的应用场景 ：当系统需要同时支持不同版本的客户端或用户时，多版本部署是必要的。例如，某些软件可能有不同版本的 API，为了保证旧版本的客户端仍然能够正常使用，就需要并行运行多个版本的服务。
10. 持续改进与变更管理流程
为了更好地管理微服务系统中的变更，我们可以建立一个持续改进的变更管理流程。以下是一个简单的流程说明：
- 数据收集与分析 ：定期收集系统的各项指标，如微服务的变更时间、变更频率、运行时延迟等。使用数据分析工具对这些指标进行深入分析，找出系统中存在的问题和改进的机会。
- 变更决策 ：根据数据分析的结果，制定变更计划。考虑变更的成本、影响范围和预期收益，选择合适的部署模式。
- 变更实施 ：按照变更计划进行部署，使用 Argo CD 等工具确保变更的顺利进行。在部署过程中，密切监控系统的运行状态，及时发现并解决问题。
- 验证与反馈 ：部署完成后，对系统进行全面的测试和验证，确保变更达到了预期的效果。收集用户的反馈意见，评估变更对用户的影响。
- 持续优化 ：根据验证和反馈的结果，对系统进行进一步的优化和调整。将成功的变更经验纳入到系统的标准流程中，不断提高系统的稳定性和性能。
11. 示例：使用金丝雀部署优化航班服务
假设我们要对航班服务进行一次优化，提高其响应速度。我们可以采用金丝雀部署的方式，具体步骤如下：
- 准备金丝雀版本 ：在代码仓库中创建一个新的分支，对航班服务的代码进行优化。将优化后的代码打包成 Docker 镜像，并推送到镜像仓库。
- 配置 Argo CD 应用程序 ：在 Argo CD 中创建一个新的应用程序，指向金丝雀版本的代码仓库。设置同步策略为手动，确保我们可以控制部署的时机。
- 设置流量路由 ：使用 Traefik 等负载均衡器，将少量流量（如 10%）导向金丝雀版本的航班服务。可以通过设置路由规则，根据用户的 IP 地址或请求头来决定流量的分配。
- 监控与评估 ：密切监控金丝雀版本的运行状态，收集各项指标，如响应时间、错误率等。与旧版本进行对比，评估优化的效果。
- 逐步扩大流量 ：如果金丝雀版本运行稳定，且性能得到了明显提升，可以逐步增加导向金丝雀版本的流量，直到全部流量都切换到新的版本。
- 清理与合并 ：部署完成后，删除金丝雀版本的代码分支和相关资源。将优化后的代码合并到主分支，确保后续的部署都使用新的版本。
12. 总结
通过使用 Argo CD 进行 GitOps 部署，我们可以实现微服务的自动化部署和同步，提高部署的效率和可靠性。同时，了解微服务系统中的变更类型、影响和部署模式，能够帮助我们更好地管理系统的变更，降低变更成本，提高系统的稳定性和性能。
在实际应用中，我们应该以数据为导向，根据系统的实际情况选择合适的部署模式和变更管理策略。持续收集和分析系统的指标，不断优化系统的架构和流程，以适应不断变化的业务需求。通过建立一个完善的变更管理体系，我们可以确保微服务系统始终保持高效、稳定的运行。
总之，微服务系统的成功不仅仅取决于技术的选择，更在于对变更的有效管理和持续改进。希望这些知识和实践经验能够帮助你更好地构建和管理微服务系统。
扫一扫
1357
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
