背景说明
- HSF是闭源的，考虑用开源产品（dubbo）进行替代。
- 如果是考虑要从一个rpc框架转成另一个，或许也可以参考本文。
- 主要思想：进行rpc的发布、订阅操作，其实是集中在2个类里面（provider/consumer），而不是散落在每个实现类里面。而替换成其它rpc时候，就是针对父类（providerFather/consumerFather）进行适配即可。
架构对比
可行性分析
- HSF、dubbo都出自阿里（只不过后来dubbo开源了，捐给了apache）。它们的开发设计团队好像是不同的，但它们设计思想很类似；
- 这2种rpc都是基于spring的吧？（意思它们没有依赖springboot，或者其它什么东西）；
- 这2种方式都是通过发布订阅来实现rpc的，都可以使用xml配置，api调用方式。（dubbo还有注解方式，hsf好像没有）
源项目(hsf)说明
- 1，本地使用，是用alitomcat+pandora的方式。
- 2，具体版本是：taobao-tomcat-7.0.59、edas-lightweight-server-1.0.0、pandora不记得是哪个版本了，反正不是最新的。（感觉pandora跟alitomcat有对应关系，不然会注册不到注册中心）
- 3，代码中自定义了注解，集中处理provider、consumer，会把provider注册到注册中心，把consumer缓存到map，调用的时候通过getObject的方式，创建代理对象获取远程结果。整体来讲，用到了继承+切面，这些思想，通过少量侵入，实现了rpc调用。
具体实操
- 1，引入包。需要引入dubbo的包，还有dubbo连edas的包。具体就不列举了，如果注册中心是其它，需要对应引入其它包；
- 2，通过适配的方式，写关于dubbo的provider/consumer初始化类。
- 3，处理一些异常问题。
中间遇到的一些问题
- 1，dubbo，provider、consumer都需要设置应用名称。如果一个同时启provider、consumer会有点问题，可以用代码解决；
- 2，注册到注册中心(edas)时候，如果长度过长，超过2048，会注册不进去。这个应该可以通过调整pandora版本解决（具体看pandora 容器版本说明），也可以换注册中心解决；
- 3，dubbo远程调用返回对象时，对象需要可序列号，这个可以通过改代码解决。