是否可以通过oData.net实现微服务

Question

我一直在阅读关于Microservice Architecure以及互联网上有限的有价值信息，我相信我从理论的角度对它有一个公正的理解。据我所知，从高层次上看，这种架构意味着从monoliths转向，并且拥有小型的独立服务。但是，我在互联网上看到的所有示例都建议连接到ESB，以编写松散耦合的Windows服务（在非MS实现的情况下，守护进程）。据我所知，编写符合SRP的小型，松散耦合的Web服务也适合微服务帐单。这就是说，oData.Net服务（所有oData控制器（微服务？）被部署为一个整体）显然违反了微服务架构模式。这是否是正确的声明，使oData.net不是作为微型服务工作的？如果你的答案是否定的，请在一个例子的帮助下解释。另外，请帮助我理解，如何在组合中使用API​​网关模式。

Answer 1

ODATA确实适合微服务。但是，微服务不适合odata。我的意思是，没有什么能够阻止你在微服务中暴露OData。

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

我个人的经验法则是要尽可能从每个服务中公开一个小的API。我公开的数据结构与内部数据结构不一样。它们可能会变平或在不同内部实体中的数据之间进行联合。

我的推理是：如果您要创建单独的服务，请尝试尽可能多地分开它们。否则，你只是建立一个巨石，碰巧运行在几个不同的窗口服务。

Answer 2

oData作为暴露微服务的方法是完全有效的;暴露一个明确的表，但不是微服务。所以我完全不同意jgauffin。没有理由使用oData无法提供API。我同意JGauffin的观点是，API应该有一个与源或目标的详细数据结构分离的小而平面的空间。因此，服务调用它来转换API，但意味着API的通用格式可以重用，只要业务需求在那里，并且技术平台根据需要进行切换。