Apache kafka 卡夫卡消费者的最佳架构

我正在创建一个应用程序（web应用程序），该应用程序需要使用来自Kafka代理的数据（更新客户端事务），但我不确定最好的方法是什么

我可以想出三种不同的方案来处理每次更新：

直接在我的应用程序中安装Kafka consumer，然后我可以启动它的另一个实例（我使用docker，所以是另一个容器），并在那里进行所需的更新（我认为这是最快的一个）

创建使用Kafka的单独服务，并在应用程序数据库中进行所需更新。它看起来与选项1几乎相同，但是更小的应用程序和更多的维护（2个应用程序而不是1个）

创建一个使用Kafka的单独服务，并将更新发送到我的应用程序中的REST端点。看起来这将是一个很小的服务，非常具体，流程仍在应用程序中；但该应用程序将收到更多请求

那么，每种解决方案的优缺点是什么？是全部有效还是部分完全无效？我应该注意哪些缺点/风险

我不是在寻找建议，我更感兴趣的是了解哪种解决方案最适合给定场景

---

谢谢。

个人经验法则-

如果您可以控制RESTAPI代码，那么第一个

如果API在到达数据库之前进行了特定的验证，那么不要进行第二次验证，除非您计划将该代码复制到使用者中。如果您想直接写入数据库，那么Kafka Connect是建议的框架，而不是普通的使用者

---

如果您不控制API代码（它是第三方API），那么您只能选择3，即将应用程序拆分为多个服务。当您跨多个服务分发代码时，您会增加间接寻址的级别。代码库中的间接性越多，一个人跨整个代码库工作就越困难，因为他们必须记住更多的东西，跨网络边界工作需要比跨文件工作更多的代码，最后跨网络API调试也就越困难

现在，这并不意味着将应用程序拆分为多个服务是不好的。这样做将帮助您扩展应用程序，因为您只能扩展需要扩展的部分。也许更重要的是，将应用程序拆分为多个服务可以让更多的人更容易同时使用代码库，因为他们必须遵守服务之间的API契约，并且不太可能同时使用相同的文件

因此，如果您存在扩展问题，无论是应用程序的负载还是开发人员的数量，3都是一个不错的选择

1是一个很好的选择，如果您希望尽快移动，并且可以将缩放问题推迟一段时间

---

2是两个世界中最糟糕的。您的两个服务将由数据库模式耦合，并将共享同一个数据库实例。代码分离意味着您有额外的间接性，数据库模式耦合意味着您无法完全获得人员扩展的好处，而且由于大多数应用程序都受到数据库的限制，共享数据库实例将使您无法独立扩展性能。

感谢您的回复！只有一个问题，这个哑巴规则有什么具体的原因吗？按照你的规则，最好的选择似乎是第一个。为什么？就像我说的-你控制API的所有代码。否则，您需要与一些外部供应商商谈添加Kafka Support的问题回答得很好，非常感谢。