软件架构风格

我最近开始以不同的方式研究软件架构风格：阅读著名架构师的书籍，并尝试在我的职业生涯中更进一步。我已经看到架构师与开发人员有多么不同；尽管这两个角色有很多共同点，但方法不同。

我不想在本文中描述成为软件架构师意味着什么。我将总结我一直在阅读和学习的有关分类为整体式或分布式的不同软件架构风格的内容。

整体与分布式定义

当我们谈论单体或分布式架构时，我们指的是应用程序的部署类型，也就是说，应用程序应该作为一个整体部署，以统一的方式（单体）部署，还是部署几个孤立的工件独立（分布式）？作为开发人员，我一直认为分布式架构是单体架构之后的一种解决方案。随着时间的推移和应用程序用户的增加，您需要隔离代码的某些部分，因为它们会使其余部分崩溃。我没有错，但这不是到达那里的唯一途径；此外，您可能必须从某些分布式架构开始，以满足不同的需求，例如安全性、弹性和法律问题 (pe PCI)，尽管这并不常见。

软件架构风格

单体架构

这种软件架构风格具有重要的好处，尤其是在启动域处于非常早期阶段并且上下文之间的界限非常模糊的应用程序时。需要记住的重要一点是，无论应用程序投入生产多长时间，都必须对域进行更改。这不是您可以遗漏的东西；我们必须尽可能频繁地更新我们的实现以忠实地代表领域，没有任何架构可以使您免于此。

单一软件架构风格可以给您带来的好处是可以更快地进行更改。这并不意味着使用分布式架构就无法做到这一点；我们正在谈论它所花费的时间和这样做时的安全性（这意味着开发成本）。在开发层面，它在初始阶段也简化了很多，只谈论单一语言的单一存储库。

在部署级别，它有点复杂。在应用程序的早期阶段，简化部署可以帮助您更加专注于领域。如果你在这个阶段引入微服务，你将不仅要处理领域，还要处理随之而来的所有基础设施。但是，随着应用程序的增长，由于安全问题，部署往往会随着时间的推移而变慢和间隔开。例如：在电子商务中，想要更改产品列表的一小部分意味着不仅要部署该部分，还要部署其余部分，包括结帐系统或其他更重要的部分，以避免提供好处的东西被破坏一个微小的变化，在低流量时段将几个小的变化归为同一个变化。

在可扩展性层面，我认为与部署相同；在早期阶段，在收集指标时平均扩展整个项目，以便稍后您可以看到项目的哪一部分需要或多或少地扩展（扩展单体有其风险，但Stack Overflow已经证明它是非常可行的） . 随着时间的推移，您会发现没有必要扩展整个项目；产品列表很可能比结帐或用户个人资料页面访问次数更多，因此我们可以在部署此应用程序时考虑进行一些更改（或者可能只是添加弹性，谁知道呢）。

分布式架构

当我们谈论分布式架构时，我们指的是这样一种应用程序，其中模块独立部署，与其他模块隔离，并且它们之间使用远程访问协议（例如，HTTP、grpc、队列等）进行通信。

它们因其可扩展性和可用性等因素而广为人知。性能通常是它们的强项之一，尤其是取决于服务的粒度。此外，这类架构通常非常依赖最终一致性，因此事件是广泛使用的服务间通信方式。这意味着通过不等待我们向其发送消息的服务的响应，我们可以更快地处理我们收到的请求。

发送事件为服务之间的通信开辟了广泛的可能性，但我们仍然需要服务之间的交易。这就是分布式架构的弱点之一：分布式事务。

分布式事务的替代方案是 ACID 事务，根据我们定义服务的方式，这是不可能实现的。在基于服务的架构或微服务中，它更受域驱动 (DDD)，服务更粗粒度，事务将是 ACID（如果不是，则很可能是设计问题）。而在其他架构中，例如 EDA，交易将是分布式的，我们将需要额外的部分（例如 SAGA、2PC）来完成交易，无论是否令人满意。如果任何部分发生故障，则必须补偿其余部分。

何时使用单体架构或分布式架构

虽然这是一个被问得很多的问题，但答案永远是“视情况而定”，因为每个项目都会有不同的要求，并且根据这些要求做出决定，但这不是应该做出的决定很快，它需要一定的标准、经验和考虑。

正是在这里，开发人员发挥了重要作用，并且能够从另一个角度（更全球化的角度）看待项目。开发人员总是倾向于在我们的日常工作中考虑更多，而不是长期考虑；我们将根据我们的经验和知识做出决定，或者仅仅通过学习，跟随炒作的潮流。能够将注意力转移到项目上的开发人员将做出该决定。他们将根据业务需求定义应用程序的特征，无论是显式的（他们将出现在电视广告中）还是隐式的（这是电子商务，你知道销售、黑色星期五等） ; 他们将评估不同的架构及其权衡，并决定哪一个更方便。

也就是说，正如我们已经提到的，单体架构通常是好的，除其他因素外，因为它易于更改，这就是为什么它是您开始开发时推荐的架构。这并不是说您不应该考虑将来隔离单体应用的特定组件的可能性。

我们通常所说的软件架构风格，指的是顶层风格，即定义第一层的架构。一个明显的例子是模块化整体架构，在顶层，我们看到一个整体组件被划分为按域分隔的模块。尽管如此，如果我们放大每个领域，我们会看到清晰识别的分层架构，这将通过技术组件（表示、领域或基础设施等）将层分开。

模块化单体

巨石还是“大泥球”？

经常会遇到“单体”受到严厉批评的项目。当你更深入地研究这个项目时，你会意识到批评并不是针对架构的类型，而是针对所谓的“缺乏”架构，即“大泥球”。

这导致妖魔化建筑，这是不应该落入主观性的东西。关于整体架构是否适合项目的决定应该通过重要的论据做出，权衡废弃架构和将要引入的架构的所有权衡。

事实上，从主观上讲，单体架构已经失去了很多重量，这导致了完整的项目重组，从大泥球转移到选择的架构、微服务，将我们带到了一个被称为“分布式大泥球”的新架构. 不用说，将有专门的团队专门负责此，在进行此类重组时停止（或试图）业务。

我们不仅没有解决任何问题，反而让系统变得更加复杂，不仅难以修改，而且在此过程中增加了更多的故障点和延迟。哦，还有一个稍微大一点的 DevOps 团队。

更好的方法是以更直接的方式攻击“大泥球”，同时通过遵循某些模式来提供业务价值，这些模式将帮助我们以更健康的方式迁移到另一种架构。

结论

缺乏对架构的关注导致许多公司做出并非最佳的决策。即使他们会工作，他们也不会像他们应该的那样工作。马克理查兹曾说过：“建筑没有错误的答案，只有昂贵的答案。” 而且他是绝对正确的：当基于单一问题而不是从全局的角度来做出决策时，结果并不像预期的那样；你通过在列表中添加十个来解决一个问题。

项目会取得进展，但对业务的交付会一点一点变慢，造成“团队”之间的摩擦，直到达到无法为项目交付价值的不归路，并且可能会重写需要考虑，包括这一切。