microservices - 微服务应该是可重用的吗？

Question

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

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

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

要解耦，我认为有以下几种方式:

1. 微服务 A 需要与另一个微服务 B 对话
   标准契约(Contract)，例如。一个特定的协议(protocol)。
2. 另一个微服务 C 充当网关，向微服务 B 请求数据并将其作为输入传递给微服务 A。

nr 的一个具体例子。 2 将是:

耦合:

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

解耦:

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

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

我是否缺少任何其他解耦微服务的策略？

Answer 1

我认为您可能得到的答复代表的是意见而不是答案，但我会继续说出我的看法!

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

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

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