介绍
架构风格的选择是构建信息系统的基本技术解决方案之一。在本系列文章中，我建议分析建筑应用程序中最流行的建筑风格，并回答何时是最喜欢的建筑风格的问题。在此过程中，我将尝试画出一条逻辑链，该逻辑链解释从整体式到微服务式的建筑风格的发展。
我们上次处理整体式时得出的结论是，整体式有很多问题：大小，连接性，部署，可伸缩性，可靠性和保守性。
这次，我建议谈论以一组模块/库（面向组件的体系结构）或服务（面向服务的体系结构）的形式组织系统的可能性。
面向组件的架构
基于组件的体系结构意味着将系统实现为可以在当前和将来的项目中使用的一组组件。在将系统划分为组件时，要考虑以下因素：它们是否适合重用，它们的可替换性，与上下文的独立性，可扩展性，封装性和独立性。
通过正确使用组件，可以解决“大污垢”（大尺寸+高连接性）的问题，并且组件本身既可以是组装单元（模块，库）又可以是部署单元（服务）。部署单元并不总是映射到正在运行的进程：例如，Web应用程序和数据库一起部署。
通常，整料被设计为一组模块。这种方法导致确保开发的独立性，但是同时仍然存在独立伸缩和部署，容错以及与常规技术堆栈无关的问题。这就是模块是部分独立的组件的原因。
这种整体的最大问题是将模块划分为纯粹的逻辑，开发人员很容易将其破坏。可能会出现一个核心模块，该模块逐渐变成垃圾堆，模块之间的依存关系图可能会增长，依此类推。为避免此类问题，开发应该由非常成熟的团队来进行，或者在“架构师”的指导下进行，该“架构师”专职从事代码审查，并击败违反逻辑结构的开发人员。
“理想的”整体是一组逻辑上分开的模块，每个模块都查看其自己的数据库。
面向服务的架构
但是，如果应该以一组服务的形式组织系统，那么我们在谈论的是面向服务的体系结构。它的原则是：面向用户的应用程序的互操作性，业务服务的可重用性，与一组技术的独立性和自治性（独立的演化，可伸缩性和可部署性）。
面向服务的体系结构（SOA）解决了所有组件概述的问题：更改仅影响一项服务，并且定义明确的API支持良好的组件封装。
但是并非一切都如此顺利：SOA引入了新问题。远程呼叫比本地呼叫昂贵，并且组件之间职责的重新分配也变得更加昂贵。
顺便说一句，独立部署的能力是服务的一个非常重要的功能。如果要一起部署服务，或者按特定顺序部署更多服务，则不能认为该系统是面向服务的。在这种情况下，他们说的是分布式整体（不仅从SOA的角度来看，而且从微服务体系结构的角度来看，它都被视为反模式）。
面向服务的体系结构得到体系结构社区和供应商的良好支持。因此，有许多课程和认证，完善的模式。后者包括，例如，未知的企业服务总线（ESB =企业服务总线）。同时，ESB是供应商的负担，不必在SOA中使用。
面向服务的体系结构在2008年左右达到顶峰，此后开始下降，随着微服务的出现（到2015年）变得更加尖锐。
结论
在讨论了以服务和模块形式组织信息系统的可能性之后，我建议最后继续讨论微服务架构的原理，并在下一部分中特别关注微服务架构和面向服务的架构之间的区别。
