Kafka支持的分布式架构超越经典软件设计的五个原因

> Photo by Jaime Dantas- Agulhas Negras — Brazil

如今，云解决方案在曾经依赖于内部部署基础架构和高性能计算机体系结构（也称为基于大型机的系统）的巨型公司中日渐流行。 这种趋势首先由大型科技公司推动，尤其是那些被定义为FAAMG公司的公司。 考虑到这种思维方式，我决定写一篇文章，探讨使用Kafka作为主要消息代理来对抗传统的单片应用程序和大型机系统的基于事件的分布式系统的一些突出优点。

大公司为何将其软件栈转换为云计算？

毫无疑问，大型机是人类创造的最可靠，性能最高且最具成本效益的机器之一。 无论您是否反对它，我们都必须承认它的重要性，尤其是在1980年代直到二十一世纪初。

但是，随着近几年技术的进步，这种能力已被使用并发系统的许多超级计算机和以可扩展方式使用给定服务的多个副本的新分布式解决方案所超越。

市值巨大且技术预算无限制的公司过去致力于使用大型机来构建系统，尤其是在我们谈论金融行业时。 毕竟，其巨大的前期成本根本不是问题。 以最大的金融机构为例。 直到2000年代初期，它们中的绝大多数都是大型机驱动的机构。

直到2006年像Amazon Web Services这样的公司成立时，这种情况才发生了巨大变化。 从那时起，大多数银行，政府机构，航空旅行公司以及许多其他公司都希望驾驭这一波云计算浪潮。 没有公司会想念这艘现代软件架构的船。

当涉及到当今我们拥有的不同云架构时，异步架构将成为传统软件设计的未来替代品之一。 下面重点介绍一些将成为大型系统未来的原因。

1-费用

毫无疑问，对于初创和中型公司而言，基于云的解决方案比大型机软件便宜。 那么，像银行这样的100,000多个员工公司呢？ 那些已经拥有强大可靠的大型机系统的公司呢？ 要回答这些问题，我们必须在这里看到大局。 从长远来看，可以肯定的是，分布式系统的成本要比大型机架构中的MIPS（每秒数百万条指令）支付的成本低。

另一方面，就创建平台本身和支持与业务相关的服务所需的基础结构而言，前期成本可能非常昂贵。 即使是很长的路要走，一旦他们启动并运行，成本将随着时间的推移而大大降低。 总体而言，这些系统的成本低于大型机系统。

当我们谈论整体系统时，大型机平台有许多相似之处。 与微服务进行比较，我们看到了相反的成本方向。 换句话说，长期成本比创建和部署多个微服务要高得多。 这是事实，因为我们可以通过微服务不断地将业务价值部署到生产中的方式来拆分功能。 如果开发人员花几个月的时间来发布单个应用程序，这是无法实现的，这对于单片软件是正确的，因为他们需要更多的时间来开发。

2-人力

现在我们在这里输入一个有趣的话题。 早在1990年代，COBOL是真实的东西。 由于当时市场需求旺盛，地球上的各大高校都将其包含在课程中。 这种情况在2000年代初发生了变化，当时出现了新的编程语言来代替大型机系统。 目前，每年都有成千上万的新毕业生进入市场，他们拥有软件开发和云计算方面训练有素的技能。

这些曾经依靠COBOL开发人员的公司不得不适应这一新标准。 总而言之，全球范围内云专业人员的数量超过大型机专家的数量。 除此之外，当今许多COBOL程序员现在都将退休，我们预计在不久的将来将缺少这些专业人员。

3-敏捷

这也许是具有基于微服务和异步通信的分布式体系结构的主要优势之一。 这样做的原因是因为在微服务平台上开发和部署小功能比在大型机上开发新的子程序或例程要快。 在完整的自动化云系统中，敏捷团队能够在数小时甚至数分钟内将功能部署到生产中。

4-独立

没有公司希望仅在供应链中拥有一个供应商，尤其是当涉及该公司的核心服务：软件时。 大多数依赖大型机的公司就是这种情况。 IBM主导了这一市场，占全球所有大型机的90％以上。 相反，公共云提供商正在以健康的方式相互竞争，导致价格在过去五年左右的时间内大幅下降。

