使用 Kafka 提高新服务的弹性
Use Kafka to increase resilience of a new service
我正在从事一个开始创建独立可部署服务的项目。我们正在创建的服务应该具有弹性，具有 24/7 的正常运行时间。
一些开发者已经创建了关于使用什么技术的概念。为确保服务始终可用，应使用 Kafka。例如，应该有一个简单的 application/serverless 函数来向项目集合添加一些内容。薄层应该创建一个 Kafka 消息，稍后将由实际应用程序处理。
起初我觉得这种方法很奇怪。 Kafka 是系统之间通信的东西。但是，将应用程序进一步拆分以提高限界上下文的弹性是否好？我想不是我想的。因为通过使用现代技术，应用程序可以非常有弹性。因此我们可以只创建一个应用程序而不是增加更多的复杂性。
后来才明白这个方法是类CQRS的方法。通过创建接收写入的应用程序，它将与读取完全分开。在这种情况下，Kafka 将用作事件系统。它可能不应该删除旧消息，但是，我想了解这是否是一个好方法，我是否做对了。
您如何看待 Kafka 获得高可用性和弹性应用程序的要求和用法？
这里的关键问题是
现代应用程序具有弹性
虽然理论上这听起来可能是正确的，但仍有相当多的现代应用程序由于设计不佳、负载过大等多种因素而惨遭失败
如果您的应用有 zero-downtime 部署并且 MTBF（平均无故障时间）接近于 0，那么您的应用是有弹性的，您不需要寻找 Kafka
Kafka 复杂度
如果对于 some-reason 你无法实现 zero-down 时间或 MTBF 接近于零，Kafka 是一个强大的选择。原因很简单，你可以配置 Kafka 监听器重试，所以如果你的应用程序关闭了一段时间，服务重启后仍然可以处理消息。此外，您将能够使用强大的 Kafka 流处理功能，例如事务处理
但请注意，Kafka 仅提供分区内消息的总顺序，而不是主题中不同分区之间的消息。
如果您的主题只有一个分区，则可以保证顺序。如果您的消费者表现良好，您不必担心。
此外，由于消息处理将是异步的，您无法保证消息何时会被处理，因此如果您的应用程序是一个面向客户端的应用程序或客户端正在等待响应，这将带来更多的复杂性
您可以评估 Akka 框架是否增加了更多价值，因为您将获得以下功能 out-of-the-box
- Event-driven: 使用 Actors，可以编写异步处理请求并专门使用 non-blocking 操作的代码。
- 可扩展性：在 Akka 中，无需修改代码即可添加节点，这要归功于消息传递和位置透明性。
- 弹性：任何应用程序都会遇到错误并在某个时间点失败。 Akka 提供“监督”（容错）策略来促进 self-healing 系统。
- 响应：当今许多高性能和快速响应的应用程序需要向用户提供快速反馈，因此需要以极其及时的方式对事件做出反应。 Akka 的 non-blocking、message-based 策略有助于实现这一目标。
我正在从事一个开始创建独立可部署服务的项目。我们正在创建的服务应该具有弹性，具有 24/7 的正常运行时间。
一些开发者已经创建了关于使用什么技术的概念。为确保服务始终可用，应使用 Kafka。例如，应该有一个简单的 application/serverless 函数来向项目集合添加一些内容。薄层应该创建一个 Kafka 消息，稍后将由实际应用程序处理。
起初我觉得这种方法很奇怪。 Kafka 是系统之间通信的东西。但是，将应用程序进一步拆分以提高限界上下文的弹性是否好？我想不是我想的。因为通过使用现代技术，应用程序可以非常有弹性。因此我们可以只创建一个应用程序而不是增加更多的复杂性。
后来才明白这个方法是类CQRS的方法。通过创建接收写入的应用程序，它将与读取完全分开。在这种情况下，Kafka 将用作事件系统。它可能不应该删除旧消息，但是，我想了解这是否是一个好方法，我是否做对了。
您如何看待 Kafka 获得高可用性和弹性应用程序的要求和用法？
这里的关键问题是
现代应用程序具有弹性
虽然理论上这听起来可能是正确的，但仍有相当多的现代应用程序由于设计不佳、负载过大等多种因素而惨遭失败
如果您的应用有 zero-downtime 部署并且 MTBF（平均无故障时间）接近于 0，那么您的应用是有弹性的，您不需要寻找 Kafka
Kafka 复杂度
如果对于 some-reason 你无法实现 zero-down 时间或 MTBF 接近于零，Kafka 是一个强大的选择。原因很简单，你可以配置 Kafka 监听器重试，所以如果你的应用程序关闭了一段时间，服务重启后仍然可以处理消息。此外，您将能够使用强大的 Kafka 流处理功能，例如事务处理
但请注意，Kafka 仅提供分区内消息的总顺序，而不是主题中不同分区之间的消息。
如果您的主题只有一个分区，则可以保证顺序。如果您的消费者表现良好，您不必担心。
此外，由于消息处理将是异步的，您无法保证消息何时会被处理，因此如果您的应用程序是一个面向客户端的应用程序或客户端正在等待响应，这将带来更多的复杂性
您可以评估 Akka 框架是否增加了更多价值，因为您将获得以下功能 out-of-the-box
- Event-driven: 使用 Actors，可以编写异步处理请求并专门使用 non-blocking 操作的代码。
- 可扩展性：在 Akka 中，无需修改代码即可添加节点，这要归功于消息传递和位置透明性。
- 弹性：任何应用程序都会遇到错误并在某个时间点失败。 Akka 提供“监督”（容错）策略来促进 self-healing 系统。
- 响应：当今许多高性能和快速响应的应用程序需要向用户提供快速反馈，因此需要以极其及时的方式对事件做出反应。 Akka 的 non-blocking、message-based 策略有助于实现这一目标。