某个项目需要使用很多内部其他Team的DLL 和第三方的DLL (大概百来个吧......这是什么鬼啊...可怕的历史,又不能改 这些dll都上生产环境了)
如果直接用dll引用之后调用 会有很多很多的问题
1.程序的质量会下降到 这百来个dll中质量最差的一个 (万一某些人在代码里面写什么lock(string) 啊什么的....死啦死啦的)
2.很多dll需要特殊的配置 把这些东西都放在web.config就准备等死吧...也不知道哪些是哪些,维护很容易死人
3.有些dll也许内部做了什么cache啊 或者开了什么socket端口啊 这种东西.. (有个组件TMD的内部缓冲了1G的数据,要死人啊,坚决关掉他)
4.要避免不同组件之间的冲突,例如一个dll的配置影响到其他dll的配置
最终要实现的效果是
配置文件隔离
不同组的DLL之间隔离,不要让代码互相影响
想为他们做一下隔离,想了以下的方案
1.服务器隔离, 把若干个dll分为一组,部署为webservice(或socket之类的)到其他服务器上 , 通过这种方式调用相互之间的影响最小
2.进程隔离, 把若干个dll分为一组,弄一个HOST 在console或者window service 上. 通过named pipe, message之类的方式通信
3.Application Domian隔离...这个就没啥好说了,开发比较简单
1和2的开发成本太高了 而且以后debug也是一个大问题......
3的问题是
a.现在的第三方组件的类很多没有标记为Serializable 也不继承MarshalByRefObject, 输入输出参数也没有标记为Serializable,
b.需要额外的编码量,相对于直接引用来说, 增加调试难度
c.性能问题 大数据量的序列化反序列化造成性能损失(performance hurt)
目前看起来还是比较靠谱, 不过还需要做一下程序原型设计...
1.看看究竟能不能走的通
2.如何减少编码量
3.性能问题影响大么?怎么解决