即使该公司决定拥有自己的数据中心（有时会发生这种情况），但由于该领域的市场多样化，因此它与特定的供应商也没有任何关系。

5—复杂性

最后，当大公司使用分布式系统将其后端基础架构迁移到云时，他们可以及时开发复杂的后端服务。 我的意思是，前端服务执行的许多操作现在都可以在后端中完全编码。 之所以如此，是因为在大多数情况下，当他们仅使用大型机时，便无法在大型机体系结构内完成诸如使用人工智能进行图像分析之类的操作。

结果，大多数时候公司会使用前端来执行这些操作，甚至使用特定的服务来提供这些操作。 相反，当选择微服务架构时，可以在没有任何主要技术障碍的情况下实现此操作。

Kafka

既然我们已经讨论了拥有一个完整的分布式平台的重要性，那么让我们来谈谈可用于支持此类设计的开源解决方案的类型。 Apache Kafka是用于管理和编排消息的最流行的消息代理组件之一。 已有10多年的历史了，Kafka已成为几乎所有大型和基于云的体系结构中的关键组件。

长话短说，Kafka被微服务，服务或第三方应用程序（如Hadoop）用作消息交换以进行数据分析。

> Kafka by Confluent

架构注册表

通过Kafka生成和使用的数据的完整性和控制权由Schema Registry进行。 所有治理，规则和结构都在Avro文件中定义，并且Schema Registry确保在Kafka上仅允许符合这些标准的消息。

Docker

大多数公共云提供商都提供Eka之类的KaaS（Kafka即服务）选项，并且像Confluent这样的公司也为本地数据中心提供客户支持。

在使用Kafka和Schema Registry开发微服务时，大多数时候我们需要在本地运行这些组件以测试我们的软件。 这是我们使用Docker的主要原因之一（当然是众多原因之一）。 使用Docker Compose，我们能够在个人计算机中运行多个容器，从而使我们能够同时运行Kafka和Schema Registry。

为此，我们需要使用以下图像创建一个名为Dockerfile的文件：

FROM confluentinc/cp-kafka-connect:5.1.2

ENV CONNECT_PLUGIN_PATH=”/usr/share/java,/usr/share/confluent-hub-components”

RUN confluent-hub install –no-prompt confluentinc/kafka-connect-datagen:latest

接下来，我们将创建名为docker-compose.yml的docker compose文件

最后，让我们在本地启动容器。

$ docker-compose up

当我们执行命令docker ps -a时，我们可以看到我们的容器正在运行。

如果您愿意，我已经在GitHub中包含了此代码。
https://github.com/jaimedantas/kafka

另外，您也可以使用由Marcos Vallim开发的令人敬畏的Java组件运行嵌入的Kafka和Schema Registry。
https://github.com/mvallim/spring-schema-registry/tree/master/spring-schema-registry-embedded

Spring Boot微服务

现在是时候创建我们的微服务了。 这里的想法是用Java创建两个微服务。 一个名为kafka-holder的人将包含一个执行付款的API端点。 收到此HTTP请求后，它将向Kafka发送一个Avro事件，并等待响应。
https://github.com/jaimedantas/kafka-holder

然后，服务kafka-service将使用来自Kafka的此消息，处理付款，并产生一个新事件，说明是否已处理付款。
https://github.com/jaimedantas/kafka-service

付款请求的Avro事件定义如下。

此处创建的体系结构使用Kafka和架构注册表来协调消息。

> Event-based architecture

请注意，这两个应用程序同时是消费者和生产者。 通过这种方法，我们可以分别扩展和缩减微服务。 这保证了我们不会浪费任何资源，我们正在真正需要的地方使用我们的资金。

该体系结构带来的另一个优势是，在给定的微服务出现任何停机的情况下，不会丢失任何消息。 这是指我们的项目中将拥有DLQ（死信队列）和良好的弹性解决方案。

万一我们需要找出给定交易发生了什么，我们还可以检查Kafka经纪人并在那里找到此特定事件。

这篇文章简要介绍了过去几十年中计算机功能和软件开发的历史。 它还显示了在处理大量服务和数据时使用分布式解决方案的一些关键优势。

如有任何疑问，请随时发表评论。

感谢您阅读！

www.jaimedantas.com