是微服务设计模式还是架构？

Question

经过严格的研究和分析后，我终于到了一个让我感到困惑的地方“微服务是设计模式还是架构”。 有人说这是一种模式演变为单片应用程序的解决方案，因此也就是设计模式 有些人确认这是一个架构，讲述了他们的开发，管理，可扩展性，自主性和安全性。全栈。 我欢迎任何想法或建议让我自己澄清。

Answer 1

微服务可以最好地描述为架构风格。除了架构决策外，该风格还包括组织和流程相关的考虑因素。

建筑元素包括：

1. 按业务关注进行组件化。
2. 在持久性方面严格脱钩。
3. 明确定义的接口和沟通。
4. 目标是缩小服务规模。

组织要素包括：

1. 围绕组件的团队组织（Conway法律）。
2. 团队规模限制（双披萨团队）。

流程相关元素包括：

1. 不太集中的治理。
2. 更小，更频繁的发布。
3. 技术决策的自由度更高。
4. 面向产品的开发（敏捷，MVP，精益等）。

有关详细信息，我建议您阅读Martin Fowler的articles。

Answer 2

我将其描述为需要对应用程序进行功能分解的软件体系结构样式。

通常，它涉及将一个整体应用程序分解为多个较小的服务，每个服务都部署在其自己的存档中，然后使用标准的轻量级通信（例如，基于HTTP的REST或一些异步通信）组成单个应用程序（当然，在某些时候，微服务是从头开始编写的）。

微服务中的“微”一词并不表示服务中的代码行，而仅表示范围仅限于单个功能。

每项服务都是完全自治和全栈的。因此，更改服务实现对其他服务使用定义良好的接口进行通信不会产生任何影响。这种应用程序有很多优点，但是它不是免费的午餐，需要在NoOps中付出很大的努力。

重要的是要注意，每个服务必须具有的属性：

• 单一目的-每个服务都应专注于一个单一目的并做到这一点。
• 松散耦合-服务彼此之间几乎一无所知。更改一项服务不应要求更改其他服务。服务之间的通信只能通过公共服务接口进行。
• 高内聚性—每个服务将所有相关行为和数据封装在一起。如果我们需要构建一项新功能，则所有更改都应仅本地化为一项服务。