节点配置中的多个 RabbitMQ 或其他后端服务器

Multiple RabbitMQ or other backend servers in Node configs

我在 DevOps,我们的开发人员坚持认为他们在 Node.js 中编写的软件由于缺点只能指向单个后端服务器,无论是数据库、Web 服务器还是 RabbitMQ 服务器在 Node.js。这对我来说听起来很疯狂。这怎么可能?

local.js 文件中考虑这个

    rabbitmq:{
        host: "rabbit01.stage",
        port: 5672,
        username : "user",
        password : "pass",
        exchangeName: "exchange_blah",
        queueName: "queue_blah",
        name : "rabbit",
        max : 10
    }

将配置更改为

            host: ["rabbit01.stage", "rabbit02.stage" ],

破坏了应用程序,它试图在 localhost:5672

上找到 rabbit 服务器

我的 Google-fu 让我失望了,因为我不确定如何将这个问题正确地表达为可搜索的短语。

我是不是漏掉了什么?或者我们的开发人员应该RTFM?

您正在寻找的(并且您清楚地知道这一点)是聚类。您可以将您的开发人员指向这篇文章:https://www.rabbitmq.com/clustering.html

但是,下面有一个关键段落讨论了连接到集群配置:

Generally, it's not advisable to bake in node hostnames or IP addresses into client applications: this introduces inflexibility and will require client applications to be edited, recompiled and redeployed should the configuration of the cluster change or the number of nodes in the cluster change. Instead, we recommend a more abstracted approach: this could be a dynamic DNS service which has a very short TTL configuration, or a plain TCP load balancer, or some sort of mobile IP achieved with pacemaker or similar technologies. In general, this aspect of managing the connection to nodes within a cluster is beyond the scope of RabbitMQ itself, and we recommend the use of other technologies designed specifically to solve these problems.

要点是说开发人员应该只尝试维护与单个 DNS 条目的连接,并且应该使用某种基于 DNS 或 IP 的负载平衡来防止代码必须了解多个连接.

同一篇文章中列出了一些好处,其中大部分归结为在代码中处理它会增加代码的复杂性。一般来说,负载均衡器更擅长这样做,因为它们是专门构建的,并且了解这样做的复杂性。

如果要求开发人员在代码中处理此问题,他们将不得不编写负载平衡器或动态 DNS 查找的软件版本。与使用网络设备来处理需求相比,这将更容易出现错误和误算。

所以...虽然您的 node.js 开发人员 可以 做您想要的是正确的...但他们说他们应该做的是正确的 没有 这样做,因为与在硬件/网络层中这样做相比,在代码中这样做是个坏主意。