我读过Martin Fowler撰写的一篇文章“Microservices”，发现很难理解智能端点和哑管。请解释这些术语，欢迎举例。
答案 0 :(得分：16)
我没有读过这篇文章，所以我只能推测他的意思究竟是什么，但是他给ESB作为反对微服务的例子，ZeroMQ作为微服务的一个例子，我希望我的猜测非常准确： / p>
Unix（和Linux）的一个想法是构建小型独立应用程序并通过管道连接它们。我正在使用的最常见的两个命令集是ps和grep，如下所示：ps aux | grep PROCESS_NAME - 在这里你可以看到一个只传递{{1}输出的哑管转到ps的标准输入。
像ZeroMQ这样的其他消息传递系统的工作方式类似，尽管它们可以像循环分配和可靠的交付那样具有更多的复杂性。 Erlang作为一种语言建立在彼此之间发送消息的小型智能端点之上。这里的优点很明显，并且在文章中也提到过，小应用程序更易于维护，解耦使其更容易扩展。
另一方面，微服务是最常见的大型企业应用程序，如上面提到的企业服务总线。我并没有真正使用那些足以给你一个具体例子，但通常这些总线包含许多功能，这些功能可以通过脚本或配置包含在内。此类功能主要包括具有高级路由的可配置工作流，甚至可以转换消息，因此不同的端点可以处理它们。
一个例子可能是 - 如果你想在系统中执行一些高级操作，例如更改已经运行的项目中的需求，这可以启动一个工作流，ESB会自动向不同的演员发送不同的通知那些更改的要求并等待这些参与者中的一个或多个确认之后将应用此更改。这基本上是相反的 - 哑终点（只是向/从总线发送/接收数据）和一个非常智能的管道（总线，可以配置或编写脚本来处理所有可能的企业场景）。
我非常有信心存在处理类似场景的企业服务总线，而这些是与简单的“哑”类ZeroMQ消息传递框架相反的。
基本上逻辑必须在某个地方实现 - 无论是在大ESB中还是在端点中。微服务的想法是将它放入端点而不是总线，并具有与unix应用程序类似的原则。
答案 1 :(得分：14)
我认为Martin Fowlers的文章因错误描述'ESB'概念而严重缩短。这种错误描述很普遍。你有多少次看到一个代表“总线”的图表作为消息流动的管道？我当然失去了数量，这让我每次都很畏缩。 “公共汽车”不是管道。它是一种在分布式，面向服务的环境中使“支持服务”易于访问的机制。经典的比喻是工厂的母线。虽然电流流过汇流条，但这并不是它的“公共汽车”。它是一辆“公共汽车”，因为它贯穿生产车间的全长。任何机械（服务实施）都可以轻松地进入酒吧以获得动力（来自发电服务），无论机器恰好位于何处。总线是一种无处不在的推动者，它支持灵活性并随着时间的推移而变化。
服务总线上唯一存在的是服务，作为一般原则，它们最好尽可能地作为微服务实现。 “智能端点，哑管”的口号在微服务出现之前就已经过时了。多年前，我第一次从与Microsoft BizTalk团队的成员一起在与ESB的主要倡导者的公开辩论中听到它。 ESB的人提倡非常细粒度的独立转换服务（微服务）的可取性，而不是典型的BizTalk方法，其中转换应用于端点（智能端点）。 ESB的人批评BizTalk，声称它是“单一的”，因此无法用于实现这种细粒度，可独立部署的服务。 BizTalk的人指出他实际上是错的（后来在BizTalk ESB工具包中进行了演示），但重点是在消息端点（从集成角度）进行转换而不是在某些中间服务的下游进行转换的一般愿望在交换中调用（概念上，在“管道”的下方）。
这是严肃的从业者之间的成熟辩论。在这一点上我同意了BizTalk的人 - 智能终端，哑管。具有讽刺意味的是，ESB家伙在ESB环境中有效地推广了微服务方法。对我来说，这是一个很好的例子，说明微服务口头禅与任何其他哲学一样，可以走得太远。
答案 2 :(得分：5)
系统中的组件使用“管道”（HTTP / S，队列等......）相互通信。通常，这些管道流经ESB（企业服务总线），后者对组件之间传递的消息执行许多操作。
它可能会：
完成这些任务后，消息将被转发到“端点”组件。这是“智能管道”的一个例子，因为许多逻辑和处理驻留在ESB（“管道”系统的一部分）内。然后，当ESB完成所有工作时，端点可能会“哑”。
“智能终端和哑管”提倡相反的情景。通信通道应该被剥夺业务处理和逻辑，并且应该只在组件之间分发消息。然后是组件本身对这些消息进行处理/逻辑/验证等。
答案 3 :(得分：2)
这是一个非常笼统的问题。我会尽量保持这种状态
智能终端
智能端点仅表示实际的业务规则和任何其他验证，发生在这些端点之后，这些端点的消费者对任何人都不可见，将其视为发生实际魔术的地方。
哑管道
哑管道意味着没有进行任何其他操作（例如进行验证）的通信手段，它只是跨特定通道传输数据，并且如果需要的话也可以替换。
答案 4 :(得分：1)
根据Martin Fowler的说法：“常用的第二种方法是通过轻量级消息总线进行消息传递。所选择的基础设施通常是愚蠢的（如同仅作为消息路由器那样愚蠢）”。
使用智能端点的基本原理隐含在：“组件的关键属性是独立替换和可升级性的概念 - 这意味着我们寻找可以想象在不影响其协作者的情况下重写组件的点。”
为了支持后者，微服务需要容忍其消费者。例如。稍后添加强制输入参数会破坏接口，因此应该避免。相反，应该使用补偿策略，如默认值，或支持某种内部“路由”，以便微服务仍然能够给出有效的响应。这是一种聪明的“终点”。
答案 5 :(得分：-1)
哑管只是指点对点连接。终点完成所有工作，任何复杂性都取决于连接它们的机制。我认为人们在谈话中谈论ESB，因为在企业环境（以及许多其他环境）中，哑管（点对点连接）是一个糟糕的想法。 ESB不是“哑管”。 ESB几乎是非常智能管道的良好定义。并且它们有助于控制令人难以置信的毛茸茸的混乱，只要您有多个需要相互通信的服务，就可以创建点连接。
WSO2刚刚在微服务上创建了一系列优秀的网络研讨会，他们谈论了这个概念。但即便他们也不愿意使用哑管的概念。
现在，如果服务纯粹是临时使用而不是在尝试管理复杂的企业系统时，那么哑管是有意义的。为每个服务设置多个网络连接是最少的。