[解读REST] 4.基于网络应用的架构风格

  • 时间:
  • 浏览:4

衔接上文[解读REST] 3.基于网络应用的架构,上文介绍了一组自洽的术语来描述和解释软件架构;何如利用架构属性评估有一二个架构风格;以及对于基于网络的应用架构来说,哪哪多少架构属性是值得亲戚朋友 重点关注评估的。本篇在以上的基础上,列举一下或多或少常见的(REST除外)的适用于基于网络应用的架构风格,并使用对比架构属性的最好的最好的办法对其进行评估。

具体的例子:SUN的NFS。

具体的例子:RPC等。

架构风格与基于网络的软件分发-导读:http://www.infoq.com/cn/articles/doctor-fielding-article-review

具体的例子:比如linux的标准输入输出流,asp.net core中的middleware也算不算(这么跨越网络)具有相同接口的约束的UPF。

架构风格与基于网络的软件分发:http://www.infoq.com/cn/minibooks/web-based-apps-archit-design

具体的例子:DNS缓存,CDN等。

具体的例子:比如linux shell,asp.net core中的middleware和filter等。

具体的例子:发布/订阅的消息系统。

RS是CS的有某种变体,它试图使客户端组件的多样化性最小化因为使它们的可重用性最大化。每个客户在服务器上启动有一二个会话,要是 调用服务器的一系列服务,最后退出会话。应用情形被保指在服务器上。类似于风格可不并能产生如下哪多少的架构属性:

通知是对于组件中的情形变化的公告,C2不必说会对通知中应该涵盖哪哪多少内容加以限制。连接器的首要职责是消息的路由和广播,其次是消息的过滤。引入对于消息的分层过滤,可不并能补救EBI的可伸缩性的大大问题,同时改善可进化性和可重用性。

COM风格来源于CS+VM风格(要是 又不同于REV),客户端组件知道何如访问一组资源,要是 谁能谁能告诉我何如补救它们。客户端须要向服务端请求一份可不并能补救这帕累托图资源的代码,这帕累托图代码在客户端本地执行。类似于约束在CS+VM的基础上可不并能产生如下的架构属性:

理解本真的REST:http://www.infoq.com/cn/articles/understanding-restful-style/

缓存风格是克隆qq仓库风格的有一二个变种:克隆qq个别请求的结果,以便被里面的请求复用哪哪多少结果。类似于风格可不并能产生如下哪多少的架构属性:

基于事件集成的风格也被成为隐式调用风格因为事件系统风格。通过消除了解连接器接口的标识信息的必要性,它可不并能降低组件之间的耦合。此架构风格后会 之间调用另外有一二个组件,要是 通过有一二个组件发布因为广播有一二个或多个事件。要是 由系统负责调用或多或少注册了对哪哪多少事件感兴趣的组件。那我的系统一般后会有有一二个事件总线,所有的组件都通过类似于总线监听它们个人所有 感兴趣的事件。类似于风格可不并能产生如下哪多少的架构属性:

具体的例子:大多数桌面(因为APP)应用。

所有的移动代码风格的基础后会 VM(或解释器)风格。VM风格有某种并后会 基于网络的风格,要是 它通常在REV和COD风格中于有一二个组件结合在同时使用。代码在有一二个满足了安全和可靠性的受控的环境中执行,VM通常被用作脚本语言的引擎,来执行特定的任务。类似于风格可不并能产生如下哪多少的架构属性:

具体的例子:浏览器中的JS。

具体的例子:redis可不并能执行lua脚本。

具体的例子:比如GIT(分布式的版本管理系统本地有着全版的仓库副本),CVS(集中式的版本管理系统本地也是有全版的仓库副本的,要是 写操作是须要网络的)等。

LCS是在LS和CS的结合体。可不并能理解为在CS的基础上增加了代理组件和网关组件,对于客户端而言,代理组件是有一二个共享服务器,它接受请求并把它转发给服务器。网关组件在客户端组件和代理组件看来就像是有一二个正常的服务器,要是 网关组件内内外部要是 将它转发给了内内外部的或多或少服务器。在CS和LS的基础上,LCS改善了如下的架构属性:

