我正在创建一个需要从Kafka代理中消费数据(更新客户端事务)的应用程序(web应用程序)，但我不确定解决这个问题的最佳方法是什么
我可以想到三种不同的场景来处理每个更新:
-
直接在我的应用程序中安装Kafka消费者，然后我可以启动它的另一个实例(我使用docker，所以另一个容器)并在那里进行所需的更新(我认为这是最快的一个)。
-
创建一个单独的服务，从Kafka中消费，并在应用程序数据库中进行所需的更新。它似乎与选项1几乎相同，但更小的应用程序和更多的维护(2个应用程序而不是1个)。
-
创建一个单独的服务，从Kafka消费并将更新发送到我的应用程序中的REST端点。这似乎是一个很小的服务，非常具体，过程仍然在应用程序中;但是应用程序会收到更多的请求。
那么，每种解决方案的优缺点是什么呢?它们都是有效的吗?还是有些是完全无效的?我应该注意哪些缺点/风险?
我不只是在寻找一个建议，我更感兴趣的是了解哪种解决方案最适合给定的场景。
谢谢。
使用3，您将应用程序拆分为多个服务。当您跨多个服务分发代码时，您增加了间接性的级别。代码库中的间接代码越多，一个人在整个代码库中工作就越困难，因为他们必须在脑子里记住更多的东西，跨网络边界工作比跨文件工作需要更多的代码，最后，跨网络API的调试也更困难。
现在，这并不意味着将应用程序拆分为多个服务是不好的。这样做将有助于扩展应用程序，因为您可以只扩展需要扩展的部分。也许更重要的是，将你的应用程序拆分为多个服务可以让更多的人更容易同时处理代码库，因为他们必须遵守服务之间的API契约，并且不太可能同时处理相同的文件。
所以3是一个很好的选择，如果你有扩展问题，要么是你的应用程序的负载，要么是开发人员的数量。
1是一个很好的选择，如果你想要尽可能快地移动，并且可以推迟一段时间的缩放问题。
2是两个世界中最糟糕的。您的两个服务将通过数据库模式耦合，并将共享相同的数据库实例。代码的分离意味着你有额外的间断性，数据库模式的耦合意味着你不能完全获得人员扩展的好处，而且由于大多数应用程序都受到数据库的瓶颈，数据库实例的共享将剥夺你独立扩展的性能。
个人经验-
如果你有REST API代码的控制权，那么第一个。
如果API在到达数据库之前有特定的验证，除非你计划将该代码复制到消费者中，否则不要执行第二个验证。如果你想直接写入数据库，那么Kafka Connect是建议的框架，而不是一个普通的消费者，无论如何
如果你不能控制API代码(它是一个第三方API)，那么你只能选择3