提倡模块化设计

Google Cloud Well-Architected Framework 的性能优化核心中的这一原则提供了一些建议,可帮助您推广模块化设计。模块化组件和清晰的界面可实现灵活的扩缩、独立更新和未来的组件分离。

原则概览

了解应用组件与系统组件之间的依赖关系,以设计可伸缩的系统。

无论最初部署的是单体式还是微服务架构,模块化设计都可以实现灵活性和弹性。通过将系统分解为具有清晰接口的明确定义的独立模块,您可以扩缩各个组件以满足特定需求。

有针对性的扩缩可以通过以下方式帮助优化资源利用率并降低费用:

  • 只为每个组件预配必要的资源,并为需求较低的组件分配较少的资源。
  • 在高流量期间添加更多资源,以维持用户体验。
  • 在不影响性能的情况下移除利用率过低的资源。

模块化还可提高可维护性。较小的独立单元更易于理解、调试和更新,这样可以缩短开发周期并降低风险。

虽然模块化具有显著优势,但您必须评估潜在的性能权衡。模块之间的通信不断增加可能会导致延迟和开销。力求在模块化和性能之间取得平衡。高度模块化的设计可能并非普遍适用。如果性能至关重要,则不妨采用更紧密耦合的方法。系统设计是一个迭代过程,您可以在其中不断审核和优化模块化设计。

建议

如需推广模块化设计,请考虑以下部分中的建议。

设计时采用松散耦合

设计松散耦合的架构。依赖项最少的独立组件可帮助您构建可扩缩的弹性应用。在规划服务的边界时,您必须考虑可用性和可扩缩性要求。例如,如果某个组件的要求与其他组件不同,您可以将该组件设计为独立的服务。为不太重要的子进程或服务实施优雅故障计划,这些子进程或服务不会影响主要服务的响应时间。

在设计时考虑并发和并行性

将应用设计为同时支持多个任务,例如处理多个用户请求,或在用户与系统交互时运行后台作业。将大型任务拆分为多个服务实例可同时处理的较小块。借助任务并发设置,您可以使用自动扩缩等功能来增加产品中的资源分配,例如:

平衡模块化,灵活分配资源

请尽可能确保每个组件仅使用必要的资源(例如内存、存储空间和处理能力)来执行特定操作。资源过度分配可能会产生不必要的费用,而资源分配不足会降低性能。

使用明确定义的接口

确保模块化组件通过清晰的标准化接口(如 API 和消息队列)有效通信,以减少翻译层或无关流量的开销。

使用无状态模型

无状态模型有助于确保您可以独立于之前的请求处理每个请求或与服务的交互。此模型有助于提高可伸缩性和可恢复性,因为您可以在扩展、缩减或重启服务的同时,不会丢失进行中的请求或进程所需的数据。

选择互补技术

选择与模块化设计相辅相成的技术。评估编程语言、框架和数据库的模块化支持。

如需了解详情,请参阅以下资源: