您真的在为您的应用程序使用微服务吗？再想一想。

免责声明警告：这将是那些纯粹主义者的文章之一，这些文章解释了你如何没有做你认为你正在做的事情，仅仅是因为你并不真正了解你认为你正在做的事情的完整定义。

如果您对此表示满意，那么我们可以继续。

您是否曾经定义或实现过基于微服务的架构？你可能错了。对不起，今天我扮演的是“定义警察”的角色。

你最有可能处理的不是微服务，而是：迷你服务。让我们试着解释一下为什么会这样，以及为什么错了是可以的。

微服务，迷你服务，它们都是小服务，不是吗？

我的意思是，是的，你没有错，事实上，这不是混乱发生的地方。

我们倾向于将“微服务”视为小型的、非常注重逻辑的服务，通常处理一项职责。然而，如果我们看一下 Martin Fowler 对微服务的定义——你知道，他是一个非常聪明的人，所以我们通常想知道他的想法——你会注意到我们缺少一个非常小的但关键的微服务特征: 解耦。

让我们仔细看看我们所说的“微服务”。近来这个词被广泛流传，以至于到了与青少年性行为完全一样的地步：每个人都在谈论它，没有人真正知道该怎么做，每个人都认为其他人都在做，所以每个人都声称他们在做.

说实话，在我作为经理接受的 99% 的采访中，当我询问微服务时，我会得到关于 REST API 的回答。不，它们不一定是同一回事。

根据定义，单独的 REST API 不能是微服务，即使您将它们分成多个较小的，每个负责单一的职责。他们不能，因为根据定义，您要能够直接使用 REST API，您需要了解它。

作为相关的旁注：有两种类型的 REST 开发人员（意味着开发人员创建 REST API）：

• 那些实现了他们认为需要的尽可能多的关于 REST 的特性。这意味着如果他们愿意，他们可能会关心面向资源的 URL，也许他们会担心他们的 API 是无状态的，因为实现起来并不难。但是这种类型的开发人员将在 99.9% 的时间里放弃 HATEOAS（超媒体作为应用程序状态的引擎）。换句话说，API 结构的自发现性不再是一个特性，客户端和服务器在两者之间有一个硬编码的契约。
  
• 严格遵守 REST 标准的那些。我想在我的经验中我只见过一个这样的开发者——所以如果你是这样的，请发表评论，让我们联系！— .以这种方式实现 REST API 可能需要更长的时间，但结果要好得多，尤其是因为客户端与服务器的耦合非常少，他们只需要知道它在哪里以及根端点是什么。其余的都是通过自我发现完成的，非常酷。
  

但是，在这两种情况下，客户端和服务器之间的耦合仍然存在。你不能仅仅通过 REST 获得解耦的通信，这就是为什么如果我们对微服务的定义很严格——而且我们正在努力做到——就不能这样称呼它们。

所以相反，让我们松开定义的腰带，给自己留一些回旋的空间，把这些服务称为：迷你服务。

所以我们可以定义一个小服务为：

足够小的服务（通常是 API）被认为是“迷你”，它们仍然只需要处理一个单一的责任，但是，我们不太担心“与客户端解耦”部分。

诚然，它们的耦合越少，对未来的变化就越有利，拥有一个动态客户端肯定有助于更快地调整，并且对服务器上的变化没有太大影响。这绝对是一个优点，但这不是我们定义的一部分。

提示：使用独立组件构建，以提高速度和规模

与其构建单一的应用程序，不如先构建独立的组件并将它们组合成服务和应用程序。它使开发速度更快，并帮助团队构建更一致和可扩展的应用程序。

像 Bit 这样的 OSS 工具为构建独立组件和编写应用程序提供了出色的开发人员体验。许多团队从通过独立组件构建他们的设计系统或微前端开始。

试试看→

An independently source-controlled and shared “card” component. On the right => its dependency graph, auto-generated by Bit.

那么什么是微服务呢？

