gRPC与REST

gRPC听起来不错。它在框架下更快，更简单。那么，我们都应该从REST变为gRPC吗？答案是，这取决于你的应用场景。

• 以下是一些注意事项：

  • 从我的印象来看，使用gRPC和ASP.NET仍然不是很好。借助对REST的成熟支持，您会变得更好。就基于契约的通信而言，这很不错，除了在REST中有我们已经讨论过的类似替代方案：Swagger和ReFit。
  • 最大的优势是性能。根据这些基准[17]，在大多数情况下，gRPC更快。特别是对于大型有效载荷，Protobuf序列化确实有所作为。这意味着对于高负载服务器而言，这是一个巨大的优势。
  • 在大型ASP.NET应用程序中从REST过渡到gRPC将非常困难。但是，如果您具有基于微服务的体系结构，那么逐步完成此过渡就变得容易得多。

其他沟通方式

还有其他一些我完全没有提及的通信方式，但是值得一提的是：

• GraphQL[18]是Facebook开发的API的查询语言。它允许客户端从服务器确切地要求它需要的数据。这样，您可以在服务器上仅创建一个端点，该端点将非常灵活，并且仅返回客户端所需的数据。近年来，GraphQL变得非常流行。
• SignalR[19]是一项允许服务器与客户端之间进行实时双向通信的技术。SignalR不仅允许客户端始终向服务器发送请求，还允许服务器向客户端发送推送通知。这样可以查看Web应用程序中的实时更新。SignalR在ASP.NET中非常流行。
• TcpClient[20]和TcpListener[21]（在中System.Net.Sockets）提供基于TCP的低级连接。基本上，您将建立连接并传输字节数组。对于大型应用程序而言，它不是理想的选择，在大型应用程序中，您可以使用ASP.NET的控制器和操作在大型API中进行订购。
• UdpClient[22]提供了一种通过UDP协议进行通信的方法。TCP建立连接，然后发送数据，而UDP仅发送数据。TCP确保数据中没有错误，而UDP没有。UDP可以更有效地快速传输数据，您不必担心它是否可靠且没有错误。一些示例是：视频流，实时广播和IP语音（VoIP）。
• WCF[23]是一种较旧的技术，主要在进程之间使用基于SOAP的通信。这是一个庞大的框架，我要说的是它已不再受REST和JSON负载的欢迎。