咨询热线:400-010-1233在线销售咨询
不方便打电话?让科腾联系您:

首页 > 公司动态 亚洲城

netcore 中的动态代理与RPC实现(微服务专题)

  2. Client stub(客户端存根)收到调用后,负责将被调用的方法名、参数等打包编码成特定格式的能进行网络传输的消息体;

  4. Server stub(服务端存根)收到通过网络接收到消息后按应格式进行拆包解码,获取方法名和参数;

  假设在系统中要调用多个服务,如果写一个函数,每次将这个服务的名字,参数,和其他信息通过一个方法来调用远程服务,假设这个方法叫做getService(methodname,object[],参数3,参数4)

  在每个调用远程服务的地方都要反射出 类的方法名称,参数等其他信息以能传给getService 是不是很麻烦?

  要知道远程服务每个服务返回的结果不会是一样的类型,那我们在客户端还要每次都转换getService的结果,是不是很麻烦?

  --请使用代理类,我们在代理类中反射代理接口得到这个方法的各种属性(名称&参数&其他),远程调用传递给远程服务,并转换得到的结果。看起来这种方法和上文的getService 差不多嘛!那我们为什么要使用代理类呢?(我也不知道,但看起来很吊的样子。)这看起来并没有很好的样子,况且如果有多个类要调用远程服务,那岂不是要写很多代理类?

  思考:调用getService 后每次都要在消费类中转换结果,使用代理类后将这个转换过程放入了代理类中,这样消费类就不用关注RPC的调用结果的类型的转换了。

  这个类的源码与上一篇反向代理文章中所讲的核心区别是 Invoke 的实现,上篇文章中其调用的是本地的一个类实体的方法,本文中其调用的是远程服务中的类实体的方法

  在查看 寒空飞箭 git 源码时候我们发现 RPCClientProxy 类和我们的ProxyDecoratorT 类 实现了相同的效果,寒空飞箭的实现方式也是很令人振奋,独辟蹊径,非常值得学习。下篇文章将会分析他的用法。感兴趣的可以自行查看作者的源码。

<< 返回

         

亚洲城

  • 联系电话:   400-010-1233
  • 地 址:       广州市天河区黄埔大道西平云路163号 广电科技大厦803-804、12楼
  • 传 真:     (8620)3835 2000
关于亚洲城 | 联系亚洲城 | 责任申明 | 网站地图 | 人才招聘 | 友情链接
Copyright © 2010 Guangzhou Ke Teng Information Technology Co. Ltd.All Rights Reserved.鄂ICP备16007204号-1