是否可以使用 oData.net 实现微服务

Question

我一直在阅读有关Microservice Architecure 的信息，并且由于互联网上提供的有价值信息有限，我相信，我从理论的角度对它有一个公平的理解。我知道，在较高级别上，该架构建议远离monoliths，并拥有小型独立服务。但是，我在互联网上看到的所有示例都建议编写连接到ESB 的松散耦合的 Windows 服务（非 MS 实现的守护程序）。我知道编写遵循 SRP 的小型、松散耦合的 Web 服务也符合微服务的要求。

也就是说，oData.Net 服务，其中所有 oData 控制器（微服务？）都部署为一个整体，显然违反了微服务架构模式。说 oData.net 不是为微服务而设计的，这是正确的说法吗？如果您的回答是否定的，请借助示例进行解释。另外，请帮助我了解如何混合使用 API 网关模式。

Answer 1

ODATA 确实适合微服务。但是，微服务并不适合 odata。我的意思是，实际上没有什么可以阻止您在微服务中公开 OData。

但是，这样做通常会在微服务中公开大量内部数据结构。这反过来又会增加不同服务之间的耦合。这样一来，由于依赖关系，您会更难更改服务。

我个人的经验法则是从每个服务中公开尽可能小的 API。而且我公开的数据结构与内部的不同。它们可能是扁平化的，或者是不同内部实体中数据之间的联合。

我的理由是：如果您要创建单独的服务，请尽量将它们分开。否则，您只是在构建一个恰好在几个不同的 Windows 服务中运行的单体。

Answer 2

oData 作为一种暴露微服务的方法是完全有效的；然而，公开一个显式表不是微服务。所以我不完全同意jgauffin。没有理由无法使用 oData 提供 API。我确实同意 JGauffin 的一点是，API 应该有一个小的平面足迹，它与源或目标的详细数据结构分离。因此由调用它的服务来转换 API，但这意味着只要有业务需要，API 的通用格式就可以重用，并根据需要切换技术平台。