常见的架构模型

我的新书《Android App开发入门与实战》已于2020年8月由人民邮电出版社出版，欢迎购买。点击进入详情

软件架构模式是用于解决软件开发中复杂架构挑战的基本准则。它们为重复出现的问题提供结构化的解决方案，确保效率、可扩展性和可维护性。

Backend For Frontend (BFF)

涉及创建根据各个前端应用程序的要求量身定制的特定后端服务，优化通信和数据交付。

重点：创建适合特定前端应用程序的后端服务。

优点：优化通信和数据传输。

权衡：可能导致重复的逻辑，需要额外的维护。

发布/订阅模型

焦点：在消息系统中解耦生产者和消费者。

优点：增强可扩展性和系统灵活性，支持异步通信。

权衡：增加消息管理的复杂性，取决于代理的可靠性。

SideCar模型

重点：增强或扩展主要应用程序的功能。

优点：功能隔离和模块化，更易于维护。

权衡：会增加系统复杂性、额外的资源消耗。

数据驱动测试

重点：通过使用数据驱动的方法来增强测试流程。

好处：增加测试覆盖率，提高效率。

权衡：需要彻底的数据管理，可能出现与数据相关的错误。

C4 Model

专注于提供软件架构的全面可视化，将其分为四个级别：上下文、容器、组件和代码。它有助于理解和交流不同抽象级别的软件结构。

重点：跨四个级别的软件架构的可视化。

好处：增强对软件结构的理解和沟通。

权衡：对于较小的系统可能过于复杂。

领域驱动设计(DDD)

重点是使用模型驱动的方法使软件设计与领域复杂性紧密结合。它强调技术和领域专家之间的协作，以创建共同语言和共享理解。

重点：使软件设计与领域复杂性保持一致。

优点：促进协作并创建共享语言。

权衡：需要深入了解该领域，可能很复杂。

扼杀者模型

旨在逐步替换旧系统的部分内容，允许增量更新并平滑迁移到新技术，而不会破坏现有功能。

重点：逐步更换遗留系统。

优点：允许增量更新而不破坏现有功能。

权衡：可能很慢并且占用资源。

断路器

提供一种优雅地处理故障的方法，防止分布式系统中发生级联故障。它的作用就像一个断路器，停止对故障服务的请求流以允许恢复。

重点：处理分布式系统中的故障。

优点：防止级联故障，让服务有时间恢复。

权衡：需要仔细设置阈值以避免错误

API网关

充当中间层，管理来自客户端的请求并将其路由到各种微服务，提供统一的接口、安全性和其他横切关注点。

重点：管理对微服务的请求。

优点：提供统一的接口，增强安全性。

权衡：潜在的单点故障、复杂性增加。

命令查询职责分离 (CQRS)

将读取和写入操作分为不同的模型，优化性能和可扩展性，尤其是在复杂和高要求的环境中。

重点：分离读操作和写操作。

优点：优化性能和可扩展性。

权衡：增加复杂性，可能导致最终的一致性问题。

发件箱模型

通过在转发消息之前临时存储消息，解决确保分布式系统（尤其是微服务架构）中可靠消息传递的挑战。

重点：确保分布式系统中可靠的消息传递。

优点：防止传输失败时数据丢失。

权衡：增加实现复杂性，可能会引入延迟。

多租户

讨论使用 Keycloak 进行身份验证以及分别使用 Angular 和 Springboot 进行前端和后端开发来实现多租户系统。

重点：使用特定技术实现多租户系统。

优点： SaaS 应用程序中的高效身份验证管理。

权衡：设置复杂，需要集成多种技术。

反模型架构

重点介绍软件架构中的常见陷阱和“反模式”，深入了解维护健康高效的软件系统时应避免的事项。