之前在.NET 性能优化群内交流时,我们发现很多朋友对于高性能网络框架有需求,需要创建自己的消息服务器、游戏服务器或者物联网网关。但是大多数小伙伴只知道 DotNetty,虽然 DotNetty 是一个非常优秀的网络框架,广泛应用于各种网络服务器中,不过因为各种原因它已经不再有新的特性支持和更新,很多小伙伴都在寻找替代品。
这一切都不用担心,在.NET Core 以后的时代,我们有了更快、更强、更好的 Kestrel 网络框架,正如其名,Kestrel 中文翻译为**红隼(hóng sǔn)**封面就是红隼的样子,是一种飞行速度极快的猛禽。Kestrel 是 ASPNET Core 成为.NET 平台性能最强 Web 服务框架的原因之一,但是很多人还觉得 Kestrel 只是用于 ASPNET Core 的网络框架,但是其实它是一个高性能的通用网络框架。
我和拥有多个.NET 千星开源项目作者九哥一拍即合,为了让更多的人了解 Kestrel,计划写一系列的文章来介绍它,九哥已经写了一系列的文章来介绍如何使用Kestrel来创建网络服务,我觉得他写的已经很深入和详细了,于是没有编写的计划。
不过最近发现还是有很多朋友在群里面问这样的问题,还有群友提到如何使用Kestrel来实现一个RPC框架,刚好笔者在前面一段时间研究了一下这个,所以这一篇文章也作为Kestrel的应用篇写给大家,目前来说想分为几篇文章来发布,大体的脉络如下所示,后续看自己的时间和读者们感兴趣的点再调整内容。
本文对应的项目源码已经开源在Github上,由于时间仓促,笔者只花了几天时间设计和实现这个RPC框架,所以里面肯定有一些设计不合理或者存在BUG的地方,还需要大家帮忙查缺补漏。
SatelliteRpc: https://github.com/InCerryGit/SatelliteRpc
如果对您有帮助,欢迎点个star~
再次提醒注意:该项目只作为学习、演示使用,没有经过生产环境的检验。
要求 .NET 7.0 SDK 版本,Visual Studio 和 Rider 对应版本都可以。
├─samples // 示例项目
│ ├─Client // 客户端示例
│ │ └─Rpc // RPC客户端服务
│ └─Server // 服务端示例
│ └─Services // RPC服务端服务
├─src // 源代码
│ ├─SatelliteRpc.Client // 客户端
│ │ ├─Configuration // 客户端配置信息
│ │ ├─Extensions // 针对HostBuilder和ServiceCollection的扩展
│ │ ├─Middleware // 客户端中间件,包含客户端中间件的构造器
│ │ └─Transport // 客户端传输层,包含请求上下文,默认的客户端和Rpc链接的实现
│ ├─SatelliteRpc.Client.SourceGenerator // 客户端代码生成器,用于生成客户端的调用代码
│ ├─SatelliteRpc.Protocol // 协议层,包含协议的定义,协议的序列化和反序列化,协议的转换器
│ │ ├─PayloadConverters // 承载数据的序列化和反序列化,包含ProtoBuf
│ │ └─Protocol // 协议定义,请求、响应、状态和给出的Login.proto
│ ├─SatelliteRpc.Server // 服务端
│ │ ├─Configuration // 服务端配置信息,还有RpcServer的构造器
│ │ ├─Exceptions // 服务端一些异常
│ │ ├─Extensions // 针对HostBuilder、ServiceCollection、WebHostBuilder的扩展
│ │ ├─Observability // 服务端的可观测性支持,目前实现了中间件
│ │ ├─RpcService // 服务端的具体Rpc服务的实现
│ │ │ ├─DataExchange // 数据交换,包含Rpc服务的数据序列化
│ │ │ ├─Endpoint // Rpc服务的端点,包含Rpc服务的端点,寻址,管理
│ │ │ └─Middleware // 包含Rpc服务的中间件的构造器
│ │ └─Transport // 服务端传输层,包含请求上下文,服务端的默认实现,Rpc链接的实现,链接层中间件构建器
│ └─SatelliteRpc.Shared // 共享层,包含一些共享的类
│ ├─Application // 应用层中间件构建基类,客户端和服务端中间件构建都依赖它
│ └─Collections // 一些集合类
└─tests // 测试项目
├─SatelliteRpc.Protocol.Tests
├─SatelliteRpc.Server.Tests
└─SatelliteRpc.Shared.Tests
安装好SDK和下载项目以后,samples
目录是对应的演示项目,这个项目就是通过我们的RPC框架调用Server端创建的一些服务,先启动Server然后再启动Client就可以得到如下的运行结果:
下面简单的介绍一下总体的设计方案:
传输协议的主要代码在SatelliteRpc.Protocol
项目中,协议的定义在Protocol
目录下。针对RPC的请求和响应创建了两个类,一个是AppRequest
另一个是AppResponse
。
在代码注释中,描述了协议的具体内容,这里简单的介绍一下,请求协议定义如下:
[请求总长度][请求Id][请求的路径(字符串)]['\0'分隔符][请求数据序列化类型][请求体]
响应协议定义如下:
[响应总长度][请求Id][响应状态][响应数据序列化类型][响应体]
其中主要的参数和数据在各自请求响应体中,请求体和响应体的序列化类型是通过PayloadConverters
中的序列化器进行序列化和反序列化的。
在响应时使用了请求Id,这个请求Id是ulong类型,是一个链接唯一的自增的值,每次请求都会自增,这样就可以保证每次请求的Id都是唯一的,这样就可以在客户端和服务端进行匹配,从而找到对应的请求,从而实现多路复用的请求和响应匹配功能。
当ulong类型的值超过最大值时,会从0开始重新计数,由于ulong类型的值是64位的,值域非常大,所以在正常的情况下,同一连接下不可能出现请求Id重复的情况。
客户端的层次结构如下所示,最底层是传输层的中间件,它由RpcConnection
生成,它用于TCP网络连接和最终的发送接受请求,中间件构建器保证了它是整个中间件序列的最后的中间件,然后上层就是用户自定义的中间件。
默认的客户端实现DefaultSatelliteRpcClient
,目前只提供了几个Invoke方法,用于不同传参和返参的服务,在这里会执行中间件序列,最后就是具体的LoginClient
实现,这里方法定义和ILoginClient
一致,也和服务端定义一致。
最后就是调用的代码,现在有一个DemoHostedService
的后台服务,会调用一下方法,输出日志信息。
下面是一个层次结构图:
[用户层代码]
|
[LoginClient]
|
[DefaultSatelliteRpcClient]
|
[用户自定义中间件]
|
[RpcConnection]
|
[TCP Client]
所以整个RCP Client的关键实体的转换如下图所示:
请求:[用户PRC 请求响应契约][CallContext - AppRequest&AppResponse][字节流]
响应:[字节流][CallContext - AppRequest&AppResponse][用户PRC 请求响应契约]
上文提到,多路复用主要是使用ulong类型的Id来匹配Request和Response,主要代码在RpcConnection
,它不仅提供了一个最终用于发送请求的方法, 在里面声明了一个TaskCompletionSource
的字典,用于存储请求Id和TaskCompletionSource
的对应关系,这样就可以在收到响应时,通过请求Id找到对应的TaskCompletionSource
,从而完成请求和响应的匹配。
由于请求可能是并发的,所以在RpcConnection
中声明了Channel<AppRequest>
,将并发的请求放入到Channel中,然后在RpcConnection
中有一个后台线程,用于从Channel单线程的中取出请求,然后发送请求,避免并发调用远程接口时,底层字节流的混乱。
客户端不仅仅支持ILoginClient
这一个契约,用户可以自行添加其他契约,只要保障服务端有相同的接口实现即可。也支持增加其它proto文件,Protobuf.Tools会自动生成对应的实体类。
该项目的扩展性类似ASP.NET Core的中间件,可以自行加入中间件处理请求和响应,中间件支持Delegate形式,也支持自定义中间件类的形式,如下代码所示:
public class MyMiddleware : IRpcClientMiddleware
{
public async Task InvokeAsync(ApplicationDelegate<CallContext> next, CallContext next)
{
// do something
await next(context);
// do something
}
}
在客户端中间件中,可以通过CallContext
获取到请求和响应的数据,然后可以对数据进行处理,然后调用next
方法,这样就可以实现中间件的链式调用。
同样也可以进行阻断操作,比如在某个中间件中,直接返回响应,这样就不会继续调用后面的中间件;或者记录请求响应日志,或者进行一些其他的操作,类似于ASP.NET Core中间件都可以实现。
序列化的扩展性主要是通过PayloadConverters
来实现的,内部实现了抽象了一个接口IPayloadConverter
,只要实现对应PayloadType的序列化和反序列化方法即可,然后注册到DI容器中,便可以使用。
由于时间关系,只列出了Protobuf和Json两种序列化器,实际上可以支持用户自定义序列化器,只需要在请求响应协议中添加标识,然后由用户注入到DI容器即可。
其它一些类的实现基本都是通过接口和依赖注入的方式实现,用户可以很方便的进行扩展,在DI容器中替换默认实现即可。如:IRpcClientMiddlewareBuilder
、IRpcConnection
、ISatelliteRpcClient
等。
另外也可以自行添加其他的服务,因为代码生成器会自动扫描接口,然后生成对应的调用代码,所以只需要在接口上添加SatelliteRpcAttribute
,声明好方法契约,就能实现。
服务端的设计总体和客户端设计差不多,中间唯一有一点区别的地方就是服务端的中间件有两种:
RpcConnectionApplicationHandler
中间件,设计它的目的主要是为了灵活处理链接请求,由于可以直接访问原始数据,还没有做路由和参数绑定,后续可观测性指标和一些性能优化在这里做会比较方便。RpcServiceHandler
的RpcConnectionApplicationHandler
中间件,放在整个连接层中间件的最后,这样可以保证最后执行的是RPC Service层的逻辑。RpcServiceMiddleware
,这里就是类似ASP.NET Core的中间件,此时上下文中已经有了路由信息和参数绑定,可以在这做一些AOP编程,也能直接调用对应的服务方法。EndpointInvokeMiddleware
的中间件,放在整个RPC Service层中间件的最后,这样可以保证最后执行的是RPC Service层的逻辑。下面是一个层次结构图:
[用户层代码]
|
[LoginService]
|
[用户自定义的RpcServiceMiddleware]
|
[RpcServiceHandler]
|
[用户自定义的RpcConnectionApplicationHandler]
|
[RpcConnectionHandler]
|
[Kestrel]
整个RPC Server的关键实体的转换如下图所示:
请求:[字节流][RpcRawContext - AppRequest&AppResponse][ServiceContext][用户PRC Service 请求契约]
响应:[用户PRC Service 响应契约][ServiceContext][AppRequest&AppResponse][字节流]
服务端对于多路复用的支持就简单的很多,这里是在读取到一个完整的请求以后,直接使用Task.Run执行后续的逻辑,所以能做到同一链接多个请求并发执行, 对于响应为了避免混乱,使用了Channel<HttpRawContext>
,将响应放入到Channel中,然后在后台线程中单线程的从Channel中取出响应,然后返回响应。
在服务端中有一个终结点的概念,这个概念和ASP.NET Core中的概念类似,它具体的实现类是RpcServiceEndpoint
;在程序开始启动以后; 便会扫描入口程序集(当然这块可以优化),然后找到所有的RpcServiceEndpoint
,然后注册到DI容器中,然后由RpcServiceEndpointDataSource
统一管理, 最后在进行路由时有IEndpointResolver
根据路径进行路由,这只提供了默认实现,用户也可以自定义实现,只需要实现IEndpointResolver
接口,然后替换DI容器中的默认实现即可。
服务端的扩展性也是在中间件、序列化、其它接口上,可以通过DI容器很方便的替换默认实现,增加AOP切面等功能,也可以直接添加新的Service服务,因为会默认去扫描入口程序集中的RpcServiceEndpoint
,然后注册到DI容器中。
现阶段做的性能优化主要是以下几个方面:
ReadOnlySequence<byte>
读取网络层数据,避免拷贝。IBufferWriter<byte>
直接将序列化的结果写入网络Buffer中,减少内存拷贝,虽然会引入闭包开销,但是相对于内存拷贝来说,几乎可以忽略。其它更多的性能优化需要Benchmark的数据支持,由于时间比较紧,没有做更多的优化。
计划做,但是没有时间去实现的:
PoolingAsyncValueTaskMethodBuilder
来池化ValueTask,这样可以减少内存分配。AwaitableCompletionSource
来降低分配。相信大家在开发中经常会遇到一些性能问题,苦于没有有效的工具去发现性能瓶颈,或者是发现瓶颈以后不知道该如何优化。之前一直有读者朋友询问有没有技术交流群,但是由于各种原因一直都没创建,现在很高兴的在这里宣布,我创建了一个专门交流.NET性能优化经验的群组,主题包括但不限于: