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

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

 

为什么一个回帖的也没呢，就这么沉了吧

不错，支持一把，可能没引起牛人的注意呢。



动态代理实现一个生命周期接口，当其被摧毁前调用生命周期方法dispose，此方法通知远程容器回收远程bean。这个代理最好在容器内做个缓存，这样业务代码就不能通过使他为null将其摧毁，只能通过unRegister来摧毁它，这样容器就可以拦截到调用生命周期方法了。



从这里看你前面的说的动态代理不一定必须是JDK的动态代理也可以是是RMI的stub代理（当然这个要做个处理，不可能有那么多的stub），或者JNDI生成的代理。
至于循环调用的问题，你没必要一定设成链式引用，你可以在每个容器中维护一个所有容器的列表，业务程序请求bean时先查询本地容器，没有在去找列表中的容器（可以在本地缓存各个容器内bean的名称）。但这样也有个问题，就是一个容器中的Bean内变量不能引用另一个容器内的Bean。除非这种引用一开始并不注入，而是请求到之后在去请求这个属性bean，生成代理然后注入。缺点时每次请求都要注入。

至于多线程没想太多，但总能解决，无非时复杂度和效率的问题

呵呵，先搞些基本需求
再深入

关于分布式的垃圾收集一般是采用租约模式(Leasing),本地代理和远程对象达成一个租约，远程对象持有这个租约，在租约过期或者本地代理回收前（回调接口）主动通知远程对象后，远程对象也被回收。当然，租约也是可更新的，租约本身的清除也是有期限的。

容期间的循环引用，也许可以采用计数解决，在查找bean的过程中对每个到达的容器计数，避免重复访问超过一定次数。

 

我也考虑过用RMI,这样的好处是不用我自己设计通信协议，而且解决传递参数是区分本地对象和远程对象的问题，有些细节也可以帮我处理，但是我希望把框架设计成非侵入式，而且还考虑到一些其他的因素，我还是放弃了RMI的方案，那个链式引用的问题其实也不是什么问题，只是提供怎样的方案来配置更方便而已，我一直坚持的一个原则就是习惯大于配置，怎么简单怎么是，哪怕牺牲点灵活性，所以我希望配置起来能够非常简单，所以才会出现这个问题，至于效率，我还没怎么考虑，我打算先做出来再说，以后可以慢慢优化

 

非常感谢你的回帖，我发了这么多天终于有人回了，呵呵

 

我也是这么想的，呵呵

呵呵 我现在在自己做一个AppServer集成，分布式集群方面也有这方面的烦恼，和你不同的是我做的没你那么底层一点，IOC容器集成PiocContainer，远程调用协议目前不准备自己写（时间要都化这里了别的很多都干不成了），JGroups配合RMI来做，当然要对RMI做一下封装，RMIC命令太烦。你通信协议写出来后发出来做各参考。

 

RMI用起来太麻烦也是我不选择RMI的一个原因，我不希望用户接触到RMI，做任何与RMI有关的工作，而且反正马上就放寒假了，我的时间多得是，时间的问题不太需要考虑

呵呵，对RMI封装下就不麻烦了，用户也感觉不到RMI的存在，就纯粹的接口调用，像register()，unRegister(),lookup()就行了