26、微服务交付与监控:构建高效可靠的系统

微服务交付与监控实践

微服务交付与监控:构建高效可靠的系统

1. 构建可复用的管道步骤

在之前的实践中,我们已经在一些领域应用了相关思路,例如:
- 使用微服务框架来抽象通用的非业务逻辑功能,如监控和服务发现。
- 使用 Docker 容器作为标准化的服务制品进行部署。
- 使用 Kubernetes 容器调度器作为通用的部署平台。

我们也可以将这种方法应用到部署管道中。

1.1 过程式与声明式构建管道

目前编写的管道脚本存在三个弱点:
1. 特定性 :它们与单个仓库绑定,其他仓库无法共享。
2. 过程式 :它们明确描述了构建的执行方式。
3. 未抽象内部细节 :它们假设了很多关于 Jenkins 本身的知识,如如何启动节点、运行命令和使用命令行工具。

理想情况下,服务部署管道应该是声明式的。工程师只需描述他们期望发生的事情(如测试服务、发布服务等),框架会决定如何执行这些步骤。这种方法还能抽象出步骤执行方式的变化。如果要调整某个步骤的工作方式,只需更改底层框架的实现。将这些实现决策从单个服务中抽象出来,可提高微服务应用的一致性。

以下是一个声明式构建管道的示例:

service {
  name('market-data')
  stages {
    build()
    test(command: 'python setup.py test', results: 'results.xml')
    publish()
    deploy()
  }
}

这个脚本定义了一些通用配置(服务名称)和一系列步骤(构建、测试、发布、部署),并向服务开发者隐藏了执行这些步骤的复杂性。这使得任何工程师都能快速遵循最佳实践,可靠且快速地将新服务投入生产。

使用 Jenkins Pipeline,可以使用共享库来实现声明式管道。相关示例管道库可在 这里 找到,Jenkins 文档 这里 提供了使用共享库的详细参考。

需要注意的是,在其他构建工具(如 Travis CI 或 DroneCI)中,使用 YAML 文件声明构建配置。这些方法很不错,特别是当需求相对简单时。相反,使用动态语言构建领域特定语言(DSL)可以提供更高的灵活性和可扩展性。

1.2 低影响部署和功能发布技术

在微服务应用中,区分部署(更新生产环境中运行的软件版本)和向客户或消费服务发布新功能这两个概念很重要。可以使用暗发布和功能开关这两种技术来完善持续交付管道,这些技术能让我们在不影响客户的情况下部署新功能,并提供灵活的回滚机制。

1.2.1 暗发布

暗发布是指在将服务提供给消费者之前,先将其部署到生产环境。公司通常会在构建新服务的最初几天内进行部署,无论服务功能是否完整。这样可以从早期阶段进行探索性测试,帮助我们了解服务的行为,并让内部协作者看到新服务。

此外,将服务暗发布到生产环境可以让我们根据真实的生产流量来测试服务。例如,SimpleBank 想提供一种新的金融预测算法服务。通过将生产流量与现有服务并行传递,他们可以轻松地对新算法进行基准测试,了解其在现实世界中的表现,而不是在有限的人工测试场景下测试。

是否手动或自动验证输出取决于功能的性质以及充分覆盖可能场景所需的请求量和分布。暗发布方法对于测试重构是否会导致敏感功能退化也很有用。

1.2.2 功能开关

功能开关控制功能对客户的可用性。与暗发布不同,功能开关可以在服务生命周期的任何阶段使用,如功能发布时。功能开关(或切换器)将功能包装在条件逻辑中,仅为特定用户组启用该功能。许多公司会使用它们来控制功能的推出,例如先仅向内部员工发布功能,或随着时间逐步增加可访问该功能的用户数量。

有几个库可用于实现功能开关,如 Flipper Togglz 。这些库通常使用持久化存储(如 Redis)来维护应用的功能开关状态。在大型微服务应用中,可能希望有一个单一的功能存储来同步涉及多个服务交互的功能推出,而不是为每个服务独立管理功能。

功能开关可以通过控制哪些用户看到更改,帮助最小化任何更改对系统的潜在影响,因为我们可以部分控制代码执行和功能可用性。如果出现错误,功能开关通常比典型的回滚方式能更快地恢复。对于微服务,它们可以在不影响服务消费者的情况下更安全地发布新功能。

2. 构建监控系统

