微服务良好实践.NET

时间:2020-05-03 14:05:24

标签: .net microservices api-gateway

我是“微服务世界”中的新手,我有一些疑问。
据我了解,微服务是由独立的小部件组成的组,这些部件具有不同的数据层,创建了一个逻辑整体(例如-商店有订单,仓库等)。
我的工具是.NET。
问题:

  1. 我的微服务项目可以同时包含Web API和Web服务吗?微服务架构原则可以吗?
    • 如果答案是肯定的,那么将Web api放在一个解决方案中并将Web服务放在另一个解决方案中还是可以放在一个解决方案中但放在单独的项目(Visual Studio)中更好?
    • 对API网关有同样的问题,对API网关有单独的解决方案更好吗?

谢谢!

2 个答案:

答案 0 :(得分:0)

为什么要同时使用service和api?这是服务和API之间的主要区别。

1)Web服务用于REST,SOAP和XML-RPC进行通信,而API用于任何形式的通信。

2)Web服务仅支持HTTP协议,而API支持HTTP / HTTPS协议。

3)Web服务支持XML,而API支持XML和JSON,因此与Web服务相比,API的重量较轻。

根据微服务架构,您可以对每种服务使用任何技术。唯一的问题是,服务应该能够以JSON或XML相互通信。所有服务应松散耦合并可以独立部署。

答案 1 :(得分:0)

回答您的问题;从微服务架构的角度来看,这并不重要。更重要的是管理您的项目和开发团队。

在某些时候,无论微服务的耦合程度如何,都必须共享某些东西,版本化消息契约就是一个典型的例子。我们在单独的项目中定义消息合同。在一个解决方案中,需要合同的项目可以引用它们。我们还为合同项目创建本地nuget包,以导入其他解决方案。

无论如何组织项目,都要确保服务保持松散耦合。这通常是新的微服务项目中最大的单个错误。服务没有适当地分离,项目最终增加了复杂性,而没有获得收益(或更糟)。如果不确定该怎么做,请确保已正确研究了松散耦合的含义。

最后,REST更多地与您选择如何公开微服务有关,而与微服务体系结构无关。 REST不一定是公开微服务的最佳方法,您可能会研究其他方式,包括消息模式和消息代理。