微服务架构的日志、测试与流程管理

### 微服务架构的日志、测试与流程管理 #### 1. 日志记录与可观测性 粗粒度的日志记录可能不足以调试和找出问题的根源。架构师需要根据每个应用程序的静态和动态特性进行权衡。较新的应用程序可能需要细粒度的日志记录，而稳定的应用程序可能可以使用粗粒度的日志记录。对于更稳定的应用程序，当运行时指标警报响起时，更改日志记录级别可能会提供更多洞察。但这不是规则，而是需要审慎评估的选项，例如详细的日志记录可能会使已经性能不佳的系统变得更糟。一旦确定了合适的日志记录级别，将日志聚合到一个可以进行上下文关联的中心位置，能显著提高系统的可观测性。 在自动支付示例中，一个自动支付请求会触发跨多个领域的一系列微服务调用。当每个微服务都具有可观测性时，每个服务调用或触发一系列微服务的事件都会被标记上一个跟踪数据包。这个跟踪数据包会被转发到每个服务，以识别执行上下文。服务有代理来聚合这些信息并将其发送到中央存储。跟踪采样的选项有很多，如一定比例的流量、每秒计数、随机跟踪等都是常见的选择。一个好的做法是将这个跟踪数据包添加到日志中，以便将日志记录与跟踪关联起来。一旦警报响起，工程师就可以识别可疑交易的踪迹，从而找出错误的来源。 所有微服务调用链都需要对其调用链进行跟踪、指标和日志记录的可见性，这三个方面定义了系统的可观测性。在微服务的海洋中调试故障是一项艰巨的任务，将可观测性构建到每个微服务中是缓解这一挑战的绝佳方法。架构师和工程师需要从一开始就强制实施可观测性。 以下是日志记录与可观测性的关键要点列表： - 日志记录粒度需根据应用特性权衡。 - 聚合日志到中心位置提高可观测性。 - 跟踪数据包用于关联日志和识别执行上下文。 - 从一开始就强制实施可观测性。 #### 2. 契约测试 微服务发展迅速，这种快速变化常常会影响到边界，并改变已定义的契约。一个微服务可能会通过新的 REST 资源提供新功能，或者在其 REST 资源中添加或删除字段。这些变化如果在开发周期后期才被发现，通常会对整个系统产生重大影响。 随着企业的微服务迅速增加到数千个，识别微服务资源变化的副作用变得困难。一个导致生态系统中另一个微服务失败的变更可能会在开发过程中被忽略。为了有效减少变更的影响范围，我们需要在生命周期的早期就对已知契约进行测试。 契约测试是指微服务与每个依赖服务承诺一份契约，并每次都针对该契约进行测试的过程。最好的方法是将验证契约遵守情况的测试嵌入到微服务本身中。如果变更破坏了协议，微服务团队可以通过修复变更以符合契约或回滚变更来进行纠正。这种测试需要依赖服务团队提供测试来描述其需求，这些测试在编译时验证微服务契约。这种协议被称为消费者驱动契约，是解决这个问题的好方法。 然而，实施契约测试并不简单直接，不能只采用消费者驱动契约或提供者驱动契约，两种方法都有优缺点。为了使契约测试有效，需要一些基本规则来决定何时优先选择其中一种。以下是一些参考规则： 1. 决定两种方法的主要标准基于以下方面的变更： - 系统所处的生命周期阶段，如处于初始阶段、开发阶段还是生产阶段。 - 系统在微服务层次结构中的位置，例如是许多系统依赖的基础系统，还是外部实体依赖契约的面向客户的应用程序。 2. 一个经验法则是，如果一个新的微服务仍在开发中，它必须接受生产中其他系统的变更。一个未发布的新微服务不能阻止已建立的微服务进行变更。在新微服务达到成熟状态之前，它必须继续接受稳定微服务的变更。 3. 协调定义企业级 API 的顶级微服务的变更是困难的。一个领域内的基础微服务也很难变更，因为有许多服务依赖于它。 在成熟的软件企业中，契约测试是软件开发过程的一部分。契约被创建、共享并添加到微服务的编译和构建阶段。围绕选择合适的契约测试类型建立治理和规则可以带来平衡，既允许微服务在需要时更改其契约，又能在开发生命周期的早期识别受影响的客户端系统。 以下是契约测试的流程 mermaid 图： ```mermaid graph LR A[微服务团队提出变更] --> B[契约测试] B -->|通过| C[变更实施] B -->|未通过| D[修复变更或回滚] D --> B ``` #### 3. 微服务开发流程 现代软件开发需要有效的技术。企业要采用微服务范式，就必须对开发方法进行变革。为了成功实施任何微服务架构，有必要围绕现代开发流程重新组织开发团队。 一个全面的软件开发过程包括以下步骤： 1. 通过中央代码仓库管理源代码： - 确保进行适当的标记、分支和功能标志设置。 - 确保每次签入/合并后都进行代码提交、合并和审查。 2. 使用工具自动触发构建过程： - 静态检查代码，查找代码异味、代码指标（复杂度、可维护性指数）、契约违规和安全漏洞。 - 运行单元测试，验证正确性并收集测试统计信息（如失败率、代码覆盖率等）。 - 将代码编译成可“及时密封”的二进制可执行格式。 - 将二进制文件移动到工件仓库，并进行版本标记。 3. 动态启动类似生产的测试环境进行测试，并运行集成测试： - 成功完成集成测试后，将二进制文件标记为发布候选版本。 - 测试完成后拆除测试环境。 4. 为服务的发布候选版本准备生产部署： - 更新功能标志以协调发布。