微服务应该可重用吗？

Question

微服务应该可重用吗？ 对于可重用，我并不是说共享特定领域的模型。

我的意思是为一个应用程序创建的微服务是否可以在另一个应用程序中重用？ 如果它们可以在应用程序中重用就足够了吗？

解耦微服务的最佳方式是什么。 从我的角度来看，一旦微服务调用另一个微服务，它就会紧密耦合，这意味着它不能轻易（未经修改）被提取并放入另一个没有它引用/来自相同服务的微服务应用程序中。

为了将它们解耦，我认为有以下几种方式：

1. 微服务 A 需要使用
   标准 合同与其他微服务 B 通信，例如。一个特定的协议。
2. 另一个微服务 C 充当网关，向微服务 B 请求数据并将其作为输入传递给微服务 A。

nr 的具体示例。 2 将是：

耦合：

客户端 -> API Gateway -> UserProfileService -> 授权服务

解耦：

客户端 -> API 网关 -> 授权服务 -> API 网关 -> UserProfileService

我是否正确假设这一切都归结为微服务的目标？没有对错之分？

我还缺少其他解耦微服务的策略吗？

Answer 1

我认为您可能得到的回复比答案更能代表意见，但我会继续提供我的！

微服务的文献早就说过，“解耦、解耦、解耦”，但坦率地说，我不认为这是现实。当有人创建了一个有用的 API 来支持您自己的功能（身份验证、支付和显然数据库浮现在脑海中）时，建议这些需要与您的功能一起运行是错误的吗？大多数人不会通过复杂的、充满逻辑的网关来通过 Stripe 进行支付或通过 Twilio 发送短信，那么为什么私有托管的 API 会有所不同呢？

将自己的服务设计为可重用、易于使用/可部署的组件非常棒。这不应该意味着它不能有依赖关系，而是我们应该注意那些依赖关系引入的膨胀。开发人员在引入依赖项时应该练习这种正念，无论它们是应用程序包还是依赖服务/API。

**披露：我构建并运行了一个框架/平台Architect.io，以帮助云原生团队协作并在彼此的服务基础上构建。我亲眼目睹了像 Facebook 这样的公司如何使用类似的策略来实现服务的重用和消费，并希望为公众构建一个微服务依赖解析器。

Answer 2

这完全取决于您要构建的微服务。例如；假设您正在构建电子邮件通知服务。这可以被不同的应用程序重用。另一个例子说你正在构建一个推荐系统。它对于单个应用程序非常具体。以可以在不同应用程序中重用的方式设计它几乎没有意义。

根据上下文选择。没有正确的方法。这完全取决于应用程序。