是否有一个特定的标准可以遵循，因此可以将某些东西称为“微服务架构”？

Question

过去我使用的是我认为的“微服务”。我们有一个服务发现，应用程序通过 REST 同步调用相互通信，我认为这称为请求/响应。

---

现在我们正在开发一个应用程序，它被简单地分解为多个小应用程序，这些应用程序通过使用 Kafka 发布/订阅来协同工作，可以说它们之间没有直接通信，也没有服务发现。

可以肯定地说这些也是“微服务”吗？或者我应该如何称呼它们？

Answer 1

正如一位评论者指出的那样——答案总是固执己见（而 stackoverflow 通常不是基于意见的问题的最佳场所），但我并不害怕给出我的答案以试图提供帮助。

我的观点与马丁·福勒和其他人在过去十年中教给我们的内容以及亚马逊维尔纳·沃格尔斯的开创性工作的见解相一致。他们的定义是，微服务不是一个定义明确的单一标准，而是一种可以包含分布式计算中一系列不同方法的架构风格。它们的共同点是在许多不同维度提供可扩展性的目标，但主要是系统复杂性、组织生产力、吞吐量和弹性——同时价格实惠。为了实现这一目标，设计应围绕以下内容：

1. 根据业务目标划分服务边界（一种领域驱动设计）。
2. 规模/服务范围受到限制（著名的两个比萨饼团队规模想法）。
3. 组织职责和维护方面的明确分离。这包括每个服务的独立团队和发布/维护周期。
4. 在所有层上拥抱自动化（云虚拟化、devops、CICD、基础设施即代码等如何成为流行的工具）。
5. 设计重点关注故障恢复操作，例如避免级联故障、定义的故障状态、回退等。

这些目标的结果也是采用分布式系统架构和水平可扩展性设计（无状态、计算和存储分离等）。 ）。

因此，如果您觉得您的设计符合这些原则，那么我认为您已经成功地应用了微服务架构风格。

如果您想了解有关这一思想流派的更多信息，我建议您这篇文章。