微服务：啥是智能端点和哑管道？

Posted 2023-02-16

【中文标题】微服务：啥是智能端点和哑管道？

【英文标题】：Microservices: What are smart endpoints and dumb pipes?微服务：什么是智能端点和哑管道？

【发布时间】：2014-12-24 08:48:34

【问题描述】：

我阅读了 Martin Fowler 的文章“Microservices”，发现很难理解智能端点和哑管道。请解释这些术语，欢迎举例。

【问题讨论】：

观看此视频：youtube.com/watch?v=2yko4TbC8cI

【参考方案1】：

这是一个很笼统的问题。我会尽量保持这种状态

智能端点

智能端点仅仅意味着实际的业务规则和任何其他验证发生在这些端点之后，这些端点的消费者对任何人都不可见，将其视为实际魔术发生的地方。

哑管道

哑管道是指任何不进行进一步操作（例如验证）的通信方式，它只是通过该特定通道传输数据，并且如果需要也可以替换。

【参考方案2】：

根据 Martin Fowler 的说法：“第二种常用方法是通过轻量级消息总线进行消息传递。所选择的基础架构通常是愚蠢的（愚蠢的，因为仅充当消息路由器）。

使用智能端点的基本原理是：“组件的关键属性是独立替换和可升级性的概念 - 这意味着我们寻找可以想象重写组件而不影响其协作者的点。”。

为了支持后者，微服务需要对其消费者具有包容性。例如。稍后添加强制输入参数会破坏接口，因此应该避免。相反，应该使用补偿策略，如默认值，或支持某种内部“路由”，以便微服务仍然能够给出有效的响应。这是一种智能的“端点”。

【参考方案3】：

哑管道仅表示点对点连接。端点完成所有工作，任何复杂性都从连接它们的机制中消除。我认为人们在这次谈话中谈论 ESB，因为哑管道（点对点连接）在企业环境中（以及在许多其他环境中）是一个糟糕的想法。 ESB 不是“哑管道”。 ESB 几乎是对非常智能的管道的一个很好的定义。当您有多个需要相互通信的服务时，它们有助于控制点对点连接所产生的令人难以置信的混乱局面。

WSO2 刚刚创建了一组关于微服务的优秀网络研讨会，他们讨论了这个概念。但即使他们也回避使用哑管道的概念。

现在，如果服务纯粹用于临时基础，但在尝试管理复杂的企业系统时，哑管道是有意义的。为每个服务设置多个网络连接是最少的。

【讨论】：

哑管道并不意味着 P2P 连接。 Martin Fowler 的microservices article 说“选择的基础设施通常是愚蠢的（愚蠢的，因为它只充当消息路由器）”。这只是意味着路由是管道应该执行的唯一功能：将业务逻辑、转换等排除在外。话虽如此，将所有这些功能都推送到端点中并不总是有意义的，尤其是在企业集成场景中，因为并非所有端点都具有相同的功能。

【参考方案4】：

系统中的组件使用“管道”（HTTP/S、队列等）相互通信。通常这些管道流经 ESB（企业服务总线），它对在组件之间传递的消息执行许多操作。

可能会：

安全检查 路由 业务流程/验证 转型

一旦完成这些任务，消息将被转发到“端点”组件。这是“智能管道”的一个示例，因为大量逻辑和处理驻留在 ESB（“管道”系统的一部分）中。由于 ESB 已完成所有工作，因此端点可能会变得“哑”。

“智能端点和哑管道”提倡相反的情况。通信通道应该被剥离业务处理和逻辑，并且应该只在组件之间分发消息。然后是组件本身对这些消息进行处理/逻辑/验证等。

【参考方案5】：

我认为 Martin Fowlers 的文章因错误地描述了“ESB”概念而严重不足。这种错误描述很普遍。您有多少次看到将“总线”表示为消息流向下的管道的图表？我当然已经数不清了，这让我每次都畏缩。 “总线”不是管道。它是一种使“支持服务”在分布式、面向服务的环境中易于访问的机制。经典的类比是工厂中的母线。尽管电流流经母线，但这并不是它成为“公共汽车”的原因。它是一辆“公共汽车”，因为它贯穿整个制造车间。任何机器（服务实现）都可以轻松接入酒吧以获取电力（来自发电服务），无论该机器恰好位于何处。总线是无处不在的推动者，支持灵活性和随时间的变化。

