是微服务设计模式或架构

Question

在进行严格的研究和分析后，我终于到达了使我感到困惑的点"是微服务模式或架构"。有人说，这是一种进化的模式，以解决整体应用的解决方案，因此设计模式毫无疑问，这是一个架构，讲述了他们的发展，管理，可伸缩性，自动及其;全栈。我欢迎任何想法或建议。

Answer 1

微服务可以最好地描述为建筑风格。除了建筑决策外，该样式还包括组织和过程相关的注意事项。

建筑元素包括：

1. 按业务关注的组成。
2. 严格的持久性脱钩。
3. 定义明确的接口和通信。
4. 目标尺寸较小。

组织元素包括：

1. 团队组织围绕组件(康威定律(。
2. 团队规模限制(两只比萨团队(。

过程相关元素包括：

1. 较少集中的治理。
2. 较小，更频繁的版本。
3. 技术决策的自由度更高。
4. 面向产品的开发(敏捷，MVP，精益等(。

有关更多详细信息，我建议阅读Martin Fowler的文章。

Answer 2

我将其描述为需要应用程序功能分解的软件架构样式。

通常，它涉及单片应用程序被分解为多个较小的服务，每个服务都在其自己的档案中部署，然后使用标准轻量级通信作为一个应用程序组成，例如在HTTP上休息或某些异步通信(当然，当然，，在某个时候，微服务是从头开始写的(。

微服务中的"微观"一词没有指示服务中的代码行，它仅表示范围仅限于单个功能。

每个服务都是完全自主且全堆栈的。因此，改变服务实现对其他服务使用明确定义的接口进行通信时没有影响。这种申请有几个优点，但它不是免费的午餐，并且需要大量的努力。

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

• 单一目的 - 每个服务都应专注于一个单一目的并做得好。
• 松散的耦合 - 服务彼此了解甚少。更改一项服务不需要更改其他服务。服务之间的沟通应仅通过公共服务界面进行。
• 高凝聚力 - 每种服务都将所有相关的行为和数据封装在一起。如果我们需要构建一个新功能，则所有更改应仅本地化为一项服务。