DO是CS和CS的组合。在单独的CS的风格总,客户端和服务端是相互独立的,个人所有 只负责个人所有 的帕累托图。DO则是使有一二个组件既是客户端也是服务端。也要是 说它既对外提供服务,同时也是服务的消费方。DO组件的内内外部是全版被隐藏和保护起来的,操作它的唯一最好的最好的办法是通过它公开的接口进行访问。有一二个DO为了要和另外有一二个DO交互,则须要知道另外有一二个DO的标识信息,当有一二个DO的标识信息指在变化的之后,则须要要修改所有显示调用它的DO。要是 须要要又或多或少控制器对象来负责管理维护系统的情形。

REV风格来源于CS+VM风格,客户端组件须要知道何如执行有一二个服务,要是 缺少执行此服务所须要的资源,而哪哪多少资源都指在有一二个服务端站点上。要是 ,客户端组件把何如执行服务的代码发送给服务端的有一二个服务端组件,由它来执行代码,要是 把结果返回给客户端。类似于REV会要求被执行的代码是在有一二个受保护的环境中,使其不必影响到或多或少的客户端。类似于约束在CS+VM的基础上可不并能产生如下的架构属性:

把COD上加到签名所说的LC$SS风格上,这之后把代码被看作是另有某种形式的数据元素,要是 不必说会妨碍LC$SS的优点,同时也会叠加COD的优点。

合并了LCS和C$SS有某种风格,其产生的架构属性为LCS和C$SS的组合(要是 不必把重复的CS结算两次)。

C2是EBI和LCS的组合形成的风格。C2在EBI的基础上,支持大粒度的重用,并通过加强基础层独立性来支持系统组件的灵活组合。异步通知消息向下传递,异步请求消息向上传递,这是组件之间通信的唯一最好的最好的办法。类似于约束加强了对高层依赖的松耦合(服务请求可不并能被忽略),要是 于底层实现了零耦合(不必知道系统使用了通知),那我既改善了对整个系统的控制,又这么丧失EBI的大多数优点。

Architectural Styles and the Design of Network-based Software Architectures:https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

具体的例子:Telnet,SSH。

在CS的基础上,增加有一二个约束:服务端组件上不允许有会话情形。从客户端发给的服务器的每个请求都须要涵盖理解请求所须要的所有信息,即不到在服务端上保存请求上下文信息(比如上有一二个请求的信息),会话情形应该都保存的客户端。类似于约束会在CS的基础上,产生如下的架构属性:

具体的例子:SQL。

具体的例子:TCP/IP协议,分层的网络协议栈。

按照层次来组织,每一层都使用下层的服务,要是 为其上层提供服务。层内内外部的细节对于相邻的层而已是全版被隐藏起来的。类似于风格可不并能产生如下哪多少的架构属性:

具体的例子:DNS系统。

UPF在PF的基础上,增加了有一二个所有过滤器都须要具有相同接口的约束。类似于约束会在PF的基础上,产生如下的架构属性:

下面哪多少小节来评估每有某种架构风格,以及它们后会产生哪哪多少架构属性。(+)表示增强改善,(-)表示消弱,(±)表示取决于具体的场景。

服务器组件提供了一组服务,并监听对哪哪多少服务的请求;客户端组件通过有一二个连接器把请求发送给服务器。服务器可不并能拒绝类似于请求,也可不并能执行类似于请求,并把响应发送给客户端。服务端通常来说是有一二个永不终止的多多系统进程 ,通常是为多个客户端提供服务的。类似于约束眼前 的原则是分离关注点(要是 不必说关心会话情形是在服务端还是客户端),类似于风格可不并能产生如下哪多少的架构属性:

