Apache kafka 使用卡夫卡提高新服务的弹性

我在一个项目中工作，该项目开始创建独立的可部署服务。我们正在创建的服务应具有24/7正常运行时间的弹性

一些开发人员已经创建了一个关于使用什么技术的概念。为确保服务始终可用，应使用卡夫卡。例如，应该有一个简单的application/serverless函数，用于向项集合添加内容。薄层应该创建一条Kafka消息，该消息稍后将由实际应用程序处理

一开始，我觉得这种方法很奇怪。卡夫卡是系统间的交流。但是，进一步拆分应用程序以提高有限上下文的恢复能力是否有好处？我想不是。因为通过使用现代技术，应用程序可以非常有弹性。因此，我们可以只创建一个应用程序，而不是增加更多的复杂性

后来我了解到这种方法是一种类似CQR的方法。通过创建一个接收写操作的应用程序，它将与读操作完全分离。在这种情况下，卡夫卡将被用作事件系统。它可能不应该删除旧的消息，但是，我想知道这是否是一个好的方式，如果我得到的东西是正确的

您如何看待Kafka的需求和使用，以获得高可用性和弹性的应用程序？

这里的关键问题是

现代应用程序具有弹性

虽然从理论上讲这听起来可能是正确的，但仍有相当多的现代应用程序由于设计不佳、负载过大等诸多因素而惨遭失败

如果你的应用程序没有停机时间部署，MTBF平均无故障时间接近0，那么你的应用程序是有弹性的，你不需要寻找卡夫卡

卡夫卡复杂性

如果由于某种原因，您无法实现零停机时间或MTBF接近零，卡夫卡是一个强大的选择。原因很简单，您可以配置Kafka listener的重试功能，因此，如果您的应用程序关闭了一段时间，则在服务重新启动后仍可以处理该消息。此外，您还可以使用强大的Kafka流媒体功能，如事务处理

但请注意，Kafka只提供分区内消息的总顺序，而不是主题中不同分区之间的顺序

如果您有一个具有单个分区的主题，则可以保证其顺序。如果你的消费者表现良好，你不必担心

此外，由于消息处理将是异步的，因此无法保证消息何时被处理，因此，如果应用程序是面向某个应用程序的客户端，或者客户端正在等待响应，则会带来更大的复杂性

您可以评估Akka框架是否为您的应用程序增加了更多价值，因为您将获得以下功能：

事件驱动：使用actor，可以编写异步处理请求的代码，并专门使用非阻塞操作。 可伸缩性：在Akka中，由于消息传递和位置透明性，无需修改代码即可添加节点。 弹性：任何应用程序都会遇到错误并在某个时间点失败。Akka提供“监督”容错策略，以促进自愈系统。 响应性：当今的许多高性能和快速响应应用程序需要向用户提供快速反馈，因此需要以极其及时的方式对事件作出反应。Akka的非阻塞、基于消息的策略有助于实现这一点。

---

首先，感谢您的详细回复。我想让我感到紧张的是，在将一个应用程序拆分为两个并使用Kafka作为异步通信层的情况下，可能还需要拆分其他服务。考虑到您有30个服务需要具有弹性和高可用性，这意味着您有60个服务，并且与基于Kafka的通信协议有很强的耦合。是的，您的担忧是正确的。额外服务的管理将增加复杂性，通过卡夫卡进行协调将是一项挑战。有关更多详细信息，请参阅此链接