当我使用 Dropwizard 开发微服务时，我试图在一个正在运行的 Dropwizard 实例/应用程序上拥有许多资源与许多实例之间找到平衡。
例如 - 我有一个项目 A 有 3 个资源。在另一个项目-B 中，我想使用项目-A 中的一个资源。公共资源与用户数据有关。现在我有这样的选择：
我想获得专家意见的另一点是如何平衡/最小化与不同微服务实例之间的通信相关的网络调用。一般来说，应该使用http在不同实例之间进行通信吗？或者任何其他进程间通信方法可以用于性能本身[特别是如果不同的实例在同一系统上]？
我觉得这对于微服务领域的新手来说可能是常见的问题/困惑。因此想知道任何一般准则或最佳实践。
非常感谢
普拉迪普
微服务的主要优势之一是有机会分别发布和部署它们。无论您选择什么选项，请确保您不会丢失此属性。微服务的另一个属性应该是它只有一个职责。因此，一切都是为了为您的服务找到正确的边界（在 DDD 术语中是“有界上下文”），实际上找到正确的边界并不容易。这是一种平衡行为。例如在您的理论案例中：如果 A 和 C 之间的通信非常健谈，那么提取 C 不是一个好主意。如果 A 和 C 具有不同的生命周期（业务方面），那么这是一个好主意提取 C.
从项目-B 对项目-A 中的用户资源进行 http 调用。我可以在这里使用 dropwizard 的客户端方法
如果我是你，我不会追求这个选择。它会不必要地减慢您的服务，造成潜在的日志记录问题，并且感觉不对。唯一有意义的情况是代码超出您的控制范围（但即便如此，也可能有更好的解决方案）。
由于用户资源很常见 - 我可以将它从项目 A 中取出来说项目 C。我需要在项目 A 和项目 B 中创建客户端代码
我可以提取包含用户代码的 jar 并在项目 B 中使用。这将避免进行 http 调用。
听起来项目 A 和项目 B 在逻辑上是不同的单元，具有一些共同的依赖关系。考虑一个多模块项目（如果您使用 Maven，则考虑一个多模块 Maven 项目）可能是有意义的。您可以拥有一个包含任何公共代码（和资源）的模块，这些代码被单独的项目模块引用。这是 Maven 真正擅长的地方，因为它可以为您管理所有这些依赖项。这就像您列出的最后两个选项的组合。
这本质上是一种设计选择：您是否准备好将每个小型服务的简单性与必须编排它们的复杂性以及整体延迟的结果进行权衡。
如果您选择小型服务方法，您可以遵循http://dropwizard.io/manual/core.html#organizing-your-project上的文档指南： 1 个项目，其中包含 3 个 api 模块（可供消费者参考） )、应用程序和可选客户端（也可能在消费者中使用）
您必须回答的其他问题： - 您的每项服务都将托管在单独的 SCM 存储库中......或不 - 您的每项服务都可以（应该？）拥有自己的版本
如果您觉得用户是有界上下文，就像用户注册、身份验证等用户管理一样。这当然可以是一个单独的微服务。但是，您应该从单个 API 网关调用用户 API，并将其转换为 JWT 令牌并将其传递给标头中的其他 API。
在另一种情况下，如果您的业务用例需要调用多个微服务，则应在复合服务层中开发逻辑（编排）。
关于微服务间的通信——通过 API 调用相互交谈将带您回到“点对点”通信，这为大型项目引入了很多复杂性且难以管理。
根据有界上下文理论，任何事务都不应超出一个微服务。然而，在现实世界的场景中，我认为我们至少对参考数据的验证仍然有依赖性。示例订单服务需要验证产品 ID。在这种情况下，我能想到的最好办法是在微服务之间进行事件处理，以相互提供参考数据。您可以尝试使用事件溯源来生成业务事件，并尝试使用异步 io 进行发布/订阅。
谢谢，阿米特