RPC与消息
公司这边需要一套RPC框架，由于技术比较繁杂，包括Python、C++、C#，还有可能有Erlang。所以最佳方案莫过于Facebook的Thrift。用了几周时间研究，发现这个玩意文档非常差劲。最终我对Thrift的了解还是出于阅读了它关于Python的所有代码。虽说Thrift支持技术广泛，不过其Python服务器相对比较落后，估计也是没太多人用。服务器有四种运行方式，Simple Server、Thread Server、ThreadPool Server、Fork Server。第一种就不用说了，一个迭代服务器，没法应用于产品环境。问题是后几种也很不方便，偶尔出现服务终止，而且也没法用daemon方式运行。问题解决的王道当然是引入Twisted。
Thrift中是有TTwisted.py模块的，不过里面的代码看得我一头雾水，明显就是恶搞么。整个通信协议有多种不同的头格式。可是其Twisted支持代码一律采用i32头+字符串方式来解析。结果自然是没法用。期间我还尝试自己写其Twisted的支持。用Greenlet来解决回调变同步的问题。不过正在写的时候，变故发生了。
我做后端，服务器端(也就是我的客户端)的同事因为他们服务器框架的问题需要我实现异步的调用和返回。也就是他发出请求以后要立即返回，然后回头再来轮询是否生成了结果。还有就是要求服务器要有能力推送通知到客户端。这两点是Thrift没法解决的，还有个问题就是Thrift的官方发行版本的C++运行时不支持Win32环境，而那些同事的应用服务器就是在Win32下运行的。
好了，长话短说，于是我们头提出要换ICE，我是百般的不爽，毕竟付出了很多心血的一个东西要这么被废掉。最终，今天，决定研究一下ICE方案的可行性。现在看来ICE框架支持的功能众多，不过同样如此让我想起CORBA这个噩梦。
刚才成功的在FreeBSD 7.2下用pkg_add方式安装了Ice了，明天再去试试。官方虽然没有提到支持FreeBSD，但是FreeBSD的源里面已经有二进制包了，看来成熟度还是符合要求的。
页:
[1]