Dropwizard：处理多个dropwizard实例

Question

在使用Dropwizard开发微服务时，我试图在一个正在运行的Dropwizard实例/应用程序上与许多实例上拥有许多资源之间寻求平衡。

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

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

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

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

非常感谢

普拉迪普

Answer 1

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

如果我是你，我不会追求这个选择。 它将不必要地减慢您的服务速度，造成潜在的日志记录头痛，并且感觉不对。 只有在代码不受您的控制时，这才有意义（但是即使那样，也可能有更好的解决方案）。

因为用户资源很常见-我可以从项目A中取出它来说项目C。 我需要在项目A和项目B中都创建客户端代码

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

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

Answer 2

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

Answer 3

从本质上讲，这是一种设计选择：您是否准备好将每个小型服务的简单性与必须协调它们的复杂性以及整体延迟的结果进行权衡。

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

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

Answer 4

如果您感到的用户是受限的上下文，就好像用户管理（例如用户注册，身份验证等）一样。这肯定可以是单独的微服务。 但是，您应该从单个API网关调用用户API，并将其转换为JWT令牌，然后将其传递到标头中的其他API。

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

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

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

谢谢阿米特