微服务良好实践 .NET

Posted 2023-03-15

【中文标题】微服务良好实践 .NET

【英文标题】：Microservice good practice .NET

【发布时间】：2020-08-17 21:46:39

【问题描述】：

我是“微服务世界”的新手，我有一些问题。 据我了解，微服务是一组具有不同数据层的小型独立部件，它们创建了一个逻辑整体（例如 - 商店有订单、仓库等）。 我的工具是 .NET。 问题：

我的微服务项目能否同时包含 Web API 和 Web 服务？这符合微服务架构的原则吗？ 如果答案是肯定的，将 Web api 放在一个解决方案中，将 Web 服务放在另一个解决方案中更好，还是可以放在一个解决方案中但在单独的项目中 (Visual Studio)？ API 网关也有同样的问题，API 网关有单独的解决方案更好吗？

谢谢！

【参考方案1】：

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

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

2) Web 服务只支持 HTTP 协议，而 API 支持 HTTP/HTTPS 协议。

3) Web 服务支持 XML，而 API 支持 XML 和 JSON，因此 API 与 Web 服务相比是轻量级的。

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

【参考方案2】：

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

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

无论您如何组织项目，请确保您的服务保持松散耦合。这通常是新微服务项目中最大的错误。服务没有正确解耦，项目最终增加了复杂性而没有获得好处（或更糟）。如果您不确定如何执行此操作，请确保您已正确研究过松散耦合的含义。

最后，REST 更多的是关于您选择如何公开您的微服务，而不是关于微服务架构。 REST 不一定是公开微服务的最佳方法，您可能会考虑其他方法，包括消息模式和消息代理。