泛化调用:如何在没有接口的情况下进行RPC调用

应用场景

统一的测试平台

让各个业务方在测试平台中通过输入接口、 分组名、方法名以及参数值,在线测试自己发布的 RPC 服务。

轻量级的服务网关

让各个业务方用HTTP的方式,通过服务网关调用其它服务

如何做

所谓的 RPC 调用,本质上就是调用端向服务端发送一条请求消息,服务端接收并处理,之 后向调用端发送一条响应消息,调用端处理完响应消息之后,一次 RPC 调用就完成了。

只要调用端将服务端需要知道的信息,如接口名、业务分组名、方法名以及参数信息
等封装成请求消息发送给服务端,服务端就能够解析并处理这条请求消息,这样问题就解决

在这里插入图片描述
可以定义一个统一的接口GenericService,调用端在创建GenericService代理时需要制定调用接口的接口名、分组名,GenericService接口的invoke方法的入参就是方法名以及参数信息。如下

class GenericService {
   Object $invoke(String methodName, String[] paramTypes, Object[] params); 
}

通过统一的 GenericService 接口类生成的动态代理,来实现在没有接口的情况下进行 RPC 调用的功能,我们就称之为泛化调用。

如何进行序列化呢

  • 为泛化调用提供专属的序列化插件,通过这个插件,解决泛化调用中的序列化与反序列化
    问题
  • 可以使用 Map 类型的对象,之后通过泛化调用专属的序列化方式对这个 Map 对象进行序列化,服务端收到消息后,再通过泛化调用专属的序列化方式将其反序列 成对象。
Spring Boot使用“习惯优于配置”的理念让我们的项目快速运行起来,我们可以不用或者只需要很少的配置就能创建一个独立运行、准生产级别的基于Spring框架的项目。我们不禁要问,这么一个优秀的框架,是不是在企业开发中就已经足够了,如果是,那么为什么像BAT这些大公司还要研发自己的交易框架,当然这里面除了核心技术之外,还有两个比较重要的原因:第一:像Spring ,Spring Boot这些开源框架固然很优秀,但却不满足这些大公司对框架的功能要求,如spring scheduler就没有分布式调度能力,阿里研发了自己的tbschedule,以及后来的schedulerx;第二:开源框架可以解决具体的领域问题,比如持久化框架Mybatis,RPC框架Dubbo,但是面对业务流程的开发却不是它的强项,以此就诞生了SSM,以及后来的Spring MVC。放眼整个java开源世界,不管是功能问题还是业务流程开发问题都有对应框架和组件能满足我们的需求,只要我们的视野足够开阔,能有效的去整合开源组件,足以应付日常的开发。当然我们很难写出像Spring、Spring Boot、Mybatis这些优秀的框架,但是我们可以在这个基础之上,进行整合,甚至二次开发,形成公司自己的功能组件或者交易开发框架。不客气的说,开源框架的底层少不了spring的身影,那么可以肯定在Spring Boot推出以后,开源框架势必会以Spring Boot作为底层平台进行二次改造,这是趋势,也是必然。本课程顺应潮流,以Spring Boot作为基础平台,充分发挥其特性,抽象业务流程,整合开源组件,降低开发难度,打造出一个功能强大的交易开发框架,简洁,优雅,好用。本课程有如下技术特色:第一:充分使用Spring Boot的自动装配、条件注解,以及各种使用技巧;第二:使用注解@Transaction抽象业务流程,简化交易的定义和执行方式,比SpringMVC更符合业务流程的开发(当然SpringMVC很强大,无贬低之意)第三:为使交易具备RPC能力,使用泛化方式集成Dubbo,其好处是服务端不再需要提供接口给客户端使用,简单、高效;第四:使用nacos作为服务注册中心,也支持zookeeper;第五:为使交易具备Http能力,在Spring MVC的基础上提供HandlerMapping、HandlerAdapter。。。。一切尽在代码中
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值