.NET Core ❤ gRPC
千呼万唤的 .NET Core 3.0 终于在 9 月份正式发布，在它的众多新特性中，除了性能得到了大大提高，比较受关注的应该是 ASP.NET Core 3.0 对 gRPC 的集成了。它的源码托管在 grpc-dotnet 这个 Github 库中，由微软 .NET 团队与谷歌 gRPC 团队共同维护.
.NET Core 对 gRPC 的支持在 grpc 官方仓库早已有实现（grpc/csharp），但服务端没有很好地与 ASP.NET Core 集成，使用起来还需要自己进行一些集成扩展。而 ASP.NET Core 3.0 新增了 gRPC 服务的托管功能，能让 gRPC 与 ASP.NET Core 框架本身的特性很好地结合，如日志、依赖注入、身份认证和授权，并由 Kestrel 服务器提供 HTTP/2 链接，性能上得到充分保障。
推荐把项目中已有的 RPC 框架或者内部服务间 REST 调用都迁移到 gRPC 上，因为它已经是云原生应用的标准 RPC 框架，在整个 CNCF 主导下的云原生应用开发生态里 gRpc 有着举足轻重的地位。
对于 gRPC 的使用方式，前段时间已经有其他大神写的几篇文章了，这里就不再赘述了。本文主要介绍的是区别于标准使用规范的，但对.NET 应用更加友好的使用方式，最后会提供源码来展示。
作为对比，还是要列一下标准的使用步骤：
定义 proto 文件，包含服务、方法、消息对象的定义
引入
Grpc.ToolsNuget 包并添加指定 proto 路径和生成模式生成项目，得到服务端的抽象类或客户端的调用客户端组件
实现服务端抽象类，并在 ASP.NET Core 注册这个服务的路由端点
DI 注册 gRPC 服务。
客户端用
Grpc.Net.ClientFactoryNuget 包进行统一配置和依赖注入
.NET Core 对 gRPC 的大力支持使开发者开发效率大大提高，入门难度也减少了许多，完全可以成为跟 WebApi 等一样的 .NET Core 技术栈的标配。
proto 在单一语言系统架构中的局限性
使用 proto 文件的好处是多语言支持，同一份 proto 可以生成各种语言的服务和客户端，可以让用不同语言开发的微服务直接互相远程调用。但 proto 文件作为不同服务间的契约，不可以经常修改，否则就会对使用了它的服务造成不同程度的影响，因此对 proto 文件的版本控制需要得到重视。
另外，我们的应用程序还不应该与 gRPC 耦合，否则就会导致系统架构被这些实现细节所绑架。直接依赖 proto 文件和由它生成的代码，就是对 gRPC 的强耦合。
例如，当应用程序在演进的过程中，复杂度还未达到完全部署隔离的必要时，为了避免因“完全边界”引入的部署运维复杂性，又能预留隔离的可能性，需要有一层接口层作为“不完全边界”。
又比如，目前在 windows 系统的 iis 上还不支持 grpc-dotnet，当有 windows 上的应用程序需要使用 RPC，就需要换成 REST 的实现了。
因此，为了不让应用程序对 gRPC 过于依赖，还应该使用一层抽象（接口）层与其解耦，用接口来隔离对 RPC 实现的依赖，这样在需要使用不同的实现时，可以通过注册不同的实现来方便地切换。
在这些场景下，本文要介绍的 Code-First gRPC 使用方法就发挥作用了。
Code-First gRPC
说了这么久，我好像还没正式介绍 Code-First gRPC，到底他有多适合在单一语言系统架构中实现 gRPC 呢？下面要介绍的就是基于大名鼎鼎的 protobuf-net 实现的 gRPC 框架，protobuf-net.Grpc。
protobuf-net 是在过去十几年前到现在一直在 .NET 中有名的 Protobuf 库，想用 Protobuf 序列化时就会用到这个库。他的特性就是可以把 C# 代码编写的类能以 Protobuf 的协议进行序列化和反序列化，而不是 proto 文件再生成这些类。而 protobuf-net.Grpc 则是一脉相承，可以把 C# 写的接口，在服务端方便地把接口的实现类注册成 ASP.NET Core 的 gRPC 服务，在客户端把接口动态代理实现为调用客户端，调用前面的这个服务端。
用法很简单，只要声明一个接口为您的服务契约：
[ServiceContract]
public interface IMyAmazingService {
ValueTask<SearchResponse> SearchAsync(SearchRequest request);
// ...
}
然后实现该接口的服务端：
public class MyServer : IMyAmazingService {
// ...
}
或者向系统获取客户端：
var client = http.CreateGrpcService<IMyAmazingService>();
var results = await client.SearchAsync(request);
这相当于以下 .proto 中的服务：
service MyAmazingService {
rpc Search (SearchRequest) returns (SearchResponse) {}
// ...
}
protobuf-net.Grpc 同样通过普通类型定义支持 gRPC 的四种模式，把 C# 8.0 中最新的 IAsyncEnumerable 类型识别成 proto 中的 stream，单向流、双向流都可以实现！而且用 IAsyncEnumerable 实现可比 proto 生成的类方便很多。
例如 proto 双向流定义：
rpc chat(stream ChatRequest) returns ( stream ChatResponse);
生成出来的方法是：
Task BathTheCat(IAsyncStreamReader<ChatRequest> requestStream, IServerStreamWriter<ChatResponse> responseStream)
而 protobuf-net.Grpc 只要定义一个方法：
IAsyncEnumerable<ChatResponse> SubscribeAsync(IAsyncEnumerable<ChatRequest> requestStream);
总结
由此可见，protobuf-net.Grpc 无需在契约层引入第三方库，充分运用了 C# 类型系统，把方法、类型映射到兼容了 gRPC 的服务定义上。
上文所说的 proto 局限也迎刃而解了，函数调用、gRPC、REST 都能方便切换。（REST 实现可以参考我的开源框架 shriek-fx 中的 Shriek.ServiceProxy.Http ）组件。
下一篇，我将主要介绍利用 protobuf-net.Grpc 的 gRPC 双向流模式与 Blazor 实现一个简单的在线即时聊天室。
相关链接：
protobuf-net.Grpc：https://github.com/protobuf-net/protobuf-net.Grpc
shriek-fx：https://github.com/Shriek-Projects/shriek-fx
GrpcChat: https://github.com/ElderJames/GrpcChat
