29

我读过 Martin Fowler 的一篇文章“微服务”，发现很难理解智能端点和哑管道。请解释这些术语，欢迎举例。

4

6 回答 6

30

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

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

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

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

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

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

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

于 2014-10-29T18:18:47.407 回答
14

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

服务总线上唯一存在的东西是服务，作为一般原则，它们最好在可能或需要的地方实现为微服务。“智能端点，哑管道”的口号可以追溯到微服务出现之前。多年前，我第一次从 Microsoft BizTalk 团队的一名成员那里听到它，当时是在与 ESB 的主要倡导者的公开辩论中。ESB 人提倡非常细粒度的独立转换服务（微服务）的可取性，而不是在端点（智能端点）应用转换的典型 BizTalk 方法。ESB 家伙批评 BizTalk，声称它是“单片机”，因此不能用于实现这种细粒度、可独立部署的服务。

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

于 2014-11-21T22:58:51.907 回答
11

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

它可能会：

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

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

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

于 2015-01-25T18:37:05.367 回答
6

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

智能端点

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

哑管道

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

于 2018-08-06T02:11:18.577 回答
1

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

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

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

于 2016-06-07T17:58:55.707 回答
-1

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

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

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

于 2016-02-12T18:14:37.210 回答