在微服务环境中了解AMQP RabbitMQ

在设计Datapath.io软件体系结构时,我们很快就部署了分布式微服务。 目标是衡量一小组关键的Internet性能指标(KPI)。 在决定使用哪种编程语言之后。 为了获得所需的测量结果,我们使用Java。

分布式微服务需求

为了确定我们的分布式微服务协议,我们需要一些需求。 首先需要有一个可以与无状态微服务通信的工具。 这是通过开放Internet在全球范围内分发的微服务。

第二个需要是它应该具有一种机制来维持对等端之间的稳定连接。 这是至关重要的,因为Internet会更改其基础拓扑和基础结构。 防火墙可能会更改,边界网关协议(BGP)会话可能会失败,并且子网可能不可用。

AMQP RabbitMQ可以承受这些故障情况。

Datapath.io AMQP RabbitMQ用例

当前,我们对网络前缀中以主机表示的Internet进行ping操作。 我们每30分钟从全球80多个位置ping通。 我们还请记住,结果已传输到中央存储。

最后,我们研究了流行的Java客户端的AMQP实现。 这导致我们进入RabbitMQ。 它是用Erlang实现的,着重于简单性和高吞吐量。 此外,它还包含用于水平可伸缩性的分片功能。 Google在消息吞吐量约为每秒10 Mio的情况下使用RabbitMQ。 这超出了我们当前的用法,但是是一个令人印象深刻的用例。

我们如何使用RabbitMQ

我们使用3.5.6 RabbitMQ服务器进程作为主持人。 这样每30分钟分发一次ping请求,并接收结果。 RabbitMQ将消息发送到不同的队列,以解决世界各地不同的主机。 结果是队列中的任何主机都知道应该处理的内容。

然后使用Ubuntu 14.04 LTS上的Erlang HiPE库进行编译。 它在具有默认配置的16核64GB内存主机上运行。

当Ping接收器/请求器开始时,它通过身份验证将其自身连接到RabbitMQ主机。 然后它将等待消息开始工作。

ping过程的结果将发送到另一个称为ping接收器的队列。 ping接收器接收所有消息,将其转换为我们的数据格式,并将其存储在HDFS群集上。 这就是Datapath.io利用大数据的方式。

如果ping接收器进程崩溃怎么办?

RabbitMQ也能够具有持久队列。 消息会一直保留直到有人要求。 可以将生存时间添加到消息中。 一段时间后,这将使它们可移动。 考虑一个由于网络故障而失去连接的测量站。 消息泛滥了RabbitMQ服务器。

最大的任务是提高我们用于通信的消息格式的可伸缩性。 这就是“消费者与生产者”的问题。

RabbitMQ可扩展性

如果像Ping-Requester这样的生产者比消费者产生更多的消息,那么您将面临严重的问题。 结果是RabbitMQ开始“限制”队列。 请记住,在使用者中完成的工作已经过优化。 解决方法如下:

缩放消费者的主机(水平或垂直)。 对于Datapath.io,都不是一个选择。 水平缩放的副作用(创建更多消费者)太复杂了。 垂直缩放的成本太高。

可伸缩性解决方案

结果是使用了不同的解决方案。 我们开始在发件人端缓存消息,并建立了上万个消息包。 这避免了AMQP RabbitMQ的开销,并将节流减少到了零。

现在,我们每30分钟向ping请求者发送70条消息。 这会ping所有635K网络前缀,而不是635K单个消息。 差异为70,而不是预期的63; 由于缓冲区的清除算法。

请记住使用序列化格式。 像“数据格式”这样的开销较小。 对于您的方案,Java或String序列化的结果可能太大。

起初,节流功能似乎是一个障碍,但是它的使用可能会有所帮助。 它将帮助您在微服务应用程序消息流中发现瓶颈。

最初发表在 Datapath.io博客 上的 文章