消息代理的使用是否与Sam的相一致？

Question

在其中一个项目中，CTO选择使用message来连接微服务。这种软件的使用是否与微服务理论相一致？

试图回答问题

在seven的第12章中，作者提到了七个原则，包括分散所有的东西。该部分最后一段如下：

这一原则也适用于建筑。避免像企业服务总线或业务流程系统这样的方法，因为它们会导致业务逻辑和哑服务的集中。相反，与编排和哑中间件相比，更喜欢编排，使用智能端点确保将关联的逻辑和数据保持在服务边界内，有助于保持事物的凝聚力。

企业服务总线

在面向服务的体系结构(SOA)中实现相互交互的软件应用程序之间的通信系统

编配系统

计算机系统、中间件和服务的自动安排、协调和管理

编舞

设计身体运动序列(或其描绘)的艺术或实践，其中规定了运动、形式或两者。

哑中间件

我非常确信，有一些企业服务总线正在处理类似的场景，它们与简单的类似于ZeroMQ的消息传递框架相反.

智能端点

问:关于智能端点……如果我做对了，Microservice=终结点，某种可以发送/接收消息的东西。端点之所以智能，是因为它内部有一个逻辑，而不是在中间件(例如ESB)上。对吗？答:确切地说，端点具有逻辑，我实际上在一个开放源码团队中做了一个项目，它使用JMS作为ESB的底层通信，所以它应该还是相当愚蠢的。

问题

1. 在IT中，舞蹈的定义是什么？
2. 什么是哑中间件的例子？
3. 微服务是智能端点吗？
4. 在Microservices中使用消息代理，例如kafka、rabbitmq、zeromq和qpid是否是一种不好的做法？

Answer 1

好吧，我在这里试试。

首先，萨姆的观点被认为是“做”微观服务的正常方式，但也存在权衡。

所以：

1. 编舞是指演员按照一套共同的指令独立行动。这与编曲相反，那里有一个指挥中心，指挥球员做什么和什么时候做。业务流程通常与ESB相关联，ESB包含大量业务逻辑(考虑脚本和选择)，并将工作分配给服务。编舞更多地与事件驱动的系统联系在一起，其中服务向世界广播事件，而感兴趣的各方对这些事件采取独立的行动。
2. 哑中间件意味着中间件不会对其传输的消息的内容做出积极的反应。它根据信封上的地址将“东西”从A发送到B。在这方面，大多数消息传递中间件都是愚蠢的，尽管通常会增加一定程度的智能，以提供交付保证，例如，精确一次。可以说，这本身并不是智能，但在我看来，由于事务性问题和故障处理语义，这仍然有点太聪明了，但我们现在还不能这么做。相信我，当我说建筑师们一直在争论这件事的时候，萨姆会站在光和真理的一边，如果不是方便和简单的话。
3. 如果您有一个愚蠢的中间件，那么微服务绝对必须是智能端点，否则就会有一个最糟糕的脆弱(容易崩溃)系统。多少智慧取决于你如何处理过载和失败。看看Netflix用一种可重用的方式将这些智能添加到微服务中的所有好处，比如Hystrix。
4. 不是的。虽然中间件不应该太聪明，但它不应该是愚蠢的。卡夫卡、ZeroMQ等是高度复杂的子系统，当您想要正确地执行事件驱动的系统时。这并不意味着您必须使用它们，但它们有一些有用的特性。大多数大型系统都能做到这一点。同步内容是使用http请求/响应完成的。异步的东西使用消息传递。消息可以集中(Kafka)或分布式(本地ZeroMQ)，但是集中式消息可以很容易地使您免受服务故障/恢复的影响。