构建可扩展、可维护且具有弹性的系统需要了解重要的设计模式,这些模式在微服务架构中变得越来越普遍。与整体架构相反,微服务将大型系统划分为更易于管理的独立服务,这些服务通过网络相互连接。然而,这种分布式特性在通信、数据管理和服务协调等领域带来了复杂性。
采用众所周知的微服务设计模式可以帮助缓解这些问题并显着提高系统的可靠性和有效性。本文介绍了每个软件开发人员都应该了解的 7 种最重要的微服务设计模式。
1。 API网关模式
API 网关充当所有客户端对微服务请求的单一入口点。 API 网关不是让客户端直接与多个服务交互,而是整合这些请求,将它们路由到适当的微服务,并聚合响应。它简化了客户端-服务器通信,并提供了一种管理横切问题的方法,例如身份验证、日志记录和速率限制。
好处:
✓ 对请求/响应处理的集中控制。
✓ 通过抽象内部微服务复杂性来简化客户端交互。
✓ 更轻松地实现安全、缓存和限制。
例子:
在Node.js中使用Express.js构建一个基本的API网关:
import express from 'express'; import proxy from 'express-http-proxy'; const app = express(); // Forward requests to microservice A app.use('/serviceA', proxy('http://serviceA-url')); // Forward requests to microservice B app.use('/serviceB', proxy('http://serviceB-url')); app.listen(3000, () => { console.log('API Gateway running on port 3000'); });
2.断路器模式
在微服务架构中,服务失败是不可避免的。断路器模式通过监视服务调用并在达到特定故障阈值时停止对失败服务的进一步调用,帮助防止级联故障。一旦服务恢复,断路器就允许再次调用。这提高了系统弹性并防止本已陷入困境的服务承受不必要的负载。
好处:
✓ 防止系统范围内的故障。
✓ 在失败期间提供后备或替代响应。
✓ 增强微服务架构的稳健性。
例子:
在 Node.js 中使用 opossum 库作为断路器:
import CircuitBreaker from 'opossum'; import axios from 'axios'; const options = { timeout: 5000, errorThresholdPercentage: 50, resetTimeout: 30000, }; const circuitBreaker = new CircuitBreaker(() => axios.get('http://serviceB-url'), options); circuitBreaker.fire() .then(response => console.log(response.data)) .catch(err => console.log('Service B is down. Circuit is open.'));
3.每个服务模式的数据库
每个微服务应该有自己的专用数据库,允许团队独立工作并减少服务之间的紧密耦合。这种设计模式确保微服务可以独立发展,而不会受到共享数据库架构更改的影响。
好处:
✓ 减少跨服务依赖和争用。
✓ 促进独立扩展和模式演化。
✓ 隔离数据所有权和责任。
4。传奇模式
在分布式架构中,处理跨多个服务的事务可能具有挑战性。 Saga 模式使用一系列跨多个服务协调的本地事务来管理分布式事务。每个服务执行其事务并触发下一个事务,并通过补偿机制在出现问题时撤消操作。
好处:
✓ 无需集中式事务管理器即可实现一致的分布式事务。
✓ 支持跨微服务的最终一致性。
✓ 必要时启用未完成操作的回滚。
例子:
在电子商务系统中,订单服务可能创建订单,付款服务处理付款,库存服务更新库存水平。如果支付失败,需要回滚订单和库存更新,通过补偿交易来处理。
5。事件溯源模式
事件溯源模式将系统的状态存储为事件序列。微服务不是将当前状态保存在数据库中,而是存储表示状态更改的事件。通过重播这些事件,始终可以重建当前状态,从而提供完整的审计跟踪并启用复杂的恢复机制。
好处:
✓ 提供所有变更的清晰审计跟踪。
✓ 通过重播过去的事件来启用历史分析。
✓ 如有必要,有利于重建状态。
例子:
在会计系统中,“交易创建”、“交易批准”和“交易完成”等事件被存储为事件。通过回放所有交易事件,可以重新计算当前余额。
6。 CQRS(命令查询职责分离)模式
CQRS 模式将读取和写入操作分为不同的模型。写操作由命令模型处理,读操作由查询模型处理。此模式对于读取比写入频繁得多的高性能应用程序特别有用。
好处:
✓ 通过分离读/写问题来优化性能。
✓ 支持不同的读写扩展策略。
✓ 允许针对特定任务定制灵活的模型。
7.绞杀无花果图案
Strangler Fig 模式是一种渐进式迁移策略,允许您用微服务重构或替换单体的部分内容。随着新功能的添加,它被构建为微服务。随着时间的推移,单体系统会被逐个服务地替换,而不会立即中断整个系统。
好处:
✓ 提供从整体迁移到微服务的无中断路径。
✓ 降低整个系统重写的风险。
✓ 实现增量改进和重构。
例子:
您可以首先将整体应用程序的用户身份验证组件提取到独立的微服务中,同时保持系统其他部分完好无损。随着时间的推移,更多的组件被转移到微服务中,直到整个系统实现模块化。
结论
使用微服务设计原则时,有许多不同的方法可以解决分布式系统中出现的问题。构建可靠、可扩展的微服务架构需要掌握这些模式,无论您的目标是什么——跨服务管理数据、增强服务之间的通信或优雅地处理错误。通过解决特定的要求和权衡,这些模式都有助于提高微服务的弹性和性能。
免責聲明: 提供的所有資源部分來自互聯網,如果有侵犯您的版權或其他權益,請說明詳細緣由並提供版權或權益證明然後發到郵箱:[email protected] 我們會在第一時間內為您處理。
Copyright© 2022 湘ICP备2022001581号-3