部署服务后,我们需要了解它们的实际运行情况。接下来将构建一个监控系统,通过收集指标、跟踪和日志,深入了解微服务应用。

2.1 强大的监控堆栈

强大的监控堆栈可以让我们从服务和基础设施中收集指标,并利用这些指标深入了解系统的运行情况。它应该提供收集、存储、显示和分析数据的方法。

即使没有监控基础设施,也应该从服务中发出指标。如果存储了这些指标,随时都可以访问、显示和解释它们。可观测性是一项持续的工作,监控是其中的关键要素。监控可以让我们知道系统是否正常工作,而可观测性则让我们了解系统为何不能正常工作。

本章将重点关注监控、指标和警报。日志和跟踪将在后续内容中解释,它们构成了可观测性的组成部分。监控不仅可以让我们预测或应对问题,还可以使用监控收集的指标来预测系统行为或为业务分析提供数据。

设置监控解决方案有多种开源和商业选项。根据团队规模和可用资源,商业解决方案可能更易于使用。不过,这里将使用开源工具来构建自己的监控系统。监控堆栈将由指标收集器、显示和警报组件组成。日志和跟踪对于实现系统的可观测性也至关重要。

监控堆栈的组件如下:
| 组件 | 作用 |
| ---- | ---- |
| 指标 | 用于监控系统 |
| 日志 | 用于实现可观测性 |
| 跟踪 | 用于实现可观测性 |

每个组件将数据聚合到各自的仪表板中,这使我们能够设置自动警报,并查看所有收集的数据以调查问题或更好地了解系统行为。

2.2 良好的监控是分层的

在架构中,包括客户端、边界、服务和平台等层级。我们应该在所有这些层级中实施监控,因为不能孤立地确定某个组件的行为。网络问题很可能会影响服务。如果仅在服务级别收集指标,我们只能知道服务本身没有处理请求,但这无法告诉我们问题的原因。如果还在基础设施级别收集指标,就能了解可能影响多个其他组件的问题。

例如,在一个允许客户端进行股票买卖下单的系统中,涉及多个服务。服务之间的通信有些是同步的(通过 RPC 或 HTTP),有些是异步的(使用事件队列)。为了了解服务的性能,需要收集多个数据点进行监控,以便诊断问题或在问题出现之前进行预防。

监控单个服务的作用有限,因为服务虽然提供了隔离性,但并非孤立存在。服务通常相互依赖,并依赖于底层基础设施(如网络、数据库、缓存存储和事件队列)。监控服务可以获得很多有价值的信息,但还需要了解所有层级的情况。

监控解决方案应能让我们知道系统哪里出现了故障或性能下降,以及原因是什么。我们可以快速发现任何症状,并使用可用的监控信息来确定原因。

2.3 黄金信号

在从任何面向用户的系统收集指标时,应关注四个黄金信号:延迟、错误、流量和饱和度。
- 延迟 :测量从向给定服务发出请求到服务完成请求所经过的时间。可以从这个信号中推断很多信息,例如,如果延迟增加,则表明服务性能在下降。但需要注意将此信号与错误进行关联。例如,应用程序快速响应但返回错误,此时延迟值较低,但结果并非我们期望的。因此,应将导致错误的请求的延迟排除在外,以免产生误导。
- 错误 :确定未成功完成的请求数量。错误可能是显式的(如 HTTP 500 错误)或隐式的(如 HTTP 200 但内容错误)。后者的监控并不简单,因为不能仅依赖 HTTP 代码,可能需要在其他组件中查找错误内容才能确定。通常通过端到端测试或契约测试来捕获这些错误。
- 流量 :测量系统所承受的需求。它会根据所观察的系统类型、每秒请求数、网络 I/O 等因素而变化。
- 饱和度 :在某一时刻测量服务的容量。主要适用于资源受限的情况,如 CPU、内存和网络。

2.4 指标类型

收集指标时,需要确定最适合要监控的资源的指标类型。
- 计数器 :是一种累积指标,表示一个始终增加的单一数值。使用计数器的指标示例包括:请求数量、错误数量、收到的每个 HTTP 代码的数量、传输的字节数。如果指标可能会减少,则不应使用计数器,而应使用仪表。
- 仪表 :表示可以上下波动的单一任意数值。使用仪表的指标示例包括:数据库连接数量、使用的内存、使用的 CPU、负载平均值、异常运行的服务数量。

