Dropwizard：处理多个 dropwizard 实例答案

【问题标题】：Dropwizard: handling multiple dropwizard instancesDropwizard：处理多个 dropwizard 实例
【发布时间】：2014-05-14 19:23:58
【问题描述】：

当我使用 Dropwizard 开发微服务时，我试图在一个正在运行的 Dropwizard 实例/应用程序与多个实例之间找到一个平衡点。

例如 - 我有一个项目-A 有 3 个资源。在另一个项目-B 中，我想使用项目-A 中的一个资源。公共资源与用户数据有关。现在我有这样的选择：

从项目-B 对项目-A 中的用户资源进行http 调用。我可以在这里使用 dropwizard 的客户端方法
因为用户资源很常见 - 我可以将它从项目 A 中取出来表示项目 C。我需要在项目 A 和项目 B 中创建客户端代码
我可以提取包含用户代码的 jar 并在项目 B 中使用。这样可以避免进行 http 调用。

我想获得专家意见的另一点是如何平衡/最小化与不同微服务实例之间的通信相关的网络调用。通常应该使用http在不同实例之间进行通信吗？还是可以使用任何其他进程间通信方法来提高性能[特别是如果不同的实例位于同一系统上]？

我觉得这对于微服务领域的新手来说可能是常见的问题/困惑。因此想知道任何一般准则或最佳实践。

非常感谢

普雷迪普

【问题讨论】：

标签： java dropwizard horizontal-scaling

【解决方案1】：

从项目-B 对项目-A 中的用户资源进行http 调用。我可以在这里使用 dropwizard 的客户端方法

如果我是你，我不会选择这个选项。它会不必要地减慢您的服务，造成潜在的日志记录问题，并且感觉不对。唯一可能有意义的情况是代码超出您的控制范围（但即便如此，也可能有更好的解决方案）。

由于用户资源很常见 - 我可以将其从项目 A 中取出来表示项目 C。我需要在项目 A 和项目 B 中创建客户端代码

我可以提取包含用户代码的 jar 并在项目-B 中使用。这样可以避免进行 http 调用。

听起来项目 A 和项目 B 在逻辑上是不同的单元，具有一些共同的依赖关系。考虑一个多模块项目（如果您使用 Maven，则考虑一个多模块 Maven 项目）可能是有意义的。您可以拥有一个包含任何公共代码（和资源）的模块，这些代码被单独的项目模块引用。这是 Maven 真正擅长的地方，因为它可以为您管理所有这些依赖项。这就像您列出的最后两个选项的组合。

【讨论】：

目前我也倾向于多模块项目。

【解决方案2】：

微服务的主要优势之一是有机会分别发布和部署它们。无论您选择什么选项，请确保您不会丢失此属性。微服务的另一个属性应该是它只有一个职责。因此，一切都是为了为您的服务找到正确的边界（在 DDD 术语中是“有界上下文”），实际上找到正确的边界并不容易。这是一种平衡行为。例如在您的理论案例中：如果 A 和 C 之间的交流会很健谈，那么提取 C 并不是一个好主意。如果 A 和 C 具有不同的生命周期（业务方面），那么提取 C 是一个好主意。

【讨论】：

【解决方案3】：

这本质上是一种设计选择：您是否准备好在每个小服务的简单性与必须编排它们的复杂性和整体延迟的结果之间进行权衡。

如果您选择小型服务方法，您可以遵循http://dropwizard.io/manual/core.html#organizing-your-project 的文档指南：1 个项目，包含 3 个模块，用于 api（可以从消费者那里引用）、应用程序和可选客户端（也可能用于消费者）

您必须回答的其他问题： - 您的每项服务都将托管在单独的 SCM 存储库中......或者不 - 您的每项服务都可以（应该？）拥有自己的版本

【讨论】：

【解决方案4】：

如果你觉得用户是有界上下文的，就像用户注册、身份验证等用户管理一样。这当然可以是一个单独的微服务。但是，您应该从单个 API 网关调用用户 API，并将其转换为 JWT 令牌并在标头中将其传递给您的其他 API。

在另一种情况下，如果您的业务用例需要调用多个微服务，则应在复合服务层中开发逻辑（编排）。

关于微服务之间的通信 - 通过 API 调用相互交谈会带您回到“点对点”通信，这对于大型项目来说会带来很多复杂性和难以管理的问题。

根据有界上下文理论，任何事务都不应超出一个微服务。然而，在现实世界的场景中，我认为我们至少对参考数据的验证仍然有依赖性。示例订单服务需要验证产品 ID。在这种情况下，我能想到的最好办法是在微服务之间进行事件处理，以相互提供参考数据。您可以尝试使用事件源来生成业务事件，并尝试使用异步 io 进行发布/订阅。

谢谢，阿米特

【讨论】：