如何基于Ocelot的API网关Relay实现RPC


本篇文章为大家展示了如何基于Ocelot的API网关Relay实现RPC,内容简明扼要并且容易理解,绝对能使你眼前一亮,通过这篇文章的详细介绍希望你能有所收获。我们都知道,API网关是工作在应用层上网关程序,为何要这样设计呢,而不是将网关程序直接工作在传输层、或者网络层等等更底层的环境呢?让我们先来简单的了解一下TCP/IP的五层模型。具体的每一层的工作原理想必大家都已经滚瓜烂熟了,笔者也不在重复的复述这内容。回到上面的问题,为何API网关需要工作在应用层上的问题就变得一目了然,物理层面的网关是交给物理设备进行的,例如物理防火墙,而HTTP是网络通信中已经完全规范化和标准化的应用层协议,随处可见的通信协议,当然,你把网关集成到FTP上面也可以,增加相应的协议转换处理即可。回过头来,RPC是什么,是一个协议吗?不是。确切的说它只是“远程调用”的一个名称的缩写,并不是任何规范化的协议,也不是大众都认知的协议标准,我们更多时候使用时都是创建的自定义化(例如Socket,Netty)的消息方式进行调用,相比http协议,我们省掉了不少http中无用的消息内容,例如headers消息头。本一个简单的GET请求,返回一个hello world的请求和响应,元数据就10个字节左右,但是加上headers消息头等等http的标准内容,估计会膨胀到25~30个字节,下面是一个常见的http的headers消息头。因此很多系统内部调用仍然采用自定义化的RPC调用模式进行通信,毕竟速度和性能是内网的关键指标之一,而标准化和语义无关性在外网中举足轻重。所以,为何API网关无法工作在RPC上,因为它没有一个像HTTP/HTTPS那样的通用标准,需要我们将标准化的协议转为为自定义协议的处理,通常称为Relay,如图所示。我们已经简单的介绍了Ocelot在Http中的网关实现,无需任何修改,全都可以在配置文件中完成,相当方便。但是,我们需要实现自定义的RPC协议时,应该怎么办呢?这里可以通过增加(或扩展)OcelotMiddleware来处理下游协议的转换。我们知道,在Ocelot网关中,所有操作均通过中间件来进行过滤和处理,而多个中间件之间的相互迭代通信便形成了Ocelot的通信管道,源码中使用OcelotPipelineConfiguration来扩展和配置更多的Ocelot中间件,见源码所示:在源码中,我们可以看到,所有的中间件对应操作对象的均是DownstreamContext下游上下文对象。而MapWhenOcelotPipeline正好可以满足我们扩展中间件的需求,它提供List>&gt 香港云主机;委托以供我们配置多个下游处理中间件并映射到Ocelot管道构建器中。我们查看DownstreamContext的源码,可以看到,构建下游上下文的时候,默认就传递了HttpContext对象,而通过DownstreamRequest和DownstreamResponse完成对下游的请求和响应接收。这样,我们便可以通过对OcelotPipelineConfiguration的扩展来添加自定义中间件,我们把它扩展名称定义为OcelotPipelineConfigurationExtensions吧。当有了DownstreamContext的扩展定义,而且在下游配置中,我们需要指定的配置协议是tcp,那么我们便可以开始实现这个扩展的中间件了,我们把中间件的名称定义为RelayRequesterMiddleware。上面加粗的代码便是下游拦截的主要处理地方,在这里我们便可以使用http转rpc的协议转换处理。当然,在Ocelot的使用配置中,我们需要对该Middleware中间件进行添加。以上便完成了对Ocelot中DownstreamContext的扩展,总结下来,当我们需要扩展下游协议时,我们需要手动配置OcelotPipelineConfiguration并添加到IOcelotPipelineBuilder中,然后通过扩展IOcelotPipelineBuilder实现下游中间件的自定义处理。其实到上面这一小节,相信很多朋友都可以实现自定义的下游拦截和处理了,而本节的介绍,只是针对在Doteasy.RPC中如何进行协议转换的一个参考。我们先看一组http中的URL:http://127.0.0.1:8080/api/values,然后再看看tcp中的URL:tcp://127.0.0.1:8080/api/values。有什么区别吗?没有任何区别,唯一的区别是scheme从http转为tcp。而在rpc过程调用中,一般我们是没有“绝对路径+谓词”的方式去识别服务节点的,一般都是tcp://127.0.0.1:8080,而具体指定的服务节点交给注册中心去完成,也就是通常所说的服务发现。由于Doteasy.RPC内部并未实现如“://:@:/……”这样标准化的统一定位,所以笔者的做法是将RPC的客户端集成到Ocelot宿主中,让它替代DownstreamConext下游的请求和响应,通过扩展反射的方式实现所有代理的生成,并根据谓词和参数进行方法的调用,这样,代码就不需要做太多的修改。首先需要明白这样做的一个目的在Doteasy.RPC单次调用中,为了减少众多接口生成代理所带来的耗时,每次调用前都会检查相关接口的动态代理是否已经生成,确保每次只生成一个片段的代理。然而,作为一个网关中的中继器,这样一次生成一个代码片段显得非常无力,需要将所有的接口全部生成代理,以方便在Relay中查找和调用。再看一个RESTful风格中的URL:http://127.0.0.1:8080/api/1/Sync,一般我们将谓词放置最后,而参数一般放置在谓词的前面,在手动转换RPC的过程中,就可以利用谓词来假设我们需要调用的RPC服务名称(但实际不一定就是Sync)。基于Doteasy.RPC中的服务容器,可以很方便的实现参数类型转换以及后期的Headers处理。笔者的转换方式是将谓词作为服务名称和参数值进行调用,虽然这种方式目前来看十分拙劣,但为自定义转换提供了一组思路,还可以不断的优化和调整,目前缺点如下:当http中多个参数时,无法进行协议转换,因为不知道代理目标方法的参数集合是多少,只有全局假设一对一的参数目标。RPC客户端在网关中集成了大量的代理生成,无法实现动态更新,例如原来手动替换DLL,接口自动更新动态代理。每一次调用都需要从大量的代理中查找指定(或模糊匹配)的方法名称,如果存在1KW+的接口名称,这个查找将是一个非常严重的瓶颈。上述内容就是如何基于Ocelot的API网关Relay实现RPC,你们学到知识或技能了吗?如果还想学到更多技能或者丰富自己的知识储备,欢迎关注开发云行业资讯频道。

相关推荐: git如何添加和删除submodule

这篇文章主要介绍“git如何添加和删除submodule”,在日常操作中,相信很多人在git如何添加和删除submodule问题上存在疑惑,小编查阅了各式资料,整理出简单好用的操作方法,希望对 香港云主机大家解答”git如何添加和删除submodule”的疑惑…

免责声明:本站发布的图片视频文字,以转载和分享为主,文章观点不代表本站立场,本站不承担相关法律责任;如果涉及侵权请联系邮箱:360163164@qq.com举报,并提供相关证据,经查实将立刻删除涉嫌侵权内容。

Like (0)
Donate 微信扫一扫 微信扫一扫
Previous 08/25 18:46
Next 08/25 18:46

相关推荐