微服务：什么是智能端点和哑管？
我读过Martin Fowler的一篇文章“微服务”，发现很难理解智能端点和哑管道 。 请解释这些条款，欢迎举例。
我没有阅读这篇文章，所以我只能推测他的确切意思，但是他以ESB为例，针对微服务和ZeroMQ作为微服务的一个例子，我希望我的推测非常精确：
Unix（和Linux）的想法之一是构建小型独立应用程序并通过管道连接它们。 我使用的最常见的两个命令是ps和grep如下所示： ps aux | grep PROCESS_NAME ps aux | grep PROCESS_NAME - 在这里你可以看到一个笨笨的管道，它只将ps的输出转发给grep stdin。
像ZeroMQ这样的其他消息传递系统的工作方式也是类似的，尽管它们可能具有更复杂一点的循环分布和可靠的传输。 Erlang作为一种语言建立在彼此之间发送消息的小巧智能终端之上。 这里的优点是显而易见的，在文章中也提到，小应用程序更容易维护，解耦更容易扩展。
另一方面，微服务是最常见的大型企业应用程序，例如上述企业服务总线。 我没有真正与那些足够给你一个具体例子的人一起工作，但是通常这些总线包含许多功能，这些功能或者通过脚本或配置包括在内。 这种功能主要包括一个可配置的工作流程和高级路由，甚至可以转换消息，因此不同的终端可以处理它们。
例如，如果您希望在系统中执行某些高级操作，例如更改已经运行的项目中的需求，则可以启动一个工作流程，ESB将自动发送不同通知给围绕这些已更改需求的不同主角并等待一个或多个演员确认，然后才能应用此更改。 这基本上是相反的 - 愚蠢的终端（只向总线发送数据/从总线接收数据）和一个非常聪明的管道（总线，可以配置或脚本处理所有可能的企业方案）。
我非常确信存在处理类似场景的企业服务总线，这些简单的“哑”ZeroMQ类似的消息传递框架正好相反。
基本上，逻辑必须在某个地方实现 - 无论是在大型ESB中，还是在端点中。 微服务的想法是把它放到端点而不是放在总线上，并且与unix应用程序有着类似的理念。
我认为Martin Fowlers的文章因“ESB”概念错误表征而变得非常短暂。 这种错误的特征是很普遍的。 你有多少次看到一个代表'总线'的图表作为消息流向的管道？ 我已经失去了重要性，每次都会让我变得w w。 '巴士'不是管道。 这是一种在分布式，面向服务的环境中提供“支持服务”的机制。 典型的比喻是工厂的母线。 虽然电力通过巴士线流动，但这不是'巴士'的原因。 这是一辆'巴士'，因为它贯穿着制造车间的全长。 任何机械（服务实施）都可以轻松地进入酒吧，以获得（从发电服务）的电力，无论机器恰好位于何处。 公共汽车是一种无处不在的支持者，它支持灵活性并随时间变化。
生活在服务总线上的唯一东西就是服务，作为一般原则，它们最好在任何可能或需要的地方作为微服务来实现。 “微型服务”出现之前，“智能终端，哑管”的口头禅回到了前面。 多年前，我首先从一位Microsoft BizTalk团队的成员那里听到了一位ESB领先倡导者的公开辩论。 ESB提倡非常细粒度的独立转换服务（微服务）的需求，而不是在端点（智能端点）应用转换的典型BizTalk方法。 ESB曾批评BizTalk，声称它是“单片”，因此不能用于实现这种细粒度，独立可部署的服务。 BizTalk人指出他实际上是错误的（随后在BizTalk ESB工具包中演示），但主要观点是在消息端点（从集成角度）进行转换的总体愿望，而不是某些中间服务的下游（在概念上，在'管子'下面）调用。
这是一个严重从业者之间长大的辩论。 在这一点上，我赞同BizTalk人 - 聪明的终端，傻瓜管。 具有讽刺意味的是，ESB人员在ESB环境中有效地推广了微服务方法。 对我来说，这是一个很好的例子，说明像其他任何哲学一样，微服务曼陀罗可以迈出一大步。
系统中的组件使用“管道”（HTTP / S，队列等）相互通信。 通常这些管道流经一个ESB（企业服务总线），它对组件之间传递的消息做了很多事情。
它可能会：
一旦完成这些任务，该消息将被转发到“端点”组件。 这是“智能管道”的一个例子，因为许多逻辑和处理驻留在ESB（“管道”系统的一部分）内。 随着ESB完成所有工作，端点可能会变得“愚蠢”。
“智能端点和哑管”主张相反的情况。 沟通渠道应该被剥离业务处理和逻辑，并且应该从字面上仅在组件之间分发消息。 那就是组件本身对这些消息进行处理/逻辑/验证等。
链接地址: http://www.djcxy.com/p/5825.html上一篇: Microservices: What are smart endpoints and dumb pipes?