用于微服务和ML解决方案管道的消息队列（Kafka和Zookeeper）

本文会演示使用Apache Kafka和Zookeeper进行微服务通信以及如何开始的基本流程。

微服务体系结构是一种将大型单一应用程序与另一个互相连接的独立模块（应用程序）以及使用API的外部数据源分离的原则。为了处理这些微服务和微服务 - 外部源通信，无论是API调用还是密集的数据处理，阻塞使用同步模型会导致整个应用程序无响应的线程，消息队列都会发挥作用。

Apache Kafka就是这样一个平台。正式地，它被称为具有高弹性和容错性的分布式流处理平台。这是通过在分布式系统协调中使用众多计算节点集群而获得的，其中由另一个称为zookeeper的apache平台维护。

这里是基本流程：

启动Zookeeper（为了协调）。
启动Kafka服务器（基本上是一个broker，在这种情况下，调解发布者[生产者]和订阅者[消费者]之间的消息）。
Producer API（为了创建消息并排入Kafka）。
消费者API（为了消费来自Kafka队列的消息）。

（为此目的，我将使用控制台生产者和消费者进行简单的演示和理解）。

安装

安装Kafka和Zookeeper。

启动Zookeeper

运行以下脚本：

sh kafka / bin / zookeeper-server-start.sh ../config/zookeeper.properties
复制代码

现在动物园管理员监控已经准备就绪，我们可以开始我们的Kafka，这是消息中介。

sh kafka / bin / kafka-server-start.sh kafka / config / server.properties
复制代码

默认情况下，它在9092端口上运行，Kafka服务器作为代理。

所有推送到Kafka的消息在逻辑上被分类为“主题”。如果一个主题不存在，Kafka被配置为默认创建一个主题，但创建主题比较明智，因此我们可以在逻辑上区分我们的消息。这就是消费者如何查询Kafka的方式：“给我一个这个话题的消息。”

（注意：所有基本的基本任务，如创建，查看和删除主题，控制台消费者生产者操作等都预先捆绑在Kafka二进制文件中，我们可以通过给出适当的参数来使用它们）。

创建一个主题

sh kafka-topics.sh  - 创建 -  zookeeper localhost：2181  - 复制因子1 - 分区1 - 主题topic_name
复制代码

分区和复制因子

默认情况下，Zookeeper监视器在端口2181端口上运行。Kafka主题分为不同的分区。分区通过将特定主题中的数据分散到可能存在于不同计算节点中的多个代理，从而实现主题的并行化。标志“复制因子”决定了主题分区的副本数量。这是如何实现容错的。一个broker可能会失败，消费者仍然可以使用现场副本中的消息。同时，zookeeper管理员将监督宕机broker并采取纠正措施。

现在我们有一个Zookeeper和一个broker在运行一个主题，我们准备发送消息给Kafka并使用它们。在现实世界的软件中，这是通过流媒体API实现的，但出于演示目的，我们将使用基于控制台的制作者和消费者。

开始制作人：

sh kafka / bin / kafka-console-producer.sh --broker -list localhost：9092  - topic topic_name
复制代码

开始消费者：

sh kafka / bin / kafka-console-consumer.sh --bootstrap -server localhost：9092  - topic topic_name
复制代码

现在，无论输入到控制台制作者的什么输入都会通过Kafka传递给控制台用户。

我们还可以查看现有的消息：

斌/ kafka-console-consumer.sh --bootstrap -server本地主机：9092 --topic TOPIC_NAME --from -beginning
复制代码

Kafka是流处理的分布式消息传递平台。它更像是一个在分布式计算环境中建立的荣耀企业消息传递系统，并具有连接器以连接到外部数据源。

排队的需要

微服务体系结构固有地要求某种消息排队系统。当我们将一个庞大的单一应用程序拆分为更小，松散耦合的微服务时，这些微服务中REST API调用的数量就会增加，连接外部数据源的次数也会增加。保持这样一个巨大的互联系统同步是不可取的，因为它可以使整个应用程序无响应，并可以摆脱首先分裂成微服务的全部目的。因此，像Kafka这样的分布式平台上有一个消息队列系统，该系统具有高度的容错能力，并且通过像Zookeeper这样的服务持续监视代理节点，从而使整个数据流更加容易。

ML解决方案管道中的消息队列

像Kafka一样排队的另一个用例可以是各种ML解决方案管线。以非常简单的方式，这就是ML解决方案的构建方式：

客户端（移动，网络）上的用户界面 - →API服务器和数据库 - →机器学习（黑盒）。

机器学习黑盒可能非常计算量大，并且在阻塞同步模式下发出这些请求是不现实的。在这种情况下，可以将所有请求排队，并将消费者API配置为逐个接收这些请求并将它们提供给ML黑盒。该管道可以轻松处理计算密集型任务 - 例如识别来自数千个图像的对象，这需要相当长的时间 - 而不会丢失任何请求。

部署在容器中的微服务彼此交谈，由容错分布式的代理节点集群进行协调，并使用像Zookeeper这样的工具进行监控，看起来像是企业软件开发的新方式。