转一篇我的博文：计算模式

田麦夜月

转自我的博客
没见过计算模式这个名词吧？^_^，肯定没有见过，因为这是老杜同志根据自己的经验发明的。昨天下午，在犹豫着是去不去公司英语角的时候，嫖锅发了设计部的培训信息，关于计算模式的。这个词，很熟悉也很模式，计算还是指导一些的，模式也是知道一些的，起码听说过代码模式、设计模式、架构模式。但是这两个词合起来就不知道是什么了，google了一把，竟然没有关于这个名词的任何信息。无语。。。

    听了老杜的解释，才知道这是他的专利。其实也只是用来描述在两台机子协作的时候，各自所职责的，也就是各自所处理的东西。因为计算机所作的所有事情，不严格的说都可以叫做计算，当然是广义的计算，不是数学上的计算。其中C/S、B/S都算作计算模式。

    这样从哑终端（更简单的解释）讲起了，哑终端基本上只处理一些输入/输出操作，典型的哑终端有显示屏、鼠标和键盘，但是没有处理器，不具备计算功能。哑终端只处理I/O，而服务端就从终端接受输出，计算，然后把结果传输给终端显示。这种模型里边，终端只具备I/O功能，只能显示字符及数字和响应简单的控制码，没有计算压力，所以对终端配置要求很低。但是服务端要处理所有终端的请求，计算压力很大。网络传输量很小。

    第二，citrix的MetaFrame技术，windows的远程桌面就是这种应用。客户端和服务端传输的不是数据，只是显示界面。客户端主要负责显示，服务端则处理计算，并把处理结果的的内存块发给客户端来显示。网络传输量也比较小，这对客户端的要求就比终端高一些。客户端负载小，服务端负载比较大，网络传输量比较小

    第三就是我们熟悉的B/S技术，服务器做主要的计算功能，浏览器主要做解析服务端传输过来的文本，渲染，当让可以通过js做少量的计算功能。客户端具有少量计算功能，服务端主要负责计算，客户端负载比较小，客户端负载比较大，一次操作相关的计算，全部在服务端完成。网络传输量比较大。当然，后来的Ajax技术，使得B/S有些类似C/S了。

   第四就是C/S技术，客户端承担部分计算功能，服务端承担大部分，服务端在一次操作中可以与服务端交互多次，比如提交一张表单，可以先到服务端校验某些数据是否合法，然后返回客户端进行接下来的校验或者其它的东西，当然也可以全部传到服务端进行校验。Swing程序里头，客户端一个控件值值改变，可以在客户端进行大量计算，同时可以到服务端取数。这种模式下，如果处理不好，客户端和服务端的交互次数会非常多，远程通信次数非常多，如果在广域网，网络延迟会表现的非常明显，特别是在大数据量的情况下。EAS就是这个现状，RPC通讯次数过多，性能很差。但是这种情况下，服务端压力相对比较小，界面加载显示功能都由客户端处理了。

   说了以上四点，大概也明白了什么是计算模型了。其实以上只是老杜在预研的新技术的引子，第四点已经说明了我们产品的问题－－客户端服务端通讯次数过于频繁，由于网络延迟，导致客户端响应太慢，产品性能太差。既然是客户端跟服务端交互过多，只能以负载为代价，减小传输，微调服务端和客户端的计算处理范围，弱化客户端，强化服务端。

    基本思想是这样的，服务端搞一套跟客户端Swing控件相对应的ps控件，有客户端相对应的事件，就有点类似B/S模式了，把客户端控件的事件和对应改变了的控件值，传到服务端，在服务端进行计算处理。如果一个控件的事件相关联的有很多事件，则一起传到服务端，进行对应事件的处理，数据对象则只在服务端－－ps server，不是应用服务器－－保存，计算后只把有改变的控件的值传到客户端，填充到相应控件。这种技术，客户端只负责接收用户事件，然后到客户端；并负责接收控件的值，然后绘制界面渲染。一次操作只跟服务端有一次交互，在关键操作上，大大减少了与服务端交互次数。比如现在情况时，在用户提交一表单的操作，第一次可能有近30次与服务端的交互，以后可能有10次左右。而如果是采用ps模型，一次操作（不严格的说是操作）就只有一次交互，数据传输的网络延迟就小很多了。当然这种技术，有一个比较严重的问题，服务端压力比较大。以前一张单据，1k条分录，都可能造成客户端OOM，现在这些数据全部存储在ps server端，那么有多个客户端连到一个ps server，如果都打开比较多的界面，很快就可能OOM了，不过他们定会有相关的解决方案的。

    简单粗糙的总结了下昨晚参加的公司设计部的一个交流，觉得设计部的牛人还是很多的，以后要多多参加。

PS:我的描述非常粗糙不准确，甚至有理解错老杜的意思的可能，不过可以用来了解下。老杜的文档都由好几个，每一个都可以出半本书了，我这几百字，总不可能描述清楚。