微服务架构中的包装服务/API 有多常见？从我个人的经验来看，感觉这是一种反模式，但也许我遗漏了一些细节？
我正在致力于将紧密耦合的架构拆分为微服务设置。因此，如果需要，每个服务都将拥有自己的数据库，否则完全无状态。
客户端使用一些拥有自己服务的第三方集成，因为它们都提供类似但格式不同的响应。客户坚持在所有集成之上构建一个包装器服务，该服务将负责调用所述集成（如代理服务）并将响应映射到通用模型。
我也许可以看到一致响应的附加价值是什么（尽管它可以以不同的方式实现），但我很难找到支持包装器想法的专业论据。
此外，这些集成不需要始终存在 - 一个客户可以决定他们愿意为多少集成以及哪些集成付费。
提前致谢！
唯一严重的原因（例如，其他原因是因为程序员认为它很酷，或者一直在互联网上阅读博客）是如果您认为 API 应该与提供相同服务的另一个 API 可以互换，并且您会想要满足为了那个原因。例如，如果您有 Google 搜索集成，并且您认为您可能想在某个时候将其替换为 Bing。
否则你只是在为自己工作，YAGNI 风格。您可能认为您需要一个通用接口，以便客户端可以使用相同的代码调用任何服务，但您所做的只是将调用服务的工作转移到代理 - 实际上并没有为自己保存任何内容，只是将其移到其他地方。
所以YMMV取决于您的情况，但问问自己这会带来什么商业利益。