微服务应该可重用吗？

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

这完全取决于您要构建的微服务。对于前;说您正在建立电子邮件通知服务。可以由不同的应用程序重用。另一个示例说您正在构建推荐系统。它对于单个应用程序非常特定。以可以在不同应用程序中重用的方式设计它几乎没有道理。

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