单个数据摄取服务与多个单独的微服务？ [关闭]

Posted 2023-03-28

【中文标题】单个数据摄取服务与多个单独的微服务？ [关闭]

【英文标题】：Single data ingestion service vs multiple individual microservices? [closed]

【发布时间】：2021-09-15 18:14:32

【问题描述】：

我试图了解单个数据摄取微服务与每个数据源的多个单独微服务的优缺点。

上下文： 从客户第一次注册到我的平台时，我需要获取多个数据源来检索客户数据；但是，每个来源，例如 Strava、Garmin、Endomondo（健身数据来源）都有不同的数据提取方法，其中一些方法比其他方法更复杂。

单一数据摄取的优点：

会出现更少的微服务，因此可能会减少集成问题 花在开发上的时间更少 “更少”的团队需要负责，因为只有一项服务（如果我们遵循每个服务一个团队的规则）

单一数据摄取的缺点：

很难查明服务中的故障 所有数据源的可用性可能会受到影响，因为从技术上讲存在单点故障 随着未来出现更多来源，代码库变成了一个小型单体

当前决定 从利弊来看，从事实来看，为每个来源提供单独的服务似乎是一个更好的选择。如果我要继续，我正在考虑使用：

API 网关模式，用于封装各个微服务。 共享数据库模式用于存储身份验证令牌，例如 异步消息传递模式将从源检索到的数据发送到最终目的地

我期待听到我是否遗漏了收养论点的任何利弊或一些反对点！

【参考方案1】：

首先，我不得不说，在我看来，你选择了正确的选项，而且这个选项最大的好处是你没有耦合不同的来源，因此，不同提供商的 API 可以更改或其中一些消失，或者如您之前所说，出现更多来源，而您的其余来源根本不会受到影响。没有源代码更改，也没有更新的版本来解决这个问题。 并且使用异步消息传递模式可以保证您的最终目的地不会与您的源耦合。

我不完全同意的唯一一点是共享数据库模式，用于在每个提供者中进行身份验证的令牌是否相同？在这种情况下，无论如何，如果需要在服务之间持久化和共享的唯一数据是令牌，我将使用比关系数据库更快的分布式缓存（如 redis）

【讨论】：

不，它们不一样，但我可以在单个数据库中使用不同的表来处理不同的提供者，对吧？

是的，你可以，但在微服务之间共享数据库（模式）不应该是一个好习惯，因为这样做是通过数据库耦合微服务。例如，如果您因为一项服务需要而更改任何表或关系等，则您必须修改和部署其他微服务以适应更改

有道理，您是否倾向于将共享数据库用于微服务？

不，我不知道任何一般情况，但也许正如我在回答中所说，您必须在服务之间共享一些信息，例如授权令牌