微服务架构挑战的应对策略

### 微服务架构挑战的应对策略 在微服务架构的应用中，我们会遇到诸多挑战，如事务处理、全局状态维护、调试故障等。下面将详细探讨这些挑战以及相应的解决策略。 #### 1. 事务处理与Saga模式 在微服务架构里，一个完整的事务往往由多个子步骤构成，这种包含众多子事务的总事务被称作Saga。Saga是嵌套事务的扩展，它由跨领域的微服务调用组成，这些调用本身也可能是事务。Saga能将事务以子步骤序列的形式呈现，而且失败或部分成功可能会在更细粒度的层面发生。 例如，对于微服务A，要成功完成任务，就需要更新微领域J、H、K和L，此时{S, H, K, L}的更新事务就是一个Saga。若微服务{C, D, G, H, K, L}中的任何一个子集出现错误，顶级微服务作为一个事务就会失败。 当Saga出现错误时，有以下几种处理方法： - **忽略错误**：这是一种较为简单直接的方法，适用于那些能够容忍一定失败率的非关键服务。例如，在Energence的计量服务中，若该服务需要在多个表中持久化电表读数，包括更新当前读数、设备信息以及HVAC和各种电器的使用百分比。若电表读数按周期到达，那么更新部分表失败是可以接受的，因为后续的数据会自动纠正错误。不过，在忽略错误之前，仍需记录错误信息，以便进行审计和质量评估。但这种方法不适用于需要处理和解决错误的场景，比如客户信用卡支付未准确反映在账户状态中的情况，这不仅会影响收入，还可能涉及法律问题。 - **内联补偿错误**：通过补偿事务来纠正失败或部分成功事务导致的错误。可以通过回滚所有操作或完成缺失的操作来修复失败或部分完成的Saga。具体做法是在Saga中创建多个保存点（每个保存点代表一个或多个步骤），并从最后一个完成的保存点开始进行补偿。回滚Saga时，将事务操作压入栈中，失败时按相反顺序弹出并“撤销”每个操作。这种方法能有效回滚更改，确保微服务结束时数据处于正确状态，还能在问题对整个系统造成更多损害之前主动解决。然而，补偿事务会增加实现的复杂性，要求微服务包含额外的业务逻辑来纠正失败的事务，对于更新多个子领域的顶级微服务来说，补偿操作可能会变得非常复杂，同时也会使测试变得困难，因为增加了需要测试的替代路径和组合。此外，补偿操作本身也可能失败，甚至进一步损坏数据。 - **离线补偿错误**：通过启动一个进程或另一个微服务来异步修复错误。其核心思想是“稍后可以回来纠正错误”。例如，可以触发一个稍后更新客户账户的进程，该进程会重试POST更新操作，以纠正客户的账户或账单。使用消息队列支持这些异步任务，能以一种可靠的方式修复数据，并且如果对消息传递和触发过程进行抽象，这种模式在类似情况下可以复用。但这种方法也存在问题，重试尝试需要受时间限制且对时间敏感。比如，Energence成功收取了客户的信用卡费用，但未能更新客户账户，若异步尝试在数小时后进行，而在此期间监控违约账户的服务因未收到付款而关闭了账户，就会引发问题。 以下是一个简单的mermaid流程图，展示Saga事务处理的基本流程： ```mermaid graph LR A[开始Saga事务] --> B{是否成功} B -- 是 --> C[事务完成] B -- 否 --> D{选择处理方式} D -- 忽略错误 --> E[继续运行] D -- 内联补偿 --> F[回滚或完成操作] D -- 离线补偿 --> G[异步修复] F --> C G --> C ``` #### 2. 实现Saga的要点 对于基于HTTP构建的分布式微服务，实现ACID事务较为困难。除了接受数据的最终一致性外，还需要提前设计以处理失败情况，无论是部分失败还是完全失败。具体而言： - **操作排序**：将不可恢复的操作放在最后执行，这样可以提高成功恢复的概率。 - **创建保存点**：保存点在实现Saga中起着关键作用。合理规划保存点，确保其使数据处于一致状态，有助于恢复。当从保存点开始恢复尝试时，可能需要重新运行保存点之间的微服务，因此这些微服务应允许重试而不失败。 - **选择错误处理方式**：根据需求和用例，在忽略错误、内联补偿和离线补偿这三种错误处理方式中做出选择。 #### 3. 全局状态维护 在编排系统中，各个系统独立维护状态并异步共享，要推断状态的一致性是一项严峻的挑战。在编排场景中，调用深度的增加会影响推断粗粒度状态的性能，深调用栈会导致更多的失败点和更长的状态协调时间。像分片这样的性能优化措施会使情况更加复杂，因为在查询数