网络应用的架构风格

目前基于网络应用的架构风格主要有三种： 

       RPC架构风格 将服务器看作是由一些过程组成，客户端调用这些过程来执行特定的任务。SOAP就是RPC风格的一种架构。过程是动词性的（做某件事），因此RPC建模是以动词为中心的。 

     分布式对象架构风格 认为服务器是由一些对象和对象上的方法组成，客户端通过调用这些对象上的方法来执行特定的任务。并且客户端调用这些对象上的方法应该就像是调用本地对象上的方法一样，这样开发就可以完全按照统一的面向对象方法来做。但是很可惜，这样的抽象并不是很有效，因为分布式对象与本地对象存在着巨大的本质差别，想要掩盖这些差别很多时候甚至是有害无益的。

       REST架构风格 将服务器抽象为一组离散资源的集合。资源是一个抽象的概念，而不是代表某个具体的东西。注意：要真正理解REST，就一定要增强自己的抽象思维能力，充分理解到资源是抽象的。资源是名词性的，因此REST建模是以名词为中心的。 

      上述是目前基于网络的应用的主要的三种抽象方式。这三种不同的抽象方式会严重影响客户端与服务器的交互模式，而不同交互模式的交互效率差别相当大。分布式对象的交互模式很多时候效率很低，因为掩盖了分布式对象与本地对象的差别，很多时候都会导致细粒度的API。实践已经证明，与RPC和分布式对象相比，REST是一种对于服务器更加有效的抽象方式，将会带来粒度更大和更有效率的交互模式。这样的效果与Fielding设计REST的初衷是吻合的，REST就是专门为交互的性能和可伸缩性进行过优化的一种架构风格。而SOAP在设计的时候优先考虑的从来不是性能和可伸缩性，而是互操作性，其开发效率比较低。 REST的主要优势其实在于它是一种对于服务器的更加有效的抽象方式。 性能分析：与基于二进制通信的RPC例如RMI对比，REST是基于文本传输的，从这点看应该说性能不如前者，但是REST强调通信语义对于中间组件的可见性，这样可以改善性能和可伸缩性。例如浏览器就是一种中间件。浏览器可以根据通信的语义来确定数据有没有发生改变，从而进行有效的缓存。RMI传输数据再有效，它的数据也无法做有效的缓存。因此RMI的性能未必比REST好，况且不能缓存会带来严重的可伸缩性问题。 如果说设计模式是从代码角度为系统降低耦合度，那么架构风格便是从数据角度解耦。架构是更加宏观和全面的视角，它不再是解决单一的技术问题，而是为系统提供更加完整的解决方案。

--------------------------------------------------------------------------------------------------------------------

 架构风格是一种粗粒度的软件模式，为常见软件问题提供解决方案，促进软件的重用。常见的软件架构风格如下:1.Pipe & Filter2.Batch3.VM4.Layered Architecture5.MVC, PAC6.MicroKernel7.Event System8.Blackboard System9.Broker, C/S, P2P, SOA参考http://www.infoq.com/news/2009/02/Architectural-Styles-Patterns每种架构风格适用于某种特定的问题域，比如第九项全部是分布式计算领域的架构风格。从用户最常见的GUI和CUI环境视角看：CUI常常是具有单一输入和单一输出，比较擅长处理有机械性、重复性和规律性的问题。GUI更擅长有交互性的任务，它的输入和输出之间时常会变化并加以排列组合。CUI和GUI是一种演化的关系：1.当输入是单一流或者多个单一流时，架构风格往往是Pipe & Filter/Batch/N Layered。2.当输入是多个流时，架构风格通常是MVC/PAC。3.当需要合并多个输入流时，则会使用Event System/MicrosKernel。4.当需要合并多个输出流时，则会使用Blackboard System。对于1，在Linux中系统管理员和程序员常用Pipe & Filter处理文本流；而在流媒体系统中，Pipe & Filter用来demux视频流和音频流。这种固定输入流的任务很容易实现批量功能而变成Batch状态。VM虚拟机可以简单看作是复杂输入而没有相应输出的任务。Layed Arch是一种存在依赖的Pipe & Filter，它的处理顺序和流程已经事先设定好。对于2，MVC不仅仅是设计模式，当它能解决多个输入流问题时，它成为为一种架构风格。MVC以及其衍生的MVVC, MVP, PAC将输入模块，数据模块和协调控制模块分解开来。类似的模型比较强调Control的作用。对于3和4，它们常常和MVC共同使用。3, 4代表一种处理更复杂问题的一般思路。数据可能是输入或输出，也可能是一种解耦的方式。比如实现接口的虚表就是一种解耦数据。直接传递数据会降低系统性能，上下文情景分析和有效数据分离都会增加计算时间开销。Event System往往会维护原始的上下文和当前变化数据的信息，这些数据出现在输入流的最开始处理阶段或着是前后处理模块的衔接过程。Blackboard System强调了Model的作用，拥有共同的Model特别是Domain Model可以在更宏观的层面上为系统解耦或接入更多的生产者与消费者。