状态和无状态--2种服务器架构之间的比较

原创 2007年09月25日 15:05:00
        对服务器程序来说,有两个基本假设十分重要,究竟服务器是基于状态请求还是无状态请求。状态化的判断是指两个来自相同发起者的请求在服务器端是否具备上下文关系。如果是状态化请求,那么服务器端一般都要保存请求的相关信息,每个请求可以默认地使用以前的请求信息。而无状态请求则不行,服务器端所能够处理的过程,他的处理信息必须全部来自于请求所携带的信息以及其他服务器端自身所保存的、并且可以被所有请求所使用的公共信息。
        无状态的服务器程序,最著名的就是WEB服务器。每次HTTP请求和以前都没有啥关系,只是获取目标URI。得到目标内容之后,这次连接就被杀死,没有任何痕迹。在后来的发展进程中,逐渐在无状态化的过程中,加入状态化的信息,比如COOKIE。服务端在响应客户端的请求的时候,会向客户端推送一个COOKIE,这个COOKIE记录服务端上面的一些信息。客户端在后续的请求中,可以携带这个COOKIE,服务端可以根据这个COOKIE判断这个请求的上下文关系。COOKIE的存在,是无状态化向状态化的一个过渡手段,他通过外部扩展手段,COOKIE来维护上下文关系。
        状态化的服务器有更广阔的应用范围,比如MSN、网络游戏等服务器。他在服务端维护每个连接的状态信息,服务端在接收到每个连接的发送的请求时,可以从本地存储的信息来重现上下文关系。这样,客户端可以很容易使用缺省的信息,服务端也可以很容易地进行状态管理。比如说,当一个用户登录后,服务端可以根据用户名获取他的生日等先前的注册信息;而且在后续的处理中,服务端也很容易找到这个用户的历史信息。
        状态化服务器在功能实现方面具有更加强大的优势,但由于他需要维护大量的信息和状态,在性能方面要稍逊于无状态服务器。无状态服务器在处理简单服务方面有优势,但复杂功能方面有很多弊端,比如,用无状态服务器来实现即时通讯服务器,将会是场恶梦。

        这些年,在金融软件行业发展,对这些行业软件的开发倍感古怪。原来是一家资讯公司,虽然是行业垄断地位,但是他们的技术架构倒没有什么特别之处,只能说很一般。最近在一家交易软件公司,也是行业垄断地位,技术架构极其古怪,倒值得说道和探讨。
        交易软件的所有架构的理论基础是基于无状态假设,主要分为3个层次:
        1、虚拟网络。这是最底层的基于架构,在原有的TCP/IP网络上构建了一个虚拟的TCP/UDP网络,这个概念和VPN很像。但也有很多不同。比如虚拟网络上的节点和节点所接入的实体是按数字化的标识来区别。
        2、业务中心。在虚拟网络上,建立一个业务逻辑中心,管理所有的业务逻辑单元。这个中心本身不处理业务逻辑,而是一个业务逻辑的管理器。
        3、业务单元。这个组件是专门实现各个业务逻辑的单元。业务单元本身是建立在业务中心的基础上。本身具有一定的独立性,但主要功能还是被绑定在业务中心上。业务中心相当于他的容器。
        这3个层次之间消息传输都是无状态的,当客户端从虚拟网络上发起一个请求之后,这个请求在整个传输过程中,都被认为是携带了完整的信息。这样的处理有个好处,允许传输层次进行负载均衡,自由路由,为虚拟网络的建设提供了很大的弹性。
        在业务中心和业务单元之间也是这样的。他们之间的关系借鉴了MQ的架构。每个消息都是一个完整的、独立的处理单位。这种架构由于耦合性低,所以实现难度比较低,错误发生的概率也改善很多。但从另外一方面来说,要获取信息的难度却加大了。比如一个业务逻辑想知道哪些客户端在线,几乎是不可能的事情。
        由于客户端之间的状态是不可知的。所以主动推送需要十分复杂的过程才能实现。不能简单地做到主动推送,轮询就成为主要的手段。当轮询被频繁地使用之后,系统的实时性就无法保证了。

        当然,我在这里不是为了对状态化和无状态化的服务器要分个三六九等,实际上他们都有自己适用的范围。但各个觉得,只要状态化的服务器的技术风险能够被克服,应该具备更广阔的前景,应该是个未来的发展方向。从交易软件的架构,我还是认为他是个比较成功的应用,毕竟是得到事实的检验。但在具体过程中遇到的很多问题,还是和他的无状态假设有关。感觉这种架构是将错误发生的时间和地点给延后了,而不是消灭。
        在这种系统中,状态化依然是最好的架构,但是难度是同样巨大。期待中...。努力实现他。

003.聊聊系统设计:有状态、无状态

上一期从线程安全的角度聊了聊系统设计要注意的事情,这次换个角度继续聊聊系统设计 这次主题围绕系统设计:有状态、无状态惯例,先看栗子网站登录校验,很普通的一个功能 对于这个功能我们要如何实现?先分析...

无状态服务 VS 有状态服务

对服务器程序来说,究竟是有状态服务,还是无状态服务,其判断依旧是指两个来自相同发起者的请求在服务器端是否具备上下文关系。如果是状态化请求,那么服务器端一般都要保存请求的相关信息,每个请求可以默认地使用...

对于REST中无状态(stateless)的一点认识

目前为止看到最好的一篇关于RESTFUL的文章 转自http://hi.baidu.com/tdormcswpebfmud/item/962d3afc4ac637c30dd1c8b2...

无状态服务VS有状态服务

在网易蜂巢的服务管理中存在两种服务:无状态服务和有状态服务。无状态服务(Stateless Service): 是指该服务运行的实例不会在本地存储需要持久化的数据,并且多个实例对于同一个请求响应的结...

无状态服务和有状态服务

对服务器程序来说,究竟是有状态服务,还是无状态服务,其判断依旧是指两个来自相同发起者的请求在服务器端是否具备上下文关系。如果是状态化请求,那么服务器端一般都要保存请求的相关信息,每个请求可以默认地使用...

有状态和无状态的区别

基本概念:  有状态就是有数据存储功能。有状态对象(Stateful Bean),就是有实例变量的对象 ,可以保存数据,是非线程安全的。在不同方法调用间不保留任何状态。 无状态就是一次操作...

线程安全,有状态,无状态的对象

进程是具有一定独立功能的程序关于某个数据集合上的一次运行活动,进程是系统进行资源分配和调度的一个独立单位. 线程是进程的一个实体,是CPU调度和分派的基本单位,它是比进程更小的能独立运行的基本单位....

有状态和无状态会话的区别

1 无状态 (Stateless) 在不同方法调用间不保留任何状态 。 事务处理必须在一个方法中结束 。 通常资源占用较少;可以被共享(...

有状态和无状态

精通有状态vs无状态(Stateful vs Stateless)—Immutable模式之姐妹篇 Peter Wei   我相信有不少人还不明白有状态和无状态(Stateful and Statel...

深入RESTful无状态原则

目录目录 前言 无状态原则 Web服务的状态 基于状态的Web服务 基于无状态的Web服务 总结两者的区别前言在上篇RESTful基础知识中整体的介绍了RESTful架构设计思想的框架,在往后的RES...
  • Jmilk
  • Jmilk
  • 2016年01月05日 11:55
  • 6005
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:状态和无状态--2种服务器架构之间的比较
举报原因:
原因补充:

(最多只允许输入30个字)