还剩3页未读,继续阅读
文本内容:
是时候设计一个分布式服务框架了我先将它定名为Hasor-RSF,“RSF”为 RemoteServiceFramework的缩写 RSF的目的是为了提供一种高效的远程服务访问方式,例如“A机器访问在B机器上的一个服务”当然首先它是运行在Java上的,但是我并不希望Java成为RSF的唯一平台 它应该是分布式的,就是说服务A可能会分布在若干台机器内当我的应用打算调用这个服务时我应该可以在这若干服务提供的机器上随机调用这样做的好处是有助于高并发、高访问、高可用 RSF的本质其实就是RPC那么我们可以先对比一下RPC里都有什么可以被我们拿来选用下面列出来的只是其中一些我相信聪明的朋友们会列举出更多的解决方案,我也敢保证你们知道的比我还多Java原生的 RMIHessianWebServicesRestfulHTTPRequestRTMP/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形式上,这就使得WebService奇慢无比了当然因素还有很多我就不多说了 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但是并不支持分布式当然您可以通过架设集群来提高它们的可靠性,这些都是您需要额外付出的------------------------------ 下面这个是RSF的架构图,包括服务生产着和消费者在内RSF被分为6层(网络层、协议层、请求响应层、调度层、接口层、消费者生产者)关键5层 Netty,其中位于最下层的网通信部分RSF采用Netty实现Netty是一款非常优秀的网络通信框架,使用Netty可以帮助RSF减少大量底层网络上的代码开发这也就意味着RSF将采用 Selector 方式实现异步IO Protocol,协议层该层主要的目的是负责解释翻译RSF数据包,并将RSF数据包转意成为Request和Response对象协议层可以是一个协议栈,这就意味您可以通过RTMP、或者其它自定义网络协议传输RSF数据包 Request/Response层,请求响应层这个在这个层中,RSF脱离了底层网络方面的特性将每次调用请求对象化为一个Request对象,并且将调用结果封装成为一个Response对象这种编程模式和Web很像 调度层,这一层最为复杂它负责管理本地RSF服务的注册,远程传输对象序列化方式的管理,并且还要负责实现其它更加复杂的功能 接口层,这一层是最终RSF暴露给业务系统的接口,将会由两个类提供一个代表服务生产着,另一个是服务消费者序列化格式 RSF规定在网络中传输的数据格式可以是任意的这就意味着您可以使用AMF 作为RSF数据传输格式发布(同时如果协议层支持RTMP那您可以在Flash中无需通过red5这样的中间代理直接访问RSF服务)同样的,如果您使用 Hessian作为数据传输格式,在其它平台例如.net、php也会很方便的调用RSF服务(需要解析RSF数据包)如果协议采用HTTP,RSF序列化格式采用JSON,那么运行在浏览器中的javascript也可以绕过web服务器,直接访问RSF服务服务配置Config 说是服务配置,其实就是路由的功能先假设我们有4台服务器,其中有两台是位于北京机房,另外两台分别位于青岛和内蒙古这四台机器上都运行着RSF,跑着相同的业务系统,这种架构通常前端会有一个CDN之类的东西负责让用户就近访问网站 如果没有服务路由的情况下,用户A在北京即使访问了最近的北京服务器,但是由于调用的RDS服务是青岛的,那么也会降低访问速度因此服务配置所负责的路由特性可以很方便的高速服务调用程序,优先选用北京机房的RSF服务只有当北京机房的服务撑不住的情况下才会动用其它地域的RSF服务 流量管控高级一点的特性是可以通过服务路由来控制服务流量假如目前要做一个全国范围的活动,我们充分的为每个地方准备了若干机器但是在活动现场很可能某一个地区的服务使用量达到了临界点,服务路由应该可以通过配置的方式让附近地区的机器提供一定的流量来减缓这个地区的访问压力。