如果我们想获得技术，根据定义，我们仍然在处理一个处理单一职责的服务，但同时它能够与任何使用它的客户端分离。

那么我们如何才能实现这种解耦呢？诀窍是在服务之外思考：沟通渠道。

我们倾向于假设微服务 = REST API，同时，REST API 倾向于自动与客户端-服务器通信范式相关联。就这样，我们在一瞬间从微服务变成了客户端-服务器。但让我们倒带一下。

不久前，我写了一篇关于我最喜欢的服务间通信模式的文章，其中我列出了一个特定的选项：异步消息传递。

该选项不会直接连接客户端和我们的服务，而是需要一个中央消息总线来负责在客户端和服务之间来回传递消息，而无需它们彼此了解。你能看到我们刚刚到达那里吗？没错，我们通过一个简单的范式改变将客户端和服务器完全解耦。

看上图，客户端应用程序用一条消息启动一个潜在的多服务请求。它甚至不必知道涉及多少服务，这太棒了。这意味着编排复杂的请求序列不再是客户责任的一部分。这是一个伟大的交易！

最终，客户端应用程序最终会收到它正在寻找的结果。我在这里说“最终”是因为这不是一个同步通信模型，考虑到它的工作原理，它需要是异步的。这不一定是个问题，它只需要改变我们为客户编写代码的方式（以及我们的其他微服务，考虑到这也是他们相互交谈的方式）。

让我们真实一点：基于消息总线的通信模型不仅可以让您正确地将服务称为“微服务”，它还提供了一些不错的优势：

• 您的整个架构，包括您的客户端应用程序的架构，都变得反应式。在我的书中，这是一个了不起的优势，尤其是当您处理本质上需要很长时间才能解决的请求时。也许您正在处理非常复杂的计算、运行一些 ML 模型，或者只是从其他第三方 API 收集数据。无论是什么原因，您的客户都可以在等待响应时继续做其他事情，而不是被活动连接锁定，希望它不会超时。事实上，在我最近的这次演讲中，我介绍了反应式架构的一些好处以及如何使用 Redis 创建一个：
  
• 水平扩展您的服务非常容易。对于耦合实现，例如让 REST API 直接与客户端对话，您需要有某种负载均衡器或 API 网关，以允许您在同一微型服务的所有副本之间分配负载。但如果我们处理的是解耦架构，我们不必担心，第一个接收消息的微服务会处理它，让副本自由处理下一个传入的消息。
  
• 添加新服务对客户端没有直接影响。如果你问我，这很残酷。因为通过客户端-服务器通信，添加新服务（因为您正在添加新功能或因为您决定拆分现有服务）意味着客户端现在需要知道在不同情况下与谁联系。要么，要么您将编排移动到所有请求都到达的中央 API，但是，在这种情况下，您还必须更新服务上的编排逻辑。当然，客户端不受影响，但您仍然有副作用。有了基于微服务的架构，情况就不再如此了。编排由消息总线完成，使添加几乎没有影响。
  
• 更容易重试和更有弹性的架构。这是两个非常相关的点。一方面，您必须担心如果您的服务因任何原因而死（或至少无法访问）会发生什么。对于客户端-服务器通信，这意味着请求将失败。然而，对于消息总线来说，这仅仅意味着在服务恢复之前请求不会完成。消息总线可以将消息存储一段时间，从而允许创建更具弹性的架构。同时，如果你想在失败时有某种重试逻辑，正如我已经提到的，这对于基于微服务的架构是隐含的，而你必须自己为客户端-服务器架构编写代码。
  

还不相信？真的吗？那可能是因为你的用例不是微服务的完美匹配。也许迷你服务是适合您的解决方案。

本文的主要内容是了解虽然“正式已知的微服务”可能很棒，但它们并不是每个架构都必须使用的。

这都是关于权衡的。微服务可能需要在基础设施层面做更多的工作，甚至可能需要让你的开发团队正确地思考异步通信。然而，从长远来看，最终产品可能会产生更好的结果和更少的麻烦。