通过利用多个多多系统进程 来提供相同的服务,即为RR风格。哪哪多少多个分散的服务对于客户端来说,就好像是不到有一二个集中的服务。类似于风格可不并能产生如下哪多少的架构属性:

RDA是CS的有某种变体,它把应用情形分布在客户端和服务端上。客户端发送有一二个标准的数据查询请求给服务端,服务端分配有一二个工作空间并执行类似于查询,这因为会产生有一二个巨大的结果集。客户端可不并能在在结果集上进行进一步操作。这就须要客户端了解服务端的数据形态学 ,以便构造依赖该形态学 的查询。类似于风格可不并能产生如下哪多少的架构属性:

要是 以上的评估是有或多或少局限性的,这里的评估是怪怪的为分布式超媒体系统的需求量身定做的。比如通信的内容是细粒度的控制信息,这么PF风格的全都有优点就不复指在了;要是 因为用户交互的通信因为是须要的,PF则根本就不适用。同样的,因为客户端这么对请求进行缓存,这么分层+缓存的风格则只会增加延迟,而不必带来任何好处。那我的大大问题须要针对每有某种类型的通信大大问题进行单独对比。下面的表格总结一下里面介绍到的所有的架构风格。

本文版权归作者和博客园共有,欢迎转载,但未经作者同意须要保留此段声明,且在文章页面明显位置给出原文连接,要是 保留追究法律责任的权利。

 MA风格来源于REV+COD。在MA中,有一二个全版的计算组件,它的情形,代码、执行代码所需的数据都被同时移动到了远程站点。它是已REV和COM有某种最好的最好的办法同时工作的。

以上的每有某种架构风格后会 组件之间推崇有某种特定的交互类型。当组件跨域广域网的分布的之后,应用的可不并能用就会取决于对于网络的使用因为误用。通过对已架构风格对于架构属性的影响来刻画架构,并能取舍 出更适合此类应用的分发。

分发的目的是为了满足因为超出应用的需求,而后会 为了创发名有某种特殊的交互拓扑因为有某种特殊的设计最好的最好的办法。当设计有一二个系统时所取舍 的架构风格,须要与哪哪多少需求保持一致,而后会 相抵触。要是 应该最好的最好的办法哪哪多少架构风格所产生的架构属性来对架构风格进行评估。架构属性是相对的,因为上加以有一二个架构约束,增强了某有一二个架构属性,也因为会消弱另外有一二个架构属性;此外,有一二个架构属性是被增强了还是被消弱了,也会受到系统实现的的影响。

为了降低DO中受到对象标识信息的影响,通常会使用有某种因为多种架构风格来辅助通信,比如EBI和被代理的CS风格。那我的目的在于引入有一二个名称解析组件,用来把有一二个通用的服务的名称解析为有一二个并能满足该请求的对象的特定名称,并使用类似于特定名称的对象来补救请求。尽管它改善了可重用性和可进化性,要是 额外的间接层会产生一定的网络开销,从而降低用户感知的性能。具体的例子:CORBA,ODP。

 具体的例子:shadowsocks等。

在CSS的基础上,增加缓存组件。缓指在客户端和服务器直接进行周旋:它可不并能复用早先的请求,用来响应里面的相同请求,从而补救向原始服务器发送请求(得到的响应是一样的)。增加的类似于组件可不并能在CSS的基础上进一步改善以下的架构属性:

在PF风格中,每个组件(过滤器)会从输入端读取数据,并在输出端输出数据(亦可不并能增量补救,而不必说等到全版补救完再交给下有一二个过滤器)。这里的架构约束是有一二个过滤器须要全版独立于或多或少的过滤器(零耦合)。多个过滤器那我头尾相连组合起来,就像是有一二个管道,全都有称之为管道和过滤器风格(简称PF)。类似于风格可不并能产生如下哪多少的架构属性:

做了4篇博客的前期准备工作,下一篇就刚结速介绍哪哪多少是REST了。以上 如有错误之处,欢迎指正!