RSF分布式服务框架设计.docx

是时候设计一个分布式服务框架了。我先将它定名为 Hasor-RSF，“RSF”为?Remote Service Framework 的缩写。? ? RSF的目的是为了提供一种高效的远程服务访问方式，例如“A机器访问在B机器上的一个服务”。当然首先它是运行在Java上的，但是我并不希望 Java 成为 RSF的唯一平台。? ? 它应该是分布式的，就是说服务 A 可能会分布在若干台机器内。 当我的应用打算调用这个服务时我应该可以在这若干服务提供的机器上随机调用。这样做的好处是有助于高并发、高访问、高可用。? ? RSF 的本质其实就是 RPC 那么我们可以先对比一下 RPC 里都有什么可以被我们拿来选用。下面列出来的只是其中一些我相信聪明的朋友们会列举出更多的解决方案，我也敢保证你们知道的比我还多。Java原生的?RMI。HessianWebServicesRestfulHTTP RequestRTMP/AMF淘宝的 HSF、Dubbo? ? RMI，这个 Java 原生的东东似乎从一开始就没有被人们所看好，究其原因是速度太慢。但是它的好处是Java原生，使用 RMI 不需要引入其它任何第三方软件包。不过挑剔的同学们似乎不太看好这个优点。? ??Hessian，原则上说Hessian我并不认为它是一个远程服务框架范畴的东西。我更觉得?Hessian 是一种数据交互格式。就像是 JSON，XML-RPC，AMF，Kryo 一类的东西。Hessian 的优点是大量的兼容平台例如：“IOS、Java、.net、C++、Python、Flash、Ruby、PHP”，其次它的第二个有点是二进制格式。在大对象序列化上会占有很大的优势。? ??WebServices，一个老牌技术解决方案。在我印象中 WebServices 是跟随着 SOA 这个东西一起出名的，他有一个最大的好处是防火墙穿透。毕竟人家是靠 80 端口吃饭的，牛叉的很。不过话说回来WebServices的最大要害就是，Xml传输格式。把一个对象序列化成为一个Xml数据是一件很容易的事，但是反序列化成本似乎是很高。再加上 SOAP 协议本身是建立在 XML 形式上，这就使得 Web Service 奇慢无比了。当然因素还有很多我就不多说了。? ??Restful，其实 restful 我更觉得它是一种 API 表述规范。但在社区论坛中讨论看来，restful 的应用似乎也延伸到远程服务的领域。所以有必要说明一下。restful 最初是出现在 web 上，究其本质是还是 HTTP。例如对于：“http://xxxxx/xxxx”这个资源的访问可以利用 HTTP 的“GET、PUT、DELETE”等方法对资源操作加以描述说明。我个人觉得这东西用在 RPC 上并不合适。? ? HTTP，这是我用过最多的一种远程交互方式。远离很见dna，服务发布者将服务发布成为一个http资源。调用者请求这个http资源。数据传输格式完全程序双方自行协商。这种方法简单除暴行之有效。不过缺点是我们要自己补充通信协议，例如请求参数和响应数据格式。常规的交互格式有 JSON、XML。? ? RTMP/AMF，这个组合的确是一套很完善的远程调用解决方案。RTMP协议中专门为 Invoke 开辟了一条通道，在配合 AMF 格式极大的方便了 Flash 下远程服务访问。不过这些都是 Flash下的东西，即使是拥有 Red5 这样的神器让我们在 java 下可以使用 rtmp 但是究其目的还是为了和 flash 通信。一般 flash 调用业务系统的方式还都停留在 http 请求或者通过 red5 服务器代为转发。? ? HSF，这个东西是淘宝内部用的很广泛的远程服务框架。它是使用NIO、Mina 并且工作在长连接模式下。话说这个东西的确是个好东西，淘宝也将其开源了！只可惜，开源了 hsf 但是相关配套依赖没有开源。在加上 hsf 依赖繁杂。这个东西也就只能让局外人膜拜一下，在淘系之外的同学们是无福享受了。? ? Dubbo，也是淘系的另外一个服务框架，它比较 HSF 来说要轻巧很多。依赖会少一些，这个东东目前也是开源状态。由于我对?dubbo 一点都不了解，在这里保持沉默不做评价。? ? 最后补充一下，真正原生就支持分布式服务调用的也就只有“HSF、Dubbo”至于京东内部是否有更好的解决方案我并不知道。哦还有一点，如果您想脱离 Spring 的话 HSF、Dubbo?会让你失望的。这就是说您的技术构架如果是非 Spring 阵营的会比较悲催。? ? so，上面提到了很多可用的技术方案，想必最后符合要求也就只有其中 HSF 和 Dubbo 了。为什么其它的方案都不入选呢？原因就是它们虽然可以完成 RPC 但是并不支持