使用Kafka增强新服务的弹性

Question

我正在开始创建独立可部署服务的项目中。我们正在创建的服务应具有全天候的正常运行时间。

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

一开始这种方法听起来很奇怪。 Kafka是系统之间进行通信的东西。但更好地分割应用程序以增加有限上下文的弹性是否合适？我想不是我想的。因为通过使用现代技术，应用程序可以非常有弹性。因此，我们可以创建一个应用程序，而不是增加更多的复杂性。

后来我明白这种方法是一种类似CQRS的方法。通过创建接收写入的应用程序，它将与读取完全分离。在这种情况下，Kafka将用作事件系统。它应该不会删除旧消息但是，我想知道这是否是一个好的方法，如果我正确的事情。

您如何看待Kafka获得高可用性和弹性应用程序的要求和用途？

Answer 1

这里的关键问题是

现代应用程序具有弹性

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

如果您的应用程序具有零停机时间部署且MTBF（平均故障间隔时间）接近0，则您的应用程序具有弹性，您无需查找Kafka

Kafka复杂性

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

但请注意，Kafka仅对分区内的消息提供总订单，而不是在主题中的不同分区之间提供订单。

如果您的主题包含单个分区，则可以保证订购。如果您的消费者表现良好，您不必担心。

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

您可以评估Akka框架是否会增加更多价值，因为您将获得开箱即用的以下功能

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