你好，哈布尔。 今天，我继续出版专门为课程新流的开始而撰写的一系列出版物。 .
介绍
架构风格的选择是构建信息系统时的基本技术决策之一。 在本系列文章中，我建议分析建筑应用中最流行的建筑风格，并回答何时最优选哪种建筑风格的问题。 在演示过程中，我将尝试绘制一条逻辑链来解释架构风格从单体到微服务的发展。
В 我们研究了单体应用并得出结论，单体应用存在许多问题：大小、连接性、部署、可扩展性、可靠性和刚性。
这次我建议讨论将系统组织为一组模块/库（面向组件的体系结构）或服务（面向服务的体系结构）的可能性。
面向组件的架构
面向组件的体系结构涉及将系统作为一组可用于当前和未来项目的组件来执行。 将系统分解为组件时，需要考虑以下因素：它们的可重用性、可替换性、上下文独立性、可扩展性、封装性和独立性。
正确使用组件，解决了“大污垢”（大尺寸+高耦合）的问题，组件本身既可以是组装单元（模块、库），也可以是部署单元（服务）。 部署单元并不总是映射到正在运行的进程：例如，Web 应用程序和数据库部署在一起。
大多数情况下，单体是作为一组模块开发的。 这种方法导致了独立开发，但独立扩展和部署、容错以及独立于整个技术堆栈的问题仍然存在。 这就是为什么该模块是部分独立的组件。
这种单体应用的最大问题是，模块的划分纯粹是逻辑性的，很容易被开发人员违反。 可能会出现一个核心模块，它逐渐变成一个垃圾转储，模块之间的依赖关系图可能会增长，等等。 为了避免此类问题，开发要么由非常成熟的团队进行，要么在“架构师”的指导下进行，专职进行代码审查，击败违反逻辑结构的开发人员。
“理想的”整体是一组逻辑上独立的模块，每个模块都会查看自己的数据库。
面向服务的架构
如果系统应该以一组服务的形式组织，那么我们正在谈论面向服务的体系结构。 其原则是以用户为中心的应用互操作、业务服务复用、技术栈独立性和自治性（独立演进、可扩展和部署）。
面向服务的架构（SOA=面向服务的架构）解决了单体应用中所有已识别的问题：发生变化时只有一项服务受到影响，并且定义良好的 API 支持良好的组件封装。
但并非一切都那么顺利：SOA 会带来新的问题。 远程调用比本地调用更昂贵，并且在组件之间重新分配职责也变得更加昂贵。
顺便说一下，独立部署的可能性是该服务的一个非常重要的特性。 如果服务必须一起部署，或者按照一定的顺序部署，那么系统就不能被认为是面向服务的。 在这种情况下，他们谈论的是分布式单体（不仅从 SOA 的角度来看，而且从微服务架构的角度来看，都认为是一种反模式）。
面向服务的架构得到了架构社区和供应商的大力支持。 这意味着存在许多课程和认证以及完善的模式。 后者包括例如著名的企业服务总线（ESB=企业服务总线）。 同时，ESB 是供应商的包袱；它不一定必须在 SOA 中使用。
面向服务的架构的流行度在 2008 年左右达到顶峰，此后开始下降，在微服务出现后（~2015 年），下降趋势更加明显。
结论
在我们讨论了以服务和模块的形式组织信息系统的可能性之后，我建议最后转向微服务架构的原则，并在下一部分中特别注意微服务架构和面向服务的架构之间的区别。
来源： habr.com