我在一个项目中工作，该项目开始创建独立的可部署服务。我们正在创建的服务应该具有24/7正常运行时间的弹性。
一些开发人员已经创建了一个关于使用什么技术的概念。为确保服务始终可用，应使用Kafka。例如，应该有一个简单的application/serverless函数，可以向项集合添加一些内容。薄层应该创建一个kafka消息，该消息稍后将由实际应用程序处理。
一开始我觉得这种方法很奇怪。Kafka是系统间的交流。但是，进一步拆分应用程序以提高有限上下文的恢复能力是否有好处？我想不是我想的。因为通过使用现代技术，应用程序可以非常有弹性。因此，我们可以只创建一个应用程序，而不是增加更多的复杂性。
后来我了解到这种方法是一种类似cqrs的方法。通过创建一个接收写操作的应用程序，它将与读操作完全分离。在这种情况下，Kafka将被用作一个事件系统。它也许不应该删除旧的消息，但是，我想知道这是否是一个好的方式去做，如果我得到的东西是正确的。
您如何看待kafka的需求和使用，以获得一个高可用性和弹性的应用程序？
1条答案
按热度按时间2w3rbyxf1#
这里的关键问题是
现代应用程序具有弹性
虽然从理论上讲这听起来可能是正确的，但仍有相当多的现代应用程序由于设计不当、负载过大等多种因素而惨遭失败
如果你的应用程序没有宕机部署，mtbf（平均无故障时间）接近于0，那么你的应用程序是有弹性的，你不需要寻找Kafka
Kafka的复杂性
如果由于某种原因，你无法实现零停机时间或mtbf接近零，Kafka是一个强大的选择给你。原因很简单，你可以配置kafka侦听器重试，所以如果你的应用程序关闭了一段时间，消息仍然可以在服务重新启动后处理。此外，您还可以使用强大的kafka流功能，如事务处理
但请注意，kafka只提供了分区内消息的总顺序，而不是主题中不同分区之间的顺序。
如果主题是单分区的，那么顺序是有保证的。如果你的消费者表现良好，你不必担心。
另外，由于消息处理将是异步的，您将无法保证消息何时被处理，因此，如果您的应用程序是一个面向某个应用程序的客户端，或者客户端正在等待响应，这将带来更大的复杂性
您可以评估akka框架是否为您的应用程序增加了更多的价值，因为您将获得以下特性
事件驱动：通过使用actor，可以编写异步处理请求的代码，并且只使用非阻塞操作。
可伸缩性：在akka中，由于消息传递和位置透明性，无需修改代码就可以添加节点。
弹性：任何应用程序都会遇到错误并在某个时间点失败。akka提供了“监督”（容错）策略来促进自我修复系统。
响应性：当今许多高性能和快速响应的应用程序需要向用户提供快速反馈，因此需要以极其及时的方式对事件做出React。akka的非阻塞、基于消息的策略有助于实现这一点。