通过关注这些黄金信号和选择合适的指标类型,我们可以构建一个有效的监控系统,及时发现系统中的问题并采取相应的措施。

2.5 监控系统的构建流程

为了更清晰地展示如何构建一个监控系统,下面给出一个 mermaid 格式的流程图:

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;

    A(确定监控目标):::process --> B(选择监控工具):::process
    B --> C(收集黄金信号指标):::process
    C --> D(确定指标类型):::process
    D --> E(设置监控层级):::process
    E --> F(配置显示和警报):::process
    F --> G(持续监控和优化):::process

具体的操作步骤如下:
1. 确定监控目标 :明确要监控的系统范围和期望获取的信息,例如是整个微服务架构还是特定的服务组件。
2. 选择监控工具 :根据团队资源和需求,选择合适的开源或商业监控工具。这里使用开源工具构建监控系统,包括指标收集器、显示和警报组件。
3. 收集黄金信号指标 :按照前面提到的黄金信号(延迟、错误、流量、饱和度),从系统的各个层级收集相关指标。
4. 确定指标类型 :根据要监控的资源,选择合适的指标类型(计数器或仪表)。
5. 设置监控层级 :在客户端、边界、服务和平台等各个层级实施监控,确保全面了解系统行为。
6. 配置显示和警报 :将收集到的指标聚合到各自的仪表板中,设置自动警报规则,以便在出现问题时及时通知。
7. 持续监控和优化 :定期检查监控数据,根据实际情况调整监控策略和警报规则,不断优化监控系统。

2.6 监控系统的实际应用案例

为了更好地理解监控系统的作用,下面通过一个实际案例进行说明。

假设我们有一个电商系统,包含商品服务、订单服务、支付服务等多个微服务。在系统运行过程中,我们使用监控系统收集相关指标。

2.6.1 发现延迟问题

通过监控延迟指标,我们发现订单服务的响应时间逐渐增加。进一步查看各个层级的监控数据,发现是数据库查询延迟导致的。原来是数据库的索引设置不合理,导致查询效率低下。通过优化数据库索引,订单服务的响应时间恢复正常。

2.6.2 检测错误情况

在监控错误指标时,我们发现支付服务偶尔会出现 HTTP 500 错误。通过查看日志和跟踪信息,定位到是支付接口调用失败。原来是支付服务与第三方支付平台的通信出现问题,可能是网络波动或接口参数错误。及时调整参数并排查网络问题后,错误问题得到解决。

2.6.3 分析流量变化

监控流量指标可以帮助我们了解系统的负载情况。在促销活动期间,我们发现商品服务的流量大幅增加。通过提前做好扩容准备,确保了系统在高流量下的稳定运行。

2.6.4 处理饱和度问题

当监控到某个服务的 CPU 饱和度接近 100% 时,说明该服务的资源已经达到瓶颈。我们可以通过增加服务器资源或优化代码来解决饱和度问题,保证服务的正常运行。

3. 总结

3.1 微服务部署要点

  • 微服务部署过程应兼顾速度和安全性,同时保证一致性。
  • 连续交付是微服务理想的部署实践,通过快速交付小的、经过验证的变更集来降低风险。
  • 良好的连续交付管道能为工程团队提供可见性、正确性和丰富的反馈。
  • 可以在多个服务之间复用声明式管道步骤,标准化部署流程,使部署在不同团队之间具有可预测性。
  • 应将部署的技术活动与功能发布的业务活动分开管理,以实现对功能推出和回滚的精细控制。

3.2 监控系统的重要性

  • 监控系统是微服务架构中不可或缺的一部分,能帮助我们及时了解系统的运行状态,发现潜在问题并采取相应措施。
  • 通过收集黄金信号指标和选择合适的指标类型,构建分层的监控系统,可以全面、准确地掌握系统的行为。
  • 监控系统不仅能应对问题,还能预测系统行为,为业务分析提供数据支持。

3.3 未来展望

随着微服务架构的不断发展和应用场景的日益复杂,对部署和监控的要求也会越来越高。未来,我们可以进一步探索以下方面:
- 更智能化的部署策略,如基于机器学习的自动部署和资源分配。
- 更强大的监控工具和技术,如实时分析和可视化展示。
- 更好的故障诊断和修复机制,提高系统的可靠性和可用性。

通过不断优化和完善微服务的部署和监控体系,我们可以构建出更加高效、可靠的微服务系统,为用户提供更好的服务体验。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值