关于分布式容器的一点想法

      这几天一直在考虑分布式计算的问题,因为之前写过一个IoC框架,所以打算对原来的框架进行扩展,做成一个分布式的容器,该容器的设计目标是:由多个子容器构成一个大的分布式容器,用户不需要知道Bean存在于哪一个容器中,只需知道Bean的ID即可进行调用,对用户来讲,远程容器中的Bean和本地的Bean是没有区别的,容器是非侵入式的,不需要继承任何类或者实现接口。
      最初考虑到比较简单,觉得容器解决的只是容器间的通信问题,我设想的是用户请求远程容器中的Bean时,在本地生成目标接口的一个动态代理,该动态代理通过把参数对象序列化(或者其他方式)后保存在一个调用请求中,然后把调用请求传递给远程容器,远程容器接收到请求后调用容器中的Bean,把返回结果对象序列化后保存在一个调用响应中,然后把调用响应返回给本地容器,由动态代理对象处理后返回。
      真正开始设计之后才发现很多细节问题没有考虑到,比如远程容器中Bean的生存周期(非单例状态的情况下),本地容器中的动态代理对象成为垃圾之后如果保证远程容器中的Bean被回收。我设想的分布式是通过容器间的引用来配置的,比如,容器A引用容器B,那么A可以透明的调用B中的Bean,从简化配置和设计的角度来考虑,如果A引用了B,B又引用了C,应该让A也能够调用C才对,也就是说应该具有传递性,但是很可能存在的情况是容器间存在循环引用,这时如果用户请求了一个不存在的Bean,就会出现死循环的情况。还有容器必须把结果返回给正确的调用者,还有多线程等问题……
      突然想到《非诚勿扰》里的一句台词:老说改进服务质量,怎么改进啊?其实就是细节。

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值