服务总线上唯一存在的东西是服务，作为一般原则，它们最好在可能或需要的情况下实现为微服务。 “智能端点，哑管道”的口号可以追溯到微服务出现之前。多年前，在与 ESB 的主要倡导者的公开辩论中，我第一次听到 Microsoft BizTalk 团队的成员。 ESB 人提倡非常细粒度的独立转换服务（微服务）的可取性，而不是在端点（智能端点）应用转换的典型 BizTalk 方法。 ESB 家伙批评 BizTalk，声称它是“单片机”，因此不能用于实现这种细粒度、可独立部署的服务。 BizTalk 人指出他实际上是错误的（正如随后在 BizTalk ESB 工具包中所证明的那样），但主要的一点是在消息端点（从集成的角度）而不是在某些中间服务的下游进行转换的普遍需要在交换中调用（从概念上讲，在“管道”的下方）。

这是严肃的从业者之间的成人辩论。在这一点上，我同意 BizTalk 家伙的观点——智能端点、哑管道。具有讽刺意味的是，ESB 人在 ESB 环境中有效地推广了微服务方法。对我来说，这是一个很好的例子，说明微服务的口头禅，就像任何其他哲学一样，可以走得太远。

【讨论】：

如果我在这方面关注你，如果 ESB 本身不是管道，如何确保 ESB 环境中的管道？

这似乎是对 ESB 的辩护（当本文没有攻击 ESB 时），而不是回答什么是智能端点/哑管道的实际问题

这篇文章只是说 ESB 不是一个哑管道，并没有以任何方式批评 ESB。 “我们已经看到许多产品和方法都强调将重要的智能融入通信机制本身。企业服务总线 (ESB) 就是一个很好的例子，其中 ESB 产品通常包括用于消息路由、编排、转换和应用业务规则。”。也许你可以说他没有正确地描述 ESB，但我认为 ESB 显然不是一个愚蠢的管道是公平的

这篇文章是对 Martin Fowler 文章的回应。它并没有真正回答这里提出的问题，基本上是这样的：What are smart endpoints and dumb pipes?。或者如果确实如此，它是如此令人费解以至于不清楚，因此是一个非常糟糕的答案。

【参考方案6】：

我没有读过这篇文章，所以我只能推测他的确切意思，但是由于他以 ESB 作为微服务的例子，ZeroMQ 作为微服务的例子，我希望我的猜测会非常准确：

Unix（和 Linux）的想法之一是构建小型独立应用程序并通过管道连接它们。我正在使用的可能最常见的两个命令集是 ps 和 grep 就像这样：ps aux | grep PROCESS_NAME - 在这里你可以看到一个哑管道，它只将 ps 的输出转发到 grep 的标准输入.

ZeroMQ 等其他消息传递系统的工作方式与此类似，但它们的复杂性可能会更高一些，例如循环分发和可靠交付。 Erlang 作为一种语言是建立在小型智能端点之上的，它们相互之间发送消息。这里的优势很明显，文章中也提到过，小应用更容易维护，解耦更容易扩展。

另一方面，微服务是最常见的大型企业应用程序，例如前面提到的企业服务总线。我并没有真正与那些足以给你一个具体例子的人一起工作，但通常这些总线包含很多功能，这些功能要么通过脚本包含，要么通过配置包含。此类功能主要包括具有高级路由的可配置工作流，甚至可以转换消息，以便不同的端点可以处理它们。

一个例子可能是 - 如果您想在系统中执行一些高级操作，例如更改已经运行的项目中的需求，这可以启动一个工作流，其中 ESB 会自动向周围的不同参与者发送不同的通知这些更改的要求并等待其中一个或多个参与者确认，然后再应用此更改。这基本上是相反的——哑端点（只是向总线发送/接收数据）和一个非常智能的管道（总线，可以配置或编写脚本来处理所有可能的企业场景）。

我非常有信心，存在处理类似场景的企业服务总线，它们与简单的“愚蠢”ZeroMQ 式消息传递框架相反。

基本上，逻辑必须在某个地方实现——要么在大 ESB 中，要么在端点中。微服务的理念是将其放入端点而不是总线中，并且具有与 unix 应用程序类似的理念。

【讨论】：

在哑管上不错，谢谢！ JMS 经纪人原来也是愚蠢的？关于智能端点..如果我做对了，微服务=端点，有点像可以发送/接收消息的东西。端点之所以聪明，是因为它内部有逻辑，而不是中间件（例如 ESB）。对吗？

没错，端点有逻辑，我实际上在一个开源团队中做了一个项目，它使用 JMS 作为 ESB 的底层通信，所以它应该仍然相当愚蠢

Erlang 是一个值得补充的内容，但是因为您没有阅读文章，所以这个答案的大部分内容是对文章的解释。文章的前两段专门描述了 Unix 哲学（“从微服务构建的应用程序旨在尽可能地解耦和内聚——它们拥有自己的领域逻辑，并且更像是经典 Unix 意义上的过滤器”) 用于管道，并以 ESB 作为反例（"...强调将重要的智能融入通信机制本身。一个很好的例子是企业服务总线 (ESB)"）。