一个人做网站原型,网络营销是什么工作内容,简单的公司网页设计作品,厦门市城乡建设局网站原文链接 https://blog.csdn.net/on_1y/article/details/60358117 架构风格与基于网络的软件架构设计 如今许多服务都采用了 RESTful API, 而 REST 这一架构风格#xff0c;最早即来源于 Roy Thomas Fielding 的博士论文 Architectural Styles and the Design of Network-bas…原文链接 https://blog.csdn.net/on_1y/article/details/60358117 架构风格与基于网络的软件架构设计 如今许多服务都采用了 RESTful API, 而 REST 这一架构风格最早即来源于 Roy Thomas Fielding 的博士论文 Architectural Styles and the Design of Network-based Software Architectures 本文即是阅读此文后的总结并结合论文给出大量实例。通常人们都是因为 RESTful 风格才提到这篇论文有的人甚至只读涉及 REST 的那章。但是我读完论文后感觉最大的收获不是 REST 这一架构风格而是为基于网络的软件设计架构时应该考虑哪些因素不同的因素会导致哪些不同的结果。因此本文将重点对基于网络的软件架构进行介绍而非介绍 REST 本身。 背景 首先介绍一下作者Roy Thomas Fielding。 Fielding 博士是 HTTP/1.1 规范的主要制定者并且深度参与了 URI, HTML 规范的设计。同时是 Apache HTTP Server 项目的联合创始人Apache 软件基金会的联合创始人并在成立前三年担任软件基金会主席。Fielding 博士的这篇博士论文是 Web 发展史上极其重要的文献奠定了现代 Web 架构。可以看出此人不仅理论功底扎实还亲自写代码践行自己的理论。 Fielding 博士之所以写这篇论文也与 Web 早期的发展状况有关。早期的 Web 架构基于一些基本的原则例如简单性分离关注点通用性但是缺少对架构的精确描述。Web 早期只在政府及研究机构部署但随着公众及商业公司的介入Web 的规模在指数级增长但早期的 Web 架构已经难以支撑这样的规模。因此当时需要现代 Web 架构来支持 Web 规模的极速增长同时也要避免新架构的引入破坏了早期 Web 架构中一些良好的特性。因此作者在论文中提出了 REST 架构风格来指导现代 Web 架构的设计。这就是这篇论文出现的主要背景。 软件架构 软件架构元素 我们经常听别人谈起 “软件架构”“系统架构”“架构师”这样的名词。那么到底什么是软件架构呢Fielding 认为软件架构主要由三部分元素组成数据元素连接元素处理元素。 数据元素是指系统中被使用被转化的信息例如 HTML 文档JPEG 图片等。连接元素是将系统中不同部分连接起来的元素例如我们常用的一些用于组件和组件之前网络连接的库HttpClient, OkHttp, gRPC 等。处理元素是指对数据进行转化的元素例如 HTTP 服务器 (Apache, Nginx), 网关代理浏览器等。 软件架构本身是对系统运行时的一种抽象。一方面系统存在多个层次的抽象每层都有自己的架构另一方面系统又由多个操作阶段构成每个阶段都有自己的架构。 那么什么是多个层次的抽象呢例如你的公司有一款面向用户的移动应用。从上层的抽象来看这款应用由客户端及服务端构成。在这一层次上处理元素有客户端服务端连接元素是用于在客户端与服务器传送数据的组件数据元素即是在客户端与服务端之间传递的信息。 如果你把抽象层次下降一点就能在整个系统中发现更多的架构元素。例如把客户端抽象层次下降一些会发现客户端有 Android 和 iOS 之分。 同理服务端将抽象层次再下降一点就能识别出更多的处理元素例如用于负载均衡的处理元素。 从上面的例子可以看出从不同的抽象层次观察可以得到不同的架构。另一方面对同一系统而言在不同操作阶段也有不同的架构这是什么意思呢 对一个系统而言都有初始化提供服务停止等阶段。在不同阶段都有着不同的数据元素处理元素。 例如在初始化阶段如果我们使用了 Spring Framework, 那么 Spring 框架会根据我们的配置生成各种对象这时候数据元素是我们的配置处理元素是 Spring 框架。但是到了服务阶段各种用于处理的元素已经生成配置已经不再是此时的数据元素因为他们已经内化到处理元素中了。此时的数据元素有从客户端发来的请求中的数据有我们服务端的业务数据。此时的处理元素是服务端的各种模块例如用于搜索的模块用于渲染的模块。 软件架构配置 从上一节我们了解到软件架构由数据元素连接元素处理元素构成。但是我们描述一个软件架构时除了描述软件架构由什么元素组成还需要描述这些元素之间的关系。软件架构配置(Configurations)就是用于描述系统运行时数据元素连接元素和处理元素之间关系的概念。那么这种 “关系” 又是指什么呢我们可以将其理解为对元素之间的一种约束。 软件架构属性 我们设计软件架构时在选择了数据元素连接元素处理元素并且确定了他们之间的关系后系统就会体现出一系列性质。这些性质就是软件架构属性。 软件架构属性包括功能属性和非功能属性。功能属性表示系统是否完成了需要的功能而非功能属性则代表了系统除了完成功能之外还具有的一些性质例如可扩展性可重用性等等。 软件架构风格 一个软件架构由不同元素构成元素之间有各种各样的约束而软件架构风格就是指一组协作的架构约束。有了架构风格的概念我们就可以方便地比较不同的软件架构。当我们谈到某个系统是某种架构风格时就代表了这个系统的架构背后有一系列架构约束。 说了这么多概念他们之间到底有什么关系呢对我们设计系统又有什么用呢里面有一条重要的逻辑链条就是系统需求约束与属性之间的关系。我们设计任何一个系统都是要满足特定的需求除了特定功能需求之外有的系统需要满足高性能有的系统需要满足高可用有的系统需要经常进行灵活的扩展。那么怎么设计系统才能达到这种需求呢 那就是对系统进行一些特定的约束。特定的约束会导致特定的属性特定的属性又会满足特定的需求。 因此架构风格即一组约束导致了一组架构属性这组架构属性构成了系统需求的一个超集。 所以要设计好系统就要正确地识别出系统到底需要满足哪些需求当需求不能都满足时优先满足哪些。然后要了解如何对系统进行划分如何确定组件之间的关系有哪些约束的手段这些约束又会导致哪些属性。这也是论文后面会仔细探讨的问题。 总的来说从抽象的角度看架构风格是对架构的一种抽象一种架构风格对应多种架构。而架构本身是对系统的抽象同一架构对应着多种不同的系统。而这篇论文主要探讨的就是基于网络的应用架构以及架构风格。 基于网络的应用架构 这一节介绍基于网络的应用架构主要解决三个问题 基于网络的应用架构是指什么如何评估基于网络的应用架构基于网络的应用架构中重要的架构属性有哪些 什么是基于网络的应用架构 之前我们已经介绍了软件架构的概念基于网络的应用架构是在软件架构的基础上施加了一个约束即组件之间的通信限于消息传递。论文中还特别说明了基于网络的应用和分布式系统的区别。一般而言我们在使用分布式系统时就像使用一个集中式的系统一样网络的存在对用户来说是透明的。而基于网络的应用“网络”的存在无需表现为对用户透明的形式有时候还要用户感知到“网络”的存在特别是“网络”意味着一定的性能开销时。 如何评估基于网络的应用架构 那么我们如何评估基于网络的应用架构呢就是从根本上讲评估一个应用架构就不看这个架构是否满足了系统的需求。之前我们讲系统属性的时候说过系统属性分功能属性和非功能属性。相应地这里看架构是否满足系统的需求也要看是否满足了功能需求是否满足了非功能需求。功能需求和我们的业务相关而非功能需求就要使用架构风格来评估。 我们知道架构风格代表了一组架构约束用架构风格评估架构就是看这种约束是否能使系统的需求得到满足。 在上图中我们的系统有一组架构约束分别是 缓存无状态统一接口 同时我们还有一组系统需要的属性即系统的需求分别是 性能简单性可靠性 每种架构约束会在不同程度上影响某种属性。这样我们知道了系统的架构风格之后就能评估架构是否满足了系统的需求。 基于网络的应用架构中的重要属性 下面我们就介绍在基于网络的应用架构中重要的属性有哪些这也是我们在设计系统时要思考我们的系统最终要满足哪些属性。如果我们连有哪些属性都不知道又怎么设计一个系统 这里主要包括的属性有性能可伸缩性简单性可修改性可见性可移植性可靠性。注意我们这里谈论这些属性性关注的点都在 “基于网络” 的环境下。 性能(Performance) 我们首先要讲的一个系统属性就是性能。我们常说“性能优化”那么我们到底在优化什么性能本身又由什么决定 ACM Queue 上有一篇文章Thinking Clearly about Performance里面提到多数时候我们提到性能时指的都是计算机软件完成某种任务所需要的时间也有的时候性能是指“吞吐”即一定时间间隔内完成的任务数。这和我们常说的“响应时间” “QPS” 等是一致的。这里我们先讲性能的决定因素有哪些然后再讲性能度量问题。 性能的决定因素主要有下面几个方面 应用需求交互风格架构每个组件的实现 决定性能的首先是应用的需求。假如你的应用是用来下载数据的看视频的还是实时交易的不用类型的应用能达到的性能水平是不一样的比较不同类型应用的性能指标也是没有什么意义的。此外决定性能的还有交互风格你的系统中组件之间的通信是基于 TCP 还是 UDP达到的性能水平也会有所不同。另外架构的设计也影响系统的性能例如子系统是如何划分的连接元素用的什么有没有使用缓存组件之间数据传输的格式是什么这些都会对系统性能造成影响。最后组件的实现也会影响性能即使你什么都设计好了一个糟糕的实现还是会对性能造成致使打击。 接下来我们讲如何度量性能我们谈性能时通常谈到的就是各种性能指标这些指标就是通过不同形式的度量得到的。在基于网络的环境下对性能的度量主要分三个方面 网络性能用户可察觉性能网络使用效率 对网络性能的度量也分为多种。吞吐是指组件之间信息转移的速率负载(overhead) 是指跨网络传输带来的某种额外的负担这种“负担”可能是时间也可能是内存带宽等等负载又分初始负载每次交互的负载在组件之间通讯时我们要确定通讯是每次都要建立连接再传输数据么还是只建立一次连接后面的多次传输可以复用这个连接带宽是指特定网络上最大吞吐量可用带宽是指真正可以被系统使用的那部分带宽。 用户可察觉的性能又分为两个方面一是延迟即初次请求到首次响应的时间二是完成时间即完成一个应用动作所需要的时间。我们看下 Chrome 对一次网络请求时间的划分就能明白这个概念 从 Queueing 到 Wariting(TTFB) 即是初次请求到首次响应的时间其中 TTFB 的含义就是 (Time to first byte)即首字节响应时间。而完成时间要等到 Content Download即所有内容下载完成后才结束。区分延迟和完成时间是很重要的在其它条件都相同的条件下页面是等到所有元素下载完成后用户才能看到内容并且交互还是下载部分内容后用户就可以看到并交互了。这两种形式对用户而言是完全不同的感受虽然他们的完成时间相同。 关于网络使用效率作者给我们的忠告是 最佳的应用性能是通过不使用网络而获得的1 这就告诉我们能不使用网络的时候就不要使用网络。知乎上有一个问题”大公司里怎样开发和部署前端代码”, 其中张云龙讲的 前端静态资源部署方案 就是对如何减少网络使用最好的解读。从最初没有缓存(每次请求都要通过网络获取数据)到使用 304 协商缓存(通过网络询问内容是否有变化没变化就不需要下载资源)再到使用内容摘要精确控制缓存无需通过网络询问资源是否有变化步步减少对网络的使用从而提高了性能有兴趣可以移步张云龙的答案。 另外在服务端的设计中我们常会使用 Redis 来作缓存提高数据访问速度但是我们也要想下如果数据可以放在本地内存中是不是可以减少对网络的使用从而提高系统的性能和稳定性呢 性能的问题是个很宏大的问题在今后的博文中我们会专门讨论这个话题。 可伸缩性(Scalability) 可伸缩性是指架构支持大量组件或者大量的组件之间交互的能力。例如我们的系统用于处理客户端的请求。当请求量太大系统支持不了如此大量的请求时通常我们会如何做呢一般通过水平扩展或者垂直扩展的方式提高系统的处理能力。水平扩展就是通过增加服务实例个数的方式提升处理能力垂直扩展通过增加单个实例可以使用的资源提升系统的处理能力例如增加 CPU 核数增加内存增加存储空间机械硬盘换 SSD等方式。 系统的可伸缩性就是指我们是否可以很容易地通过水平扩展或者垂直扩展增加系统的处理能力。例如如果我们可以很容易地提高单核 CPU 的性能垂直扩展那对我们多核的需求也就没那么强烈了现实是单核 CPU 性能很难再提高所以现在已经是多核时代人们也越来越重视系统的并发能力(水平扩展。又例如现在大量使用的各种 NoSQL 数据库其中很重要的原因之一就是水平扩展性单个数据库实例的处理能力毕竟有限如果能很方便地通过加数据库实例的方式增加系统的处理能力那系统的可伸缩性就比较强。 简单性 简单性是指系统是否正确地使用了分离关注点的原则对功能进行了划分使得每个组件都足够简单。简单的组件容易被理解和实现因此简单性对系统设计而言是非常重要的。 可修改性 可修改性是指对应用架构所作的修改的难易程度。可修改性进一步可以划分成可进化性可扩展性可定制性可配置性和可重用性。总的来说可修改性就是指系统应对变化的能力。当新需求出现或者现在的系统已经不适合当前的场景时我们是不是可以通过简单地调整系统使得系统满足当前的需求。 先谈可扩展性。现在的 IDE, 无论是 Jetbrains 系列还是 Eclipse还是有宇宙第一 IDE 之称的 Visual Studio都提供了插件机制方便地对系统的功能进行扩展可扩展性。又比如著名的 Nginx, 其本身提供了一个稳定的核心同时我们可以按规范为其开发第三方模块扩展 Nginx 的能力本来这种机制就增强了 Nginx 的可扩展性但是因为 Nginx 第三方模块需要用 C 编写的对很多人而言开发效率不高因此 agentzh章亦春的 OpenResty 项目受到广泛的欢迎OpenResty 把 Nginx 与 LuaJIT 结合即保留了 Nginx 的高性能又可以方便地使用 Lua 开发自己的应用可以说进一步提升了系统的可扩展性。但是这还不够春哥准备在 OpenResty 之上再定义一个小语言 EdgeLang, 这是一种基于规则的语言用它写的代码经过编译可以生成高效的 OpenResty Lua 代码可以说进一步降低了对 Nginx 进行扩展的难度。 其次是可定制性。例如 Java 9 中将出现的模块化功能Jigsaw。有了模块化我们就可以根据自己的需要对 JDK 进行细粒度的定制和裁剪从而可以按需部署不必将 JDK/JRE 中不需要的东西也部署到生产环境。 再次是可配置性系统可以正常运行起来后一些需要经常修改的东西是写死在了代码里还是可以很方便地进行配置配置之后系统可以自动检测到变化并加载生效还是需要重启系统这些都反映可配置性的高低。 最后是可重用性。例如我们写了个负载均衡器这个负载均衡器是否与上下游的组件耦合在一起了是不是可以很方便地用到其它上下游组件的环境中如果可以在很多其它场景中使用那重用性就好如果和特定的上下游组件有强耦合那重用性就差。 可见性 可见性是指一个组件对于其它两个组件之间的交互进行监视或者仲裁的能力。例如在一个分布式的系统中可能有大量组件存在如果设计架构时没考虑可见性那系统一旦出了问题查起来就比较困难。 例如Google 的论文 Dapper 出现后就出现一系列用于分布式系统跟踪的开源项目。例如 Zipkin, Pinpoint。 从上图可以看出用 Pinpoint 我们可以观察分布式系统中组件之间的交互情况这就使得系统的可见性大大增强。 增强系统可见性不仅能在系统出现问题时快速定位系统瓶颈。也能在问题出现之初就感知到故障而不是等到某一天突然发现某个系统已经不能正常服务而我们却不知道。 可移植性 如果软件能在不同的环境下运行那软件就是可移植的。 例如Java 平台的应用由虚拟机屏蔽了底层系统的细节因此可以比较容易地在不同系统之间移植。这样你就不必在多个平台编写多套代码了。 在设计系统时我们就需要考虑系统的可移植性例如移动端应用是不是可以方便地在 iOS 和 Android 之间移植服务端应用是不是可以方便地移植到云端环境 如果系统的实现对特定环境的依赖比较重那移植起来就不大容易。 可靠性 可靠性是指当组件连接器或数据中出现部分故障时一个架构容易受到系统层面故障影响的程度。 例如系统中如果一个组件出现了故障整个系统都被拖垮了那这个系统的可靠性就比较差如果系统有良好的降级策略在部分组件故障时仍然可以保证系统核心部分正常运转那系统的可靠性就比较好。这提示我们设计组件时要避免由于自身故障对外界造成大的影响同时也要减少其它组件出现故障时自己受到影响的程度尽力提高整个系统的可靠性。 又例如如果系统设计成一个单点能服务一旦挂了就无法正常提供服务了这样可靠性就比较差。如果提供了足够的冗余一个节点挂掉其它节点还能提供服务这样可靠性就比较好。 基于网络的架构风格 这一章主要解决的问题有 什么是架构风格不同架构风格对系统属性有什么影响 什么是架构风格 架构风格就是将一组架构约束组合起来再给它一个名字。向一种架构风格添加一个约束就形成了一种新的架构风格。 上图是各种架构上的约束组合起来就组成了架构风格。 我们学习架构风格其实就是要了解各种架构约束了解他们会带来什么他们组合起来又意味着什么。 基于网络的架构风格 其中网络的架构风格主要有下面这些他们都是各种架构约束的组合。 数据流风格复制风格分层风格移动代码风格点对点风格 每种风格又可以细分出一些风格。 数据流风格 数据流风格分为下面两个风格 管道和过滤器(Pipe and Filter, PF)统一管道和过滤器(Uniform Pipe and Filter, UPF) 管道和过滤器风格在输入端读取数据流在输出端产生数据流架构上的约束为组件之间要零耦合不能共享状态。统一管道和过滤器风格在此基础上增加了一个约束即所有组件使用统一的接口。 我们可以看到很多数据流风格的例子。例如UNIX/LINUX 中的 shell, 命令和命令之间可以任意组合原因就是命令之间的接口是统一的标准输入输出数据就可以在任意组合的命令之间流动从而根据我们的需求随时组合成各种各样的功能。 又例如著名的编译器工具链 LLVM。 源代码经过编译器前端优化器编译器后端最终形成机器码。LLVM 有一套自己的代码表示方式称为 LLVM IR。在 LLVM 内部组件之间以 LLVM IR 作为接口统一的方式。编译器前端将源代码生成 LLVM IR, 优化器将 LLVM IR 转化成优化后的 LLVM IR编译器后端将 LLVM IR 转化成机器码。 这样做编译器前端的人可以专注于将各种语言转化成 LLVM IR不必关心怎么优化怎么生成各类平台上的机器码。做编译器优化的人可以专注于优化 LLVM IR不必关心前端和后端多个优化器之间也可以组合。做编译器后端的人可以专注由将 LLVM 转化成各类平台的机器码。 通过这些例子我们可以明白数据流风格的好处这种风格简化了系统的设计各个组件之间以统一的方式通信同时可扩展性可进化性很好想加个功能或者替换某个功能只需要新加一个组件或者优化其中一个组件就可以了其它组件不受到影响。每个组件在这个过程中可重用性也得到极大提高。 但数据流风格也有缺点例如组件太多会影响整个系统性能要统一接口需要转化数据格式也会影响系统性能。 复制风格 复制风格又分为下面两种风格 复制仓库(Replicated Repository, RR)缓存(Cache, $) 所谓复制仓库风格就是通过多个进程提供相同的服务。我们对这种方式应该很熟悉通过这种方式整个系统可以处理更多请求可伸缩性得到提高每个进程压力的减少也可以降低响应时间同时因为存在冗余系统也变得更可靠。 缓存风格就是复制之前请求的结果下次再有请求时直接返回之前缓存的结果。这也是比较常见的设计例如浏览器的缓存文件系统的缓存。采用缓存风格对性能有改善但是改善程度也受到缓存命中率的影响因而改善程度不如复制仓库风格对网络的使用效率也有提升因为结果直接缓存了不必穿过网络经过各种计算生成 分层风格 分层风格有很多变种但最基本的就是 客户-服务器 风格在这种风格的基础上再逐渐施加其它约束形成新的风格。 分层风格分为下面的几个风格 客户-服务器(CS)分层与分层-客户-服务器(LCS)客户-无状态-服务器(CSS)客户-缓存-无状态-服务器(C$SS)分层-客户-缓存-无状态-服务器(LC$SS)远程会话(RS) 客户-服务器风格中客户端通过连接器将请求发到服务器要求提供服务而服务器提供一组服务并监听对这些服务的请求。客户-服务器风格背后的原则是分离关注点客户端关注用户接口服务端关注业务逻辑的处理数据的生成。两端分离后可以各自独立地演化。我们可以关注一下前后端分离的一些实践来理解分离关注点原则对互联网开发模式的改变。 在分层风格中系统按层次来组织每一层为上层提供服务并使用下层的服务。典型的例子就是 TCP/IP 协议栈。 我们可以看出分层之后每一层只和其上层下层有耦合减少了跨层的耦合。应用层的协议不必关心低层的数据链路层各层都在自己的抽象层次上工作。不同的应用层可以复用下层的协议可重用性得到提高。但分层系统会降低系统的性能各层会有自己的数据格式数据格式的层层转换会带来一定开销。分层-客户-服务器风格是在客户-服务器的基础上添加了代理(proxy) 和网关(gateway) 组件。 无状态-客户-服务器风格是在客户-服务器风格基础上添加了无状态这一约束。无状态的意思就是客户端与服务端的会话状态不能在服务端保存。我们举个移动广告平台跟踪广告展示点击的例子来说明有状态的设计与无状态的设计的区别。 客户端向服务端请求广告服务端除了返回广告内容外还需要返回展示上报和点击上报跟踪链接当广告有展示时客户端会访问展示上报链接服务端收到上报后对展示进行计数点击上报也是如此。 我们先来看有状态的设计 这种设计中服务端向客户端返回的跟踪链接只有一个 id值为 123, 与此值相关的上下文信息例如广告位请求 ip时间等信息被存入数据库。当广告有展示时客户端上跟踪服务上报参数中即有 id 123 跟踪服务收到请求时从数据库中提取出与 123 相关的上下文信息之后进入统计流程。 这种设计就是一种有状态的设计此处的状态就是指 id 123 的上下文信息可以看出他们被保存在服务端。这种设计的好处是跟踪链接会比较短因而网络上传输的数据会少。坏处有很多一是系统的伸缩性变差因为广告上下文信息要在服务端存储并且在有展示时提取出来当请求量变大展示周期变大时需要存储的数据量都会被放大。二是系统的可靠性变差因为不是请求的广告都会有展示请求的上下文信息不可能永远存在服务端总有过期时间但是如果过期之后展示上报到达跟踪服务就会提取不到之前的状态信息。三是可见性下降如果展示跟踪失效可能是客户端出问题也可能数据库里没数据了数据没存进去数据过期出了问题会很难查。 我们再看来无状态的设计。 无状态的设计中与展示/点击相关的上下文信息直接放在跟踪链接中。有展示时上报的链接中就包含了与此展示相关的所有信息。好处就是系统伸缩性提高因为展示相关的状态不需要在服务端保存了分散到了客户端同时可靠性也得到提高因为状态无需维护另外可见性也得到提高因为展示相关的信息都在跟踪链接里了直接观察是否上报了正确的链接就可以分析展示上报情况。坏处就是如果展示相关信息很多链接会很长在网络上传输的数据会变多也可能会被截断。 当然有状态的设计自然有它的用处但是不在上面我们举例的那类场景。这就是我们要讲的远程会话风格。 远程会话风格是客户-服务器风格的变体客户端在服务器启动会话而应用的状态完全保留在服务器上。这样的好处是客户端的设计可以得到很大简化可重用性得到提高。而系统功能的扩展性也得到提高因为升级服务端后所有客户端可以同时受益想想升级客户端与服务端的难度就可以明白这一点就多方便。当然坏处就是因为服务端要保存客户端状态降低了伸缩性。 移动代码风格 移动代码风格使用移动性(mobility)来动态地改变处理过程与数据源之间的距离。主要有下面几种风格 虚拟机(VM)远程求值(REV)按需代码(COD) 虚拟机风格应该是我们比较熟悉的例如常用的 Java 语言运行在虚拟机上虚拟机分离了指令与实现可移植性比较好因为虚拟机本身帮我们屏蔽了底层系统的细节另外扩展性也比较好例如 Java 虚拟机有了 G1 垃圾收集器后所有平台上的 Java 代码均可同时受益。 远程求值风格适用的场景是客户端知道如何执行服务但是缺少执行服务的资源此时客户端可以将代码发送到服务端服务端组件执行完后将结果返回客户端。例如我们用 Spark Shell 对大规模的数据作交互式的分析时数据和计算资源都不在本地但是客户端知道分析机群上的哪些数据知道如何分析代码会被发到 Spark 集群上对数据进行分析分析结果最后又返回 Spark Shell。 按需代码风格中客户端知道如何访问资源但是不知道如何处理资源此时客户端可以向远程服务器请求处理资源的代码在本地执行。典型的例子就是 JavaScript浏览器从服务器上下载 JS 代码在浏览器中执行。这种方式的好处是能够方便地为已经部署的客户端添加功能改善了可扩展性。我们想添加新功能时升级 JS 代码就可以了浏览器下载了新版本的 JS 代码就能使用新功能了。 点对点风格 点对点风格要介绍的一种风格叫 基于事件的集成(EBI)其含义是一个组件发布一个或者多个事件其它组件对某类事件进行订阅。 例如在 Kafka 中生产者向某个 topic 生产数据可以有多个消费者消费这个 topic 中的数据。当我们想用这个 topic 中的数据做更多的事情时只需要新增加一个消费者就可以了。这样系统的扩展性就很好。同时消费者可以独立地演化而不会影响其它消费者。想象一下如果你把这些消费者的功能集中在某一个系统中那每次添加功能都要改这个系统同时如果某个功能对资源的消耗比较大因为其它功能和这个功能在同一系统中就会对其它功能造成影响。 到这里我们对各种架构风格的介绍就结束了。 设计 Web 架构 Roy Fielding 博士在定义了架构属性架构约束架构风格之后用这些理论去指导 Web 架构的设计。 之前已经说过Web 规模开始扩大后现有架构的缺陷已经不能支持这么大的规模需要对其进行增强摆在眼前的任务有 定义在现有的早期 Web 架构中被公共地、一致地实现的架构通信的子集识别出在这个架构中存在的问题定义标准解决问题: URI, HTTP, HTML 架构风格就被用于解决这些问题首先架构风格被用于描述现有 Web 架构背后的基本原理包括分离关注点简单性通用性等。然后通过为架构风格添加约束使其满足现代 Web 架构所需要的属性。在修改 Web 架构时要与新 Web 架构风格进行比较分析以便在新提议部署前识别出其与 Web 架构风格的冲突。 表述性状态转移(REST) 在介绍完各种约束架构风格后REST 架构风格就变得水到渠成了。它是通过在一个空风格基础上不断添加约束而形成的。 从空风格开始先后添加下面的约束 客户-服务器无状态缓存统一接口分层按需代码 之前我们已经讲了这些约束对系统设计而言意味着什么。 最后用两张图总结一下 REST 架构风格推导中的约束与属性的关系。 上图可以看出在 REST 架构推荐过程中添加的各种约束。 上图可以看出各种约束为系统带来的各种特性。 总结 文章到这里就全部结束了这篇文章主要结合 Roy Fielding 博士论文的前三章介绍了基于风格的应用架构设计中需要关注的架构属性架构约束以及架构风格。有些内容基于经验所限可能无法做到表达精确希望以后能不断修改补充。
