软件架构模式


软件架构模式 Mark Richards 著 版权归 © 2015 O’Reilly Media, Inc. 所有 . 原书发布链接为 Software Architecture Patterns. 译员信息 本书的译员均来⾃ 开发技术前线 www.devtf.cn。 译者 个⼈简介 Mr.Simple 乐于分享,热爱开源的⼯程师, 个⼈博客 chaossss 追⻛筝的吃货,汪〜。 个⼈博客 Allenlsy 计算机科学爱好者, Rails程序员。 个⼈博客 BillonWang 做好玩的事情,交好玩的朋友。 个⼈博客 dupengwei 乐于分享的移动互联⺴开发⼯程师 Charli Hu 喜欢英语,不放弃编程的菇凉。 简介 第⼀章 分层架构 第⼆章 事件驱动架构 第三章 微内核架构 第四章 微服务架构 第五章 基于空间的架构 附录 A 关于作者 对程序员来说很常⻅⼀种情况是在没有合理的程序架构时就开始编程,没有⼀个清晰的和定义好的架构的时 候,⼤多数开发者和架构师通常会使⽤标准式的传统分层架构模式(也被称为多层架构) ——通过将源码模 块分割为⼏个不同的层到不同的包中。不幸的是,这种编码⽅式会导致⼀系列没有组织性的代码模块,这些 模块缺乏明确的规则、职责和同其他模块之间的关联。这通常被称为架构⼤泥球。 应⽤程序缺乏合理的架构⼀般会导致程序过度耦合、容易被破坏、难以应对变化,同时很难有⼀个清晰的版 本或者⽅向性。这样的结果是,如果你没有充分理解程序系统⾥每个组件和模块,就很难定义这个程序的结 构特征。有关于程序的部署和维护的基本问题都难以回答,⽐如:程序架构是什么规模 ?应⽤程序有什么性能 ⺫录 简介 特点 ?应⽤程序有多容易应对变化 ?应⽤程序的部署特点是什么 ?架构是如何反应的 ? 架构模式帮助你定义应⽤程序的基本特征和⾏为。例如,⼀些架构模式会让程序⾃⼰⾃然⽽然地朝着具有良 好伸缩性的⽅向发展,⽽其他架构模式会让程序朝着⾼度灵活的⽅向发展。知道了这些特点,了解架构模式 的优点和缺点是⾮常必要的,它帮助我们选择⼀个适合⾃⼰特定的业务需求和⺫标的的程序。 作为⼀个架构师 ,你必须证明你的架构模式的决策是正确的 ,特别是当需要选择⼀个特定的体系结构模式或⽅法 的时候。这本迷你书的⺫的就是给你⾜够的信息让你去做出正确的架构决策。 分层架构是⼀种很常⻅的架构模式,它也叫 N层架构。这种架构是⼤多数 Jave EE应⽤的实际标准,因此很多 的架构师,设计师,还有程序员都知道它。许多传统 IT公司的组织架构和分层模式⼗分的相似。所以它很⾃ 然的成为⼤多数应⽤的架构模式。 分层架构模式⾥的组件被分成⼏个平⾏的层次,每⼀层都代表了应⽤的⼀个功能 (展⽰逻辑或者业务逻辑 )。 尽管分层架构没有规定⾃⾝要分成⼏层⼏种,⼤多数的结构都分成四个层次 :展⽰层,业务层,持久层,和数 据库层。如表 1-1,有时候,业务层和持久层会合并成单独的⼀个业务层,尤其是持久层的逻辑绑定在业务层 的组件当中。因此,有⼀些⼩的应⽤可能只有 3层,⼀些有着更复杂的业务的⼤应⽤可能有 5层或者更多的分 层。 分层架构中的每⼀层都着特定的⾓⾊和职能。举个例⼦,展⽰层负责处理所有的界⾯展⽰以及交互逻辑,业 务层负责处理请求对应的业务。架构⾥的层次是具体⼯作的⾼度抽象,它们都是为了实现某种特定的业务请 求。⽐如说展⽰层并不需要关⼼怎样得到⽤户数据,它只需在屏幕上以特定的格式展⽰信息。业务层并不关 ⼼要展⽰在屏幕上的⽤户数据格式,也不关⼼这些⽤户数据从哪⾥来。它只需要从持久层得到数据,执⾏与 数据有关的相应业务逻辑,然后把这些信息传递给展⽰层。 第⼀章 分层架构 模式分析 分层架构的⼀个突出特性是组件间关注点分离 (separation of concerns)。⼀个层中的组件只会处理本层的逻 辑。⽐如说,展⽰层的组件只会处理展⽰逻辑,业务层中的组件只会去处理业务逻辑。多亏了组件分离,让 我们更容易构造有效的⾓⾊和强⼒的模型。这样应⽤变的更好开发,测试,管理和维护。 注意表 1-2中每⼀层都是封闭的。这是分层架构中⾮常重要的特点。这意味 request必须⼀层⼀层的传递。举 个例⼦,从展⽰层传递来的请求⾸先会传递到业务层,然后传递到持久层,最后才传递到数据层。 那么为什么不允许展⽰层直接访问数据层呢。如果只是获得以及读取数据,展⽰层直接访问数据层,⽐穿过 关键概念 ⼀层⼀层来得到数据来的快多了。这涉及到⼀个概念 :层隔离。 层隔离就是说架构中的某⼀层的改变不会影响到其他层 :这些变化的影响范围限于当前层次。如果展⽰层能够 直接访问持久层了,假如持久层中的 SQL变化了,这对业务层和展⽰层都有⼀定的影响。这只会让应⽤变得 紧耦合,组件之间互相依赖。这种架构会⾮常的难以维护。 从另外⼀个⽅⾯来说,分层隔离使得层与层之间都是相互独⽴的,架构中的每⼀层的互相了解都很少。为了 说明这个概念的⽜逼之处,想象⼀个超级重构,把展⽰层从 JSP换成 JSF。假设展⽰层和业务层的之间的联系 保持⼀致,业务层不会受到重构的影响,它和展⽰层所使⽤的界⾯架构完全独⽴。 然⽽封闭的架构层次也有不便之处,有时候也应该开放某⼀层。如果想往包含了⼀些由业务层的组件调⽤的 普通服务组件的架构中添加⼀个分享服务层。在这个例⼦⾥,新建⼀个服务层通常是⼀个好主意,因为从架 构上来说,它限制了分享服务访问业务层 (也不允许访问展⽰层 )。如果没有隔离层,就没有任何架构来限制 展⽰层访问普通服务,难以进⾏权限管理。 在这个例⼦中,新的服务层是处于业务层之下的,展⽰层不能直接访问这个服务层中的组件。但是现在业务 层还要通过服务层才能访问到持久层,这⼀点也不合理。这是分层架构中的⽼问题了,解决的办法是开放某 些层。如表 1-3所⽰,服务层现在是开放的了。请求可以绕过这⼀层,直接访问这⼀层下⾯的层。既然服务层 是开放的,业务层可以绕过服务层,直接访问数据持久层。这样就⾮常合理。 开放和封闭层的概念确定了架构层和请求流之间的关系,并且给设计师和开发⼈员提供了必要的信息理解架 构⾥各种层之间的访问限制。如果随意的开放或者封闭架构⾥的层,整个项⺫可能都是紧耦合,⼀团糟的。 以后也难以测试,维护和部署。 为了演⽰分层架构是如何⼯作的,想象⼀个场景,如表 1-4,⽤户发出了⼀个请求要获得客户的信息。⿊⾊的 箭头是从数据库中获得⽤户数据的请求流,红⾊箭头显⽰⽤户数据的返回流的⽅向。在这个例⼦中,⽤户信 息由客户数据和订单数组组成 (客户下的订单 )。 ⽤户界⾯只管接受请求以及显⽰客户信息。它不管怎么得到数据的,或者说得到这些数据要⽤到哪些数据 表。如果⽤户界⾯接到了⼀个查询客户信息的请求,它就会转发这个请求给⽤户委托 (Customer Delegate)模 块。这个模块能找到业务层⾥对应的模块处理对应数据 (约束关系 )。业务层⾥的 customer object聚合了业务 请求需要的所有信息 (在这个例⼦⾥获取客户信息 )。这个模块调⽤持久层中的 customer dao 来得到客户信 息,调⽤ order dao来得到订单信息。这些模块会执⾏ SQL语句,然后返回相应的数据给业务层。当 customer object收到数据以后,它就会聚合这些数据然后传递给 customer delegate,然后传递这些数据到 customer screen 展⽰在⽤户⾯前。 从技术的⾓度来说,有很多的⽅式能够实现这些模块。⽐如说在 Java平台中, customer screen 对应的是 (JSF) Java Server Faces ,⽤ bean 组件来实现 customer delegate。⽤本地的 Spring bean或者远程的 EJB3 bean 来实现业务层中的 customer object。上例中的数据访问可以⽤简单的 POJP's(Plain Old Java Objects),或者可以⽤ MyBatis,还可以⽤ JDBC或者 Hibernate 查询。 Microsoft平台上, customer screen能 ⽤ .NET 库的 ASP模块来访问业务层中的 C#模块,⽤ ADO来实现⽤户和订单数据的访问模块。 分层架构是⼀个很可靠的架构模式。它适合⼤多数的应⽤。如果你不确定在项⺫中使⽤什么架构,分层架构 是再好不过的了。然后,从架构的⾓度上来说,选择这个模式还要考虑很多的东⻄。 ⽰例 注意事项 第⼀个要注意的就是 污⽔池反模式 (architecture sinkhole anti-pattern)。 在这个模式中,请求流只是简单的 穿过层次,不留⼀点云彩,或者说只留下⼀阵⻘烟。⽐如说界⾯层响应了⼀个获得数据的请求。响应层把这 个请求传递给了业务层,业务层也只是传递了这个请求到持久层,持久层对数据库做简单的 SQL查询获得⽤ 户的数据。这个数据按照原理返回,不会有任何的⼆次处理,返回到界⾯上。 每个分层架构或多或少都可能遇到这种场景。关键在于这样的请求有多少。 80-20原则可以帮助你确定架构是 否处于反污⽔模式。⼤概有百分之⼆⼗的请求仅仅是做简单的穿越,百分之⼋⼗的请求会做⼀些业务逻辑操 作。然⽽,如果这个⽐例反过来,⼤部分的请求都是仅仅穿过层,不做逻辑操作。那么开放⼀些架构层会⽐ 较好。不过由于缺少了层次隔离,项⺫会变得难以控制。 下⾯的的表⾥分析了分层架构的各个⽅⾯。 评级 :低 分析 :总体灵活性是响应环境变化的能⼒。尽管分层模式中的变化可以隔绝起来,想在这种架构中做⼀些也改 变也是并且费时费⼒的。分层模式的笨重以及经常出现的组件之间的紧耦合是导致灵活性降低的原因。 评级 :低 分析 :这取决于你怎么发布这种模式,发布程序可能⽐较⿇烦,尤其是很⼤的项⺫。⼀个组件的⼩⼩改动可能 会影响到整个程序的发布 (或者程序的⼤部分 )。发布必须是按照计划,在⾮⼯作时间或者周末进⾏发布。因 此。分层模式导致应⽤发布⼀点也不流畅,在发布上降低了灵活性。 评级 :⾼ 分析 :因为组件都处于各⾃的层次中,可以模拟其他的层,或者说直接去掉层,所以分层模式很容易测试。开 发者可以单独模拟⼀个展⽰组件,对业务组件进⾏隔绝测试。还可以模拟业务层来测试某个展⽰功能。 评级 :低 分析 :尽管某些分层架构的性能表现的确不错,但是这个模式的特点导致它⽆法带来⾼性能。因为⼀次业务请 求要穿越所有的架构层,做了很多不必要的⼯作。 评级 :低 分析 :由于这种模式以紧密耦合的趋势在发展,规模也⽐较⼤,⽤分层架构构建的程序都⽐较难以扩展。你可 以把各个层分成单独的物理模块或者干脆把整个程序分成多个节点来扩展分层架构,但是总体的关系过于紧 模式分析 整体灵活性 易于部署 可测试性 性能 伸缩性 密,这样很难扩展。 评级 :容易 分析 :在开发难度上⾯,分层架构得到了⽐较⾼的分数。因为这种架构对⼤家来说很熟悉,不难实现。⼤部分 公司在开发项⺫的都是通过层来区分技术的,这种模式对于⼤多数的商业项⺫开发来说都很合适。公司的组 织架构和他们软件架构之间的联系被戏称为 "Conway's law"。你可以 Google⼀下查查这个有趣的联系。 译者注:⽂章中 mediator 及 broker 的概念很容易混淆,在⽂章的结尾处译者对两者的区别(还有 proxy)进⾏了⼀定的阐述 事件驱动架构模式是⼀种主流的异步分发事件架构模式,常⽤于设计⾼度可拓展的应⽤。当然了,它有很⾼ 的适应性,使得它在⼩型应⽤、⼤型应⽤、复杂应⽤中都能表现得很好。事件驱动架构模式由⾼度解耦、单 ⼀⺫的的事件处理组件构成,这些组件负责异步接收和处理事件。 事件驱动架构模式包含了两种主要的拓扑结构: 中介 (mediator)拓扑结构和 代理 (broker)拓扑结构。 mediator 拓扑结构通常在你需要在事件内使⽤⼀个核⼼中介分配、协调多个步骤间的关系、执⾏顺序时使 ⽤;⽽代理拓扑结构则在你想要不通过⼀个核⼼中介将多个事件串联在⼀起时使⽤。由于这两种结构在结构 特征和实现策略上有很⼤的差别,所以如果你想要在你的应⽤中使⽤它们的话,⼀定要深⼊理解两者的技术 实现细节,从⽽为你的实际使⽤场景选择最合理的结构。 中介拓扑结构适合⽤于拥有多个步骤,并需要在处理事件时能通过某种程度的协调将事件分层的场景,举例 来说吧:假设你现在需要进⾏股票交易,那你⾸先需要证券所批准你进⾏交易,然后检查进⾏这次交易是否 违反了股票交易的某种规定,检查完成后将它交给⼀个经纪⼈,计算佣⾦,最后与经纪⼈确认交易。以上所 有步骤都需要通过中介进⾏某种程度的分配和协调,以决定各个步骤的执⾏顺序,判断哪些步骤可以并⾏, 哪些步骤可以串⾏。 在中介拓扑结构中主要有四种组件:事件队列( event queue) , 事件中介 , 事件通道( event channel) , 和 事件处理器( event processor)。当事件流需要被处理,客户端将⼀个事件发送到某个事件队列中,由消息 队列将其运输给事件中介进⾏处理和分发。事件中介接收到该消息后,并通过将额外的异步事件发送给事件 通道,让事件通道执⾏该异步事件中的每⼀个步骤,使得事件中介能够对事件进⾏分配、协调。同时,⼜因 为事件处理器是事件通道的监听器,所以事件通道对异步事件的处理会触发事件处理器的监听事件,使事件 处理器能够接收来⾃事件中介的事件,执⾏事件中具体的业务逻辑,从⽽完成对传⼊事件的处理。事件驱动 架构模式中的中介拓扑模式结构⼤体如下图: 易开发性 第⼆章 事件驱动架构 中介 ( Mediator )拓扑结构 在事件驱动架构中拥有⼗⼏个,甚⾄⼏百个事件队列是很常⻅的情况,该模式并没有对事件队列的实现有明 确的要求,这就意味着事件队列可以是消息队列, Web 服务端,或者其它类似的东⻄。 在事件驱动架构模式中主要有两种事件:初始事件和待处理事件。初始事件是中介所接收到的最原始的事 件,没有经过其他组件的处理;⽽待处理事件是由事件中介⽣成,由事件处理器接收的组件,不能把待处理 事件看作初始事件经过处理后得到的事件,两者是完全不同的概念。 事件中介负责分配、协调初始事件中的各个待执⾏步骤,事件中介需要为每⼀个初始事件中的步骤发送⼀个 特定的待处理事件到事件通道中,触发事件处理器接收和处理该待处理事件。这⾥需要注意的是:事件 中介 没有真正参与到对初始事件必须处理的业务逻辑的实现之中;相反,事件中介只是知道初始事件中有哪些步 骤需要被处理。 事件中介通过事件通道将与初始事件每⼀个执⾏步骤相关联的特定待处理事件传递给事件处理器。尽管我们 通常在待处理事件能被多个事件处理器处理时才会在中介拓扑结构中使⽤ 消息主题,但事件通道仍可以是消 息队列或 消息主题。(但需要注意的是,尽管在使⽤ 消息主题 时待处理事件能被多个事件处理器处理,但 由于接收到的待处理事件各异,所以对其处理的操作也各不相同) 为了能顺利处理待处理事件,事件处理器组件中包含了应⽤的业务逻辑。此外,事件处理器作为事件驱动架 构中的组件,不依赖于其他组件,独⽴运作,⾼度解耦,在应⽤或系统中完成特定的任务。当事件处理器需 要处理的事件从细粒度(例如:计算订单的营业税)变为粗粒度(例如:处理⼀项保险索赔事务),必须要 注意的是:⼀般来说,每⼀个事件处理器组件都只完成⼀项唯⼀的业务⼯作,并且事件处理器在完成其特定 的业务⼯作时不能依赖其他事件处理器。 虽然事件中介有许多⽅法可以实现,但作为⼀名架构⼯程师,你应该了解所有实现⽅式,以确保你能为你的 实际需求选择了最合适的事件中介。 事件中介最简单、常⻅的实现就是使⽤开源框架,例如: Spring Integration, Apache Camel,或 Mule ESB。事件流在这些开源框架中通常⽤ Java 或 域特定语⾔( domain-specific language)。在调节过程和业 务流程都很复杂的使⽤场景下,你可以使⽤业务流程执⾏语⾔( BPEL - business process execution language)结合类似开源框架 Apache ODE 的 BPEL 引擎进⾏开发。 BPEL 是⼀种基于 XML 的服务编制编 程语⾔,它为处理初始事件时需要描述的数据和步骤提供了描述。对每⼀个拥有复杂业务流程(包括与⽤户 交互的执⾏步骤)的⼤型应⽤来说,你可以使⽤类似 jBPM 的业务处理管理系统( business process manager)实现事件中介。 如果你需要使⽤中介拓扑结构,那么理解你的需求,并为其匹配恰当的事件中介实现是构建事件驱动架构过 程中⾄关重要的⼀环。使⽤开源框架去解决⾮常复杂的业务处理、管理、调节事件,注定会失败,因为开源 框架只是⽤ BPM 的⽅式解决了⼀些简单的事件分发逻辑,⽐起你的业务逻辑,其中的事件分发逻辑简直是 九⽜⼀⽑。 为了解释清楚中介拓扑结构是怎么运作的,我假设你在某家保险公司买了保险,成为了受保⼈,然后你打算 搬家。在这种情况下,初始事件就是重定位事件,或者其他类似的事件。与重定位事件相关的处理步骤就像 下图展⽰的那样,处于事件中介之中。对每⼀个初始事件的传⼊,事件中介都会创建⼀个待处理事件(例 如:改变地址,重新计算保险报价,等等 ……),并将它发送给事件通道,等待发出响应的事件处理器处理 待处理事件(例如:客户改变地址的操作流程、报价计算流程,等等 ……)。直到初始事件中的每⼀个需要 处理的步骤完成了,这项处理才会继续(例如:把所有⼿续都完成之后,保险公司才会帮你改变地址)。事 件中介中,重新报价和更新理赔步骤上⾯的直线表⽰这些步骤可以并⾏处理。 代理拓扑结构与中介拓扑结构不同之处在于:代理拓扑结构中没有核⼼的事件中介;相反,事件流在代理拓 扑结构中通过⼀个轻量的消息代理(例如: ActiveMQ, HornetQ,等等 ……)将消息串联成链状,分发⾄事 件处理器组件中进⾏处理。代理扑结构适⽤的使⽤场景⼤致上具有以下特征:你的事件处理流相对来说⽐较 简单,⽽且你不想(不需要)使⽤核⼼的事件分配、调节机制以提⾼你处理事件的效率。 在代理拓扑结构中主要包括两种组件:代理和事件处理器。代理可被集中或相互关联在⼀起使⽤,此外,代 理中还可以包含所有事件流中使⽤的事件通道。 存在于代理组件中的事件通道可以是消息队列,消息主题 ,或者是两者的组合。 代理拓扑结构⼤致如下图,如你所⻅,在这其中没有⼀个核⼼的事件中介组件控制和分发初始事件;相反, 每⼀个事件处理器只负责处理⼀个事件,并向外发送⼀个事件,以标明其刚刚执⾏的动作。例如,假设存在 ⼀个事件处理器⽤于平衡证券交易,那么事件处理器可能会接受⼀个拆分股票的初始事件,为了处理这项初 始事件,事件处理器则需要重新平衡股票的投资⾦额,⽽这个重新平衡的事件将由另⼀个事件处理器接收、 处理。在这其中有⼀个细节需要注意:处理初始事件后,由事件处理器发出的事件不被其他事件处理器接 收、处理的情况时常会发⽣,尤其是你在为应⽤添加功能和进⾏功能拓展时,这种情况更为常⻅。 代理 (Broker) 拓扑结构 为了阐明代理拓扑结构的运⾏机制,我会⽤⼀个与讲解中介拓扑结构时类似的例⼦(受保⼈旅⾏的例⼦)进 ⾏解释。因为在代理拓扑结构中没有核⼼事件中介接收初始事件,那么事件将由客户处理组件直接接收,改 变客户的地址,并发出⼀个事件告知系统客户的地址被其进⾏了改变(例如:改变地址的事件)。在这个例 ⼦中:有两个事件处理器会与改变地址的事件产⽣关联:报价处理和索赔处理。报价事件处理器将根据受保 ⼈的新地址重新计算保险的⾦额,并发出事件告知系统该受保⼈的保险⾦额被其改变。⽽索赔事件处理器将 接受到相同的改变地址事件,不同的是,它将更新保险的赔偿⾦额,并发出⼀个更新索赔⾦额事件告知系统 该受保⼈的赔偿⾦额被其改变。当这些新的事件被其他事件处理器接收、处理,使事件链⼀环扣⼀环地交由 系统处理,直到事件链上的所有事件都被处理完,初始事件的处理才算完成。 如上图所⽰,代理拓扑结构的设计思想就是将对事件流的处理转换为对事件链的业务功能处理,把代理拓扑 结构看作是接⼒⽐赛是最好的理解⽅式:在⼀场 4*100的接⼒⽐赛中,每⼀位运动员都需要拿着⼀根接⼒棒跑 100⽶,运动员跑完⾃⼰的 100⽶后需要将接⼒棒传递给下⼀位运动员,直到最后⼀位运动员拿着接⼒棒跑过 终点线,整场接⼒⽐赛才算结束。根据这样的逻辑我们还可以知道:在代理拓扑结构中,⼀旦某个事件处理 器将事件传递给另⼀个事件处理器,那么这个事件处理器不会与该事件的后续处理产⽣任何联系。 实现事件驱动架构模式相对于实现其他架构模式会更困难⼀些,因为它通过异步处理进⾏事件分发。当你需 要在你的应⽤中使⽤这种架构模式,你必须处理各种由事件分发处理带来的问题,例如:远程操作功能的可 ⽤性,缺少权限,以及在代理或中介中处理事件失败时,⽤于处理这种情况的重连逻辑。如果你不能很好地 解决这些问题,那你的应⽤⼀定会出现各种 Bug,让开发团队痛苦不已。 在选择事件驱动架构时还有⼀点需要注意:在处理单个业务逻辑时,这种架构模式不能处理细粒度的事务。 因为事件处理器都⾼度解耦、并且⼲泛分布,这使得在这些事件处理器中维持⼀个业务单元变得⾮常困难。 因此,当你使⽤这种架构模式架构你的应⽤时,你必须不断地考虑哪些事件能单独被处理,哪些不能,并为 此设计相应事件处理器的处理粒度。如果你发现你需要将⼀个业务单元切割成许多⼦单元,并⼀⼀匹配相应 的事件处理器,那你就要为此进⾏代码设计;如果你发现你⽤多个不同的事件处理器处理的哪些业务其实是 可以合并到⼀个业务事件之中的,那么这种模式可能并不适合你的应⽤,⼜或者是你的设计出了问题。 顾虑 使⽤事件驱动架构模式最困难的地⽅就在于架构的创建、维护、以及对事件处理器的管理。通常每⼀个事件 都拥有其指定的事件处理协议(例如:传递给事件处理器的数据类型、数据格式),这就使得设下标准的数 据格式成为使⽤事件驱动架构模式中⾄关重要的⼀环(例如: XML, JSON, Java 对象,等等 ……),并在 架构创建之初就为这些数据格式授权,以便处理。 下⾯是基于对常⻅的架构模式特征进⾏评价的标准,对事件驱动架构模式所作的实际分析,评价是以常⻅的 架构模式的相似实现作为标准进⾏的,如果你想知道进⾏对⽐的其他架构模式对应的特征,可以结尾处查看 附录 A 的汇总表。 评价:⾼ 分析:整体灵活性⽤于评价架构能否在不断改变的使⽤场景下快速响应,因为事件处理器组件使⽤⺫的单 ⼀、⾼度解耦、与其他事件处理器组件相互独⽴,不相关联,那么发⽣的改变对⼀个或多个事件处理器来说 普遍都是独⽴的,使得对改变的反馈⾮常迅速,不需要依赖其他事件处理器的响应作出处理。 评价:⾼ 分析:总的来看,事件驱动架构模式由于其⾼度解耦的事件处理器组件的存在,对事件的部署相对来说⽐较 容易,⽽使⽤代理拓扑结构⽐使⽤中介拓扑结构进⾏事件调度会更容易⼀些,主要是因为在 中介拓扑结构中 事件处理器与事件中介紧密地耦合在⼀起:事件处理器中发⽣改变后,事件中介也随之改变,如果我们需要 改变某个被处理的事件,那么我们需要同时调度事件处理器和事件中介。 评价:低 分析:虽然在事件驱动架构模式中进⾏单元测试并不困难,但如果我们要进⾏单元测试,我们就需要某种特 定的测试客户端或者是测试⼯具产⽣事件,为单元测试提供初始值。此外,由于事件驱动架构模式是异步进 ⾏事件分发的,其异步处理的特性也为单元测试带来了⼀定的困难。 评价:⾼ 分析:对消息传递的架构可能会让设计出来的事件驱动架构的表现不如我们的期望,但通常来说,该模式都 能通过其异步处理的特性展⽰优秀的性能表现;换句话来说,⾼度解耦,异步并⾏操作⼤⼤减少了传递消息 过程中带来的时间开销。 评价:⾼ 模式分析 整体灵活性 易于部署 可测试性 Performance 性能 伸缩性 分析:事件驱动架构中的⾼度解耦、相互独⽴的事件处理器组件的存在,使得可拓展性成为该架构与⽣俱来 的优点。架构的这些特定使得事件处理器能够进⾏细粒度的拓展,使得每⼀个事件处理器都能单独被拓展, ⽽不影响其他事件处理器。 评价:低 分析:由于使⽤事件驱动架构进⾏开发需要考虑其异步处理机制、协议创建流程,并且开发者需要⽤代码为 事件处理器和操作失败的代理提供优秀的错误控制环境,⽆疑使得⽤事件驱动架构进⾏开发会⽐使⽤其他架 构进⾏开发要困难⼀些。 读完整篇⽂章,我相信⼤家对 mediator 与 broker 这两个概念有⼀个⼤致的印象,但就两者的译⽂来看,中 介和代理似乎没什么区别,尤其是了解 proxy 的读者会更加困惑,这三者之间到底是什么关系?它们的概念 是互通的吗?为了解决这种混淆,译者将在此阐述三者间的区别: 假如现在我有⼀个事件 /事件流需要被处理,那么使⽤ mediator、 broker、 proxy 处理事件的区别在哪⾥呢? 如果我们使⽤ mediator,那就意味着我将把事件流交给 mediator, mediator 会帮我把事件分解为多个 步骤,并分析其中的执⾏逻辑,调整和分发事件(例如判断哪些事件可以并⾏,哪些事件可以串⾏), 然后根据 mediator 分解、调节的结果去执⾏事件中的每⼀个步骤,把所有步骤完成后,就能把需要处理 的事件处理好。 如果我们使⽤ broker,那就意味着我将把事件交给 broker, broker 获得事件后会把事件发出去(在本⽂ 中为:通知架构中所有可⽤的事件处理器),事件处理器们接收到事件以后,判断处理这个事件是否为 ⾃⼰的职责之⼀,如果不是则⽆视,与⾃⼰有关则把需要完成的⼯作完成,完成后如果事件还有后续需 要处理的事件,则通过 broker 再次发布,再由相关的事件处理器接收、处理。以这样的⽅式将事件不断 分解,沿着事件链⼀级⼀级地向下处理⼦事件,直到事件链中的所有事件被完成,我的事件也就处理好 了。 如果我们使⽤ proxy,那就意味着我⾃⼰对需要处理的事件进⾏了分解,然后把不同的⼦事件⼀⼀委托 给不同的 proxy,由被委托的 proxy 帮我完成⼦事件,从⽽完成我要做的事件。 微内核架构模式 (也称为插件化应⽤架构 )对于基于产品的应⽤程序来说是⼀个很⾃然的选择。基于产品的应 ⽤是指⼀个经过打包的、可以通过版本下载的⼀个典型的第三⽅产品。然⽽,很多公司也会开发和发布他们 的内部商业软件,完整的版本号、发布⽇志和可插拔的新特性,这些就⾮常符合微内核架构的思想。微内核 架构模式可以通过插件的形式添加额外的特性到核⼼系统中,这提供了很好的扩展性,也使得新特性与核⼼ 系统隔离开来。 ( 译者注 : ⽐如,著名的 Eclipse IDE就是基于插件化开发的, eclipse核⼼更像是⼀个微内核, 或者我们可把它叫做开放平台,其他的功能通过安装插件的形式添加到 eclipse中。 ) 易于开发 译者注 第三章 微内核架构 微内核架构主要需要考虑两个⽅⾯ : 核⼼系统和插件模块。应⽤逻辑被划分为独⽴的插件模块和核⼼系统,这 样就提供良好的可扩展性、灵活性,应⽤的新特性和⾃定义处理逻辑也会被隔离。图 3-1演⽰了基本的微内核 架构。 微内核架构的核⼼系统⼀般情况下只包含⼀个能够使系统运作起来的最⼩化模块。很多操作系统的实现就是 使⽤微内核架构,因此这也是该架构名字的由来。从商业应⽤的⾓度看,核⼼系统通常是为特定的使⽤场 景、规则、或者复杂条件处理定义了通⽤的业务逻辑,⽽插件模块根据这些规则实现了具体的业务逻辑。 插件模块是⼀个包含专业处理、额外特性的独⽴组件,⾃定义代码意味着增加或者扩展核⼼系统以达到产⽣ 附加的业务逻辑的能⼒。通常,插件模块之间应该是没有任何依赖性的,但是你也可以设计⼀个需要依赖另 ⼀个插件的插件。但⽆论如何,使得插件之间可以通信的同时避免插件之间产⽣依赖⼜是⼀个特别重要的问 题。 核⼼系统需要了解插件模块的可⽤性以及如何获取到它们。⼀个通⽤的实现⽅法是通过⼀组插件注册表。这 个插件注册表含有每个插件模块的信息,包括它的名字、数据规约和远程访问协议 (取决于插件如何与核⼼系 统建⽴连接 )。例如,⼀个税务软件的⽤于标识⾼⻛险的税务审计插件可能会有⼀个含有插件名 (⽐如 AuditChecker)的注册⼊⼝,数据规约 (输⼊数据、输出数据 )和规约格式 ( ⽐如 xml )。如果这个插件是通过 SOAP服务访问,那么它可能会包含⼀个 WSDL (Web Services Definition Language). 插件模块可以通过多种⽅式连接到核⼼系统,包括 OSGi ( open service gateway initiative )、消息机制、 web 服务或者直接点对点的绑定 ( ⽐如对象实例化,即依赖注⼊ )。你使⽤的连接类型取决于你构建的应⽤类型和 你的特殊需求(⽐如单机部署还是分布式部署)。微内核架构本⾝没有指定任何的实现⽅式,唯⼀的规定就 是插件模块之间不要产⽣依赖。 插件和核⼼系统的通信规范包含标准规范和⾃定义规范。⾃定义规范典型的使⽤场景是插件组件是被第三⽅ 构建的。在这种情况下,通常是在第三⽅插件规约和你的标准规范创建⼀个 Adapter来使核⼼系统根本不需要 知道每个插件的具体细节。当创建标准规范 ( 通常是通过 XML或者 Java Map )时,从⼀开始就创建⼀个版本 策略是⾮常重要的。 模式描述 也许微内核架构的最好⽰例就是⼤家熟知的 Eclipse IDE了。下载最基本的 Eclipse后,它只能提供⼀个编辑 器。然后,⼀旦你开始添加插件,它就变成⼀个⾼度可定制化和⾮常有⽤的产品(译者注 : 更多内容⼤家可 以参考 开源软件架构 卷 1:第 6章 Eclipse之⼀ )。浏览器是另⼀个使⽤微内核架构的产品⽰例,它由⼀个查 看器和其他扩展的插件组成。 基于微内核架构的⽰例数不胜数,但是⼤型的商业应⽤呢?微内核应⽤架构也适⽤于这些情形。为了阐述这 个观点,让我们来看看另⼀个保险公司的⽰例,但是这次的⽰例会涉及保险赔偿处理。 赔偿处理是⼀个⾮常复杂的过程。每个州都有不同的关于保险赔偿的规则和条⽂。例如⼀些州允许在你的挡 ⻛玻璃被⽯头砸碎时免费进⾏替换,但是⼀些州则不是这样。因为⼤家的标准都不⼀样,因此赔偿标准⼏乎 可以是⽆限的。 有很多保险赔偿应⽤运⽤⼤型和复杂的规则处理引擎来处理不同规则带来的复杂性。然⽽,可能会因为某条 规则的改变⽽引起其他规则的改变⽽使得这些规则处理引擎变成⼀个⼤泥球,或者使简单需求变更会需要⼀ 个很⼤的分析师、⼯程师、测试⼯程师来进⾏处理。使⽤微内核架构能够很好的解决这个问题,核⼼系统只 知道根据赔偿规则处理,但这个赔偿规则是抽象的,系统将赔偿规则作为⼀个插件规范,具体的规则有对应 的实现,然后注⼊到系统中即可。 图 3-2中的⼀堆⽂件夹代表了赔偿处理核⼼系统。它包含⼀些处理保险赔偿的基本业务逻辑。每⼀个插件模块 包含每个州的具体赔偿规则。在这个例⼦中,插件模块通过⾃定义源代码实现或者分离规则引起实例。不管 具体实现如何,关键就在于赔偿规则和处理都从核⼼系统中分离,⽽这些规则和处理过程都可以被动态地添 加、移除,⽽这些改变对于核⼼系统和其他插件只有很⼩的影响或者根本不产⽣影响。 对于微内核架构来说⼀个很重要的⼀点就是它能够被嵌⼊或者说作为另⼀种架构的⼀部分。例如,如果这个 架构解决的是⼀个你应⽤中易变领域的特定的问题 ( 译者注 : 即插件化能够解决你应⽤中的某个特定模块的 架构问题 ),你可能会发现你不能在整个应⽤中使⽤这种架构。在这种情况下,你可以将微内核架构嵌⼊到另 ⼀个架构模式中 ( ⽐如分层架构 )。同样的,在上⼀章节中描述的事件驱动架构中的事件处理器组件也可以使 ⽤微内核架构。 架构⽰例 注意事项 微内核架构对渐进式设计和增量开发提供了⾮常好的⽀持。你可以先构建⼀个单纯的核⼼系统,随着应⽤的 演进,系统会逐渐添加越来越多的特性和功能,⽽这并不会引起核⼼系统的重⼤变化。 对基于产品的应⽤来说,微内核架构应该是你的第⼀选择。特别是那些你会在后续开发中发布附加特性和控 制哪些⽤户能够获取哪些特性的应⽤。如果你在后续开发中发现这个架构不能满⾜你的需求了,你能够根据 你的特殊需求将你的应⽤重构为另⼀个更好的架构。 下⾯的表格中包含了微内核架构每个特性的评级和分析。以微内核架构的最经典的实现⽅式的⾃然趋势为依 据对每个特性进⾏评级。关于微内核架构与其他模式的相关性⽐较请参考附录 A。 评级 : ⾼ 分析 : 整体灵活性是指能够快速适应不断变化的环境的能⼒。通过插件模块的松耦合实现,可以将变化隔离 起来,并且快速满⾜需求。通常,微内核架构的核⼼系统很快趋于稳定,这样系统就变得很健壮,随着时间 的推移它也不会发⽣多⼤改变。 评级 : ⾼ 分析 : 根据实现⽅式,插件模块能够在运⾏时被动态地添加到核⼼系统中 ( ⽐如,热部署 ) ,把停机时间减 到最⼩。 评级 : ⾼ 分析 : 插件模块能够被独⽴的测试,能够⾮常简单地被核⼼系统模拟出来进⾏演⽰,或者在对核⼼系统很⼩ 影响甚⾄没有影响的情况下对⼀个特定的特性进⾏原型展⽰。 评级 : ⾼ 分析 : 使⽤微内核架构不会⾃然⽽然地使你的应⽤变得⾼性能。通常,很多使⽤微内核架构的应⽤运⾏得很 好,因为你能定制和简化应⽤程序,使它只包含那些你需要的功能模块。 JBoss应⽤服务器就是这⽅⾯的优 秀⽰例 : 依赖于它的插件化架构,你可以只加载你需要的功能模块,移除那些消耗资源但没有使⽤的功能特 性,⽐如远程访问,消息传递,消耗内存、 CPU的缓存,以及线程,从⽽减⼩应⽤服务器的资源消耗。 评级 : 低 分析 : 因为微内核架构的实现是基于产品的,它通常都⽐较⼩。它们以独⽴单元的形式实现,因此没有太⾼ 模式分析 整体灵活性 易于部署 可测试性 性能 伸缩性 的伸缩性。此时,伸缩性就取决于你的插件模块,有时你可以在插件级别上提供可伸缩性,但是总的来说这 个架构并不是以构建⾼度伸缩性的应⽤⽽著称的。 评级 : 低 分析 : 微内核架构需要考虑设计和规约管理,使它不会很难实现。规约的版本控制,内部的插件注册,插件 粒度,丰富的插件连接的⽅式等是涉及到这个架构模式实现复杂度的重要因素。 微服务架构模式作为替代单体应⽤和⾯向服务架构的⼀个可⾏的选择,在业内迅速取得进展。由于这个架构 模式仍然在不断的发展中,在业界存在很多困惑 ——这种模式是关于什么的?它是如何实现的?本报告的这 部分将为你提供关键概念和必要的基础知识来理解这⼀重要架构模式的好处 (和取舍 ),以此来判断这种架构 是否适合你的应⽤。 不管你选择哪种拓扑或实现⻛格 ,有⼏种常⻅的核⼼概念适⽤于⼀般架构模式。第⼀个概念是 单独部署单元 。 如图 4-1所⽰,微服务架构的每个组件都作为⼀个独⽴单元进⾏部署,让每个单元可以通过有效、简化的传输 管道进⾏通信,同时它还有很强的扩展性,应⽤和组件之间⾼度解耦,使得部署更为简单。 也许要理解这种模式,最重要的概念就是服务组件( service component)。不要考虑微服务架构内部的服 务,⽽最好是考虑服务组件,从粒度上讲它可以⼩到单⼀的模块,或者⼤⾄⼀个应⽤程序。服务组件包含⼀ 个或多个模块(如 Java类),这些模块可以提供⼀个单⼀功能(如,为特定的城市或城镇提供天⽓情况), 或也可以作为⼀个⼤型商业应⽤的⼀个独⽴部分(如,股票交易布局或测定汽⻋保险的费率)。在微服务架 构中,正确设计服务组件的粒度是⼀个很⼤的挑战。在接下来的服务组件部分对这⼀挑战进⾏了详细的讨 论。 易于开发 第四章 微服务架构 模式描述 微服务架构模式的另⼀个关键概念是它是⼀个 分布式 的架构,这意味着架构内部的所有组件之间是完全解耦 的,并通过某种远程访问协议(如, JMS, AMQP, REST, SOAP, RMI等)进⾏访问。这种架构的分布式特性 是它实现⼀些优越的可扩展性和部署特性的关键所在。 微服务架构另⼀个令⼈兴奋的特性是它是由其他常⻅架构模式存在的问题演化来的,⽽不是作为⼀个解决⽅ 案被创造出来等待问题出现。微服务架构的演化有两个主要来源:使⽤分层架构模式的单体应⽤和使⽤⾯向 服务架构的分布式应⽤。 由单体应⽤ ( ⼀个应⽤就是⼀个整体 )到微服务的发展过程主要是由持续交付开发促成的。从开发到⽣产的持 续部署管道概念 ,简化了应⽤程序的部署。单体应⽤通常是由紧耦合的组件组成,这些组件同时⼜是另⼀个单 ⼀可部署单元的⼀部分,这使得它繁琐,难以改变、测试和部署应⽤(因此常⻅的 “⽉度部署 ”周期出现并通 常发⽣在⼤型 IT商店项⺫)。这些因素通常会导致应⽤变得脆弱以⾄于每次有⼀点新功能部署后应⽤就不能 运⾏。微服务架构模式通过将应⽤分隔成多个可部署的单元(服务组件)的⽅法来解决这⼀问题,这些服务 组件可以独⽴于其他服务组件进⾏单独开发、测试和部署。 另⼀个导致微服务架构模式产⽣的演化过程是由⾯向服务架构模式( SOA)应⽤程序存在的问题引起的。虽 然 SOA模式⾮常强⼤,提供了⽆与伦⽐的抽象级别、异构连接、服务编排,并保证通过 IT能⼒调整业务⺫ 标,但它仍然是复杂的 ,昂贵的 ,普遍存在,它很难理解和实现,对⼤多数应⽤程序来说过犹不及。微服务架构 通过简化服务概念,消除编排需求、简化服务组件连接和访问来解决复杂度问题。 虽然有很多⽅法来实现微服务架构模式 ,但三个主要的拓扑结构脱颖⽽出,最常⻅和流⾏的有 :基于 REST API 的拓扑结构 ,基于 REST的应⽤拓扑结构和集中式消息拓扑结构。 基于 REST的 API拓扑适⽤于⺴站,通过某些 API对外提供⼩型的、⾃包含的服务。这种拓扑结构 ,如图 4 - 2所 模式拓扑 ⽰ ,由粒度⾮常细的服务组件(因此得名微服务)组成,这些服务组件包含⼀个或两个模块并独⽴于其他服务 来执⾏特定业务功能。在这种拓结构扑中 ,这些细粒度的服务组件通常被 REST-based的接⼝访问,⽽这个接 ⼝是通过⼀个单独部署的 web API层实现的。此种拓扑的例⼦包含⼀些常⻅的专⽤的、基于云的 RESTful web service,⼤型⺴站像 Yahoo, Google, and Amazon都在使⽤。 基于 REST的应⽤拓扑结构与基于 REST API的不同,它通过传统的基于 web的或胖客户端业务应⽤来接收客 户端请求,⽽不是通过⼀个简单的 API层。如图 4-3所⽰,应⽤的⽤户接⼝层( user interface layer)是⼀个 web应⽤,可以通过简单的 REST-based接⼝访问单独部署的服务组件(业务功能)。该拓扑结构中的服务组 件与 API-REST-based拓扑结构中的不同,这些服务组件往往会更⼤、粒度更粗、代表整个业务应⽤程序的⼀ ⼩部分,⽽不是细粒度的、单⼀操作的服务。这种拓扑结构常⻅于中⼩型企业等复程度相对较低的应⽤程 序。 微服务架构模式中另⼀个常⻅的⽅法是集中式消息拓扑。该拓扑(如图 4-4所⽰)与前⾯提到的基于 REST的 应⽤拓扑类似,不同的是, application REST- based拓扑结构使⽤ REST进⾏远程访问,⽽该拓扑结构则使 ⽤⼀个轻量级的集中式消息代理(如, ActiveMQ, HornetQ等等)。不要将该拓扑与⾯向服务架构模式混淆 或将其当做 SOA简化版( “SOA-Lite”),这点是极其重要的。该拓扑中的轻量级消息代理( Lightweight Message Broker)不执⾏任何编排 ,转换 ,或复杂的路由 ;相反 ,它只是⼀个轻量级访问远程服务组件的传输⼯ 具。 集中式消息拓扑结构通常应⽤在较⼤的业务应⽤程序中,或对于某些对传输层到⽤户接⼝层或者到服务组件 层有较复杂的控制逻辑的应⽤程序中。该拓扑较之先前讨论的简单基于 REST的拓扑结构,其好处是有先进 的排队机制、异步消息传递、监控、错误处理和更好的负载均衡和可扩展性。与集中式代理相关的单点故障 和架构瓶颈问题已通过代理集群和代理联盟(将⼀个代理实例为分多个代理实例,把基于系统功能区域的吞 吐量负载划分开处理)解决。 微服务架构模式的主要挑战之⼀就是决定服务组件的粒度级别。如果服务组件粒度过粗,那你可能不会意识 到这个架构模式带来的好处(部署、可扩展性、可测试性和松耦合),然⽽ ,服务组件粒度过细将导致服务编 制要求 ,这会很快导致将微服务架构模式变成⼀个复杂、容易混淆、代价昂贵并易于出错的重量级⾯向服务架 构。 如果你发现需要从应⽤内部的⽤户接⼝或 API层编排服务组件,那么很有可能你服务组件的粒度太细了。如果 你发现你需要在服务组件之间执⾏服务间通信来处理单个请求 ,那么很有可能要么是你服务组件的粒度太细 了,要么是没有从业务功能⾓度正确划分服务组件。 服务间通信,可能导致组件之间产⽣耦合,但可以通过共享数据库进⾏处理。例如,若⼀个服务组件处理⺴ 络订单⽽需要⽤户信息时,它可以去数据库检索必要的数据,⽽不是调⽤客户服务组件的功能。 共享数据库可以处理信息需求,但是共享功能呢?如果⼀个服务组件需要的功能包含在另⼀个服务组件内, 或是⼀个公共的功能 ,那么有时你可以将服务组件的共享功能复制⼀份(因此违反了 DRY规则: don’t repeat yourself)。为了保持服务组件独⽴和部署分离,微服务架构模式实现中会存在⼀⼩部分由重复的业务逻辑⽽ 造成的冗余,这在⼤多数业务应⽤程序中是⼀个相当常⻅的问题。⼩⼯具类可能属于这⼀类重复的代码。 如果你发现就算不考虑服务组件粒度的级别,你仍不能避免服务组件编排 ,这是⼀个好迹象 ,可能此架构模式不 适⽤于你的应⽤。由于这种模式的分布式特性,很难维护服务组件之间的单⼀⼯作事务单元。这种做法需要 某种事务补偿框架回滚事务 ,这对此相对简单⽽优雅的架构模式来说,显著增加了复杂性。 避免依赖和编排 微服务架构模式解决了很多单体应⽤和⾯向服务架构应⽤存在的问题。由于主要应⽤组件被分成更⼩的 ,单独 部署单元 ,使⽤微服务架构模式构建的应⽤程序通常更健壮 ,并提供更好的可扩展性 ,⽀持持续交付也更容易。 该模式的另⼀个优点是 ,它提供了实时⽣产部署能⼒,从⽽⼤⼤减少了传统的⽉度或周末 “⼤爆炸 ”⽣产部署的 需求。因为变化通常被隔离成特定的服务组件,只有变化的服务组件才需要部署。如果你的服务组件只有⼀ 个实例,你可以在⽤户界⾯程序编写专⻔的代码⽤于检测⼀个活跃的热部署 ,⼀旦检测到就将⽤户重定向到⼀ 个错误⻚⾯或等待⻚⾯。你也可以在实时部署期间,将服务组件的多个实例进⾏交换,允许应⽤程序在部署 期间保持持续可⽤性(分层架构模式很难做到这点)。 最后⼀个要重视的考虑是,由于微服务架构模式是分布式的架构,他与事件驱动架构模式具有⼀些共同的复 杂的问题,包括约定的创建、维护,和管理,远程系统的可⽤性,远程访问⾝份验证和授权。 下⾯这个表中包含了微服务架构模式的特点分析和评级,每个特性的评级是基于⾃然趋势,基于典型模式实 现的能⼒特性 ,以及该模式是以什么闻名的。本报告中该模式与其他模式的并排⽐较,请参考报告最后的附件 A。 评级:⾼ 分析:整体的灵活性是能够快速响应不断变化的环境。由于单独部署单元的概念 ,变化通常被隔离成单独的服 务组件 ,使得部署变得快⽽简单。同时,使⽤这种模式构建的应⽤往往是松耦合的,也有助于促进改变。 评级:⾼ 分析:整体来讲,由于该模式的解耦特性和事件处理组件使得部署变得相对简单。 broker拓扑往往⽐ mediator拓扑更易于部署,主要是因为 event-mediator组件与事件处理器是紧耦合的,事件处理器组件有⼀个 变化可能导致 event mediator跟着变化,有任何变化两者都需要部署。 评级:⾼ 分析:由于业务功能被分离成独⽴的应⽤模块 ,可以在局部范围内进⾏测试,这样测试⼯作就更有针对性。对 ⼀个特定的服务组件进⾏回归测试⽐对整个单体应⽤程序进⾏回归测试更简单、更可⾏。⽽且 ,由于这种模式 的服务组件是松散耦合的,从开发⾓度来看,由⼀个变化导致应⽤其他部分也跟着变化的⼏率很⼩,并能减 ⼩由于⼀个微⼩的变化⽽不得不对整个应⽤程序进⾏测试的负担。 评级:低 注意事项 模式分析 整体灵活性 易于部署 可测试性 性能 分析:虽然你可以从实现该模式来创建应⽤程序并可以很好的运⾏,整体来说,由于微服务架构模式的分布 式特性,并不适⽤于⾼性能的应⽤程序。 评级:⾼ 分析:由于应⽤程序被分为单独的部署单元 ,每个服务组件可以单独扩展,并允许对应⽤程序进⾏扩展调整。 例如,股票交易的管理员功能区域可能不需要扩展,因为使⽤该功能的⽤户很少,但是交易布局服务组件可 能需要扩展,因为⼤多数交易应⽤程序需要具备处理⾼吞吐量的功能。 评级:⾼ 分析:由于功能被分隔成不同的服务组件,由于开发范围更⼩且被隔离,开发变得更简单。程序员在⼀个服 务组件做出⼀个变化影响其他服务组件的⼏率是很⼩的,从⽽减少开发⼈员或开发团队之间的协调。 ⼤多数基于⺴站的商务应⽤都遵循相同的请求流程:⼀个请求从浏览器发到 web服务器,然后到应⽤服务 器,然后到数据库服务器。虽然这个模式在⽤户数不⼤的时候⼯作良好,但随着⽤户负载的增加 ,瓶颈会开始 出现,⾸先出现在 web服务器层,然后应⽤服务器层,最后数据库服务器层。通常的解决办法就是 向外扩 展 ,也就是增加服务器数量。这个⽅法相对来说简单和廉价,并能够解决问题。然⽽,对于⼤多数⾼访问量 的情况,它只不过是把 web服务器的问题移到了应⽤服务器。⽽扩展应⽤服务器会更复杂,⽽且成本更⾼, 并且⼜只是把问题移动到了数据库服务器,那会更复杂,更贵。就算你能扩展数据库服务器,你最终会陷⼊ ⼀个⾦字塔式的情形,在⾦字塔最下⾯是 web服务器,它会出现最多的问题,但也最好伸缩。⾦字塔顶部是 数据库服务器,问题不多,但最难伸缩。 在⼀个⾼并发⼤容量的应⽤中,数据库通常是决定应⽤能够⽀持多少⽤户同时在线的关键因素。虽然各种缓 存技术和数据库伸缩产品都在帮助解决这个问题,但数据库难以伸缩的现实并没有改变。 基于空间的架构模型是专⻔为了 解决伸缩性和并发问题 ⽽设计的。它对于⽤户数量不可预测且数量级经常变 化的情况同样适⽤。在架构级别来解决这个伸缩性问题通常是⽐增加服务器数量或者提⾼缓存技术更好的解 决办法。 基于空间的模型(有时也称为云架构模型)旨在减少限制应⽤伸缩的因素。模型的名字来源于分布式共享内 存中的 tuple space(数组空间)概念。⾼伸缩性是通过去除中⼼数据库的限制,并使⽤从内存中复制的数据 框架来获得的。保存在内存的应⽤数据被复制给所有运⾏的进程。进程可以动态的随着⽤户数量增减⽽启动 或结束,以此来解决伸缩性问题。这样因为没有了中⼼数据库,数据库瓶颈就此解决,此后可以近乎⽆限制 的扩展了。 ⼤多数使⽤这个模型的应⽤都是标准的⺴站,它们接受来⾃浏览器的请求并进⾏相关操作。竞价拍卖⺴站是 伸缩性 易于开发 第五章 基于空间的架构 模型介绍 ⼀个很好的例⼦ ( 12306更是⼀个典型的⽰例 )。⺴站不停的接受来⾃浏览器的报价。应⽤收到对某⼀商品的 报价,记录下报价和时间,并且更新对该商品的报价,将信息返回给浏览器。 这个架构中有两个主要的模块: 处理单元 和 虚拟化中间件 。下图展⽰了这个架构和⾥⾯的主要模块。 处理单元包含了应⽤模块(或者部分的应⽤模块)。具体来说就是包含了 web组件以及后台业务逻辑。处理 单元的内容根据应⽤的类型⽽异 ——⼩型的 web应⽤可能会部署到单⼀的处理单元,⽽⼤型⼀些的应⽤会将 应⽤的不同功能模块部署到不同的处理单元中。典型的处理单元包括应⽤模块,以及保存在内存的数据框架 和为应⽤失败时准备的异步数据持久化模块。它还包括复制引擎,使得虚拟化中间件可以将处理单元修改的 数据复制到其他活动的处理单元。 虚拟化中间件负责保护⾃⾝以及通信。它包含⽤于数据同步和处理请求的模块,以及通信框架,数据框架, 处理框架和部署管理器。这些在下⽂中即将介绍的部分,可以⾃定义编写或者购买第三⽅产品来实现。 基于空间的架构的魔⼒就在虚拟化中间件,以及各个处理单元中的内存中数据框架。下图展⽰了包含着应⽤ 模块、内存中数据框架、处理异步数据恢复的组件和复制引擎的处理单元架构。 虚拟化中间件本质上是架构的控制器,它管理请求,会话,数据复制,分布式的请求处理和处理单元的部 署。虚拟化中间件有四个架构组件:通信框架,数据框架,处理框架和部署管理器。 组件间合作 通信框架管理输⼊请求和会话信息。当有请求进⼊虚拟化中间件,通信框架就决定有哪个处理单元可⽤,并 将请求传递给这个处理单元。通信框架的复杂程度可以从简单的 round robin算法到更复杂的⽤于监控哪个请 求正在被哪个处理单元处理的 next-available算法。 通信框架 数据框架可能是这个架构中最重要和关键的组件。它与各个处理单元的数据复制引擎交互,在数据更新时来 管理数据复制功能。由于通信框架可以将请求传递给任何可⽤的处理单元,所以每个处理单元包含完全⼀样 的内存中数据就很关键。下图展⽰处理单元间如何同步数据复制,实际中是通过⾮常迅速的并⾏的异步复制 来完成的,通常在微秒级。 处理框架,就像下图所⽰,是虚拟化中间件中⼀个可选组件,负责管理在有多个处理单元时的分布式请求处 理,每个处理单元可能只负责应⽤中的某个特定功能。如果请求需要处理单元间合作(⽐如,⼀个订单处理 单元和顾客处理单元),此时处理框架就充当处理单元⻅数据传递的媒介。 数据框架 处理框架 部署管理器根据负载情况管理处理单元的动态启动和关闭。它持续检测请求所需时间和在线⽤户量,在负载 增加时启动新的处理单元,在负载下降时关闭处理单元。它是实现可变伸缩性需求的关键。 基于空间的架构是⼀个复杂和实现起来相对昂贵的框架。对于有可变伸缩性需求的⼩型 web应⽤是很好的选 择,然⽽,对于拥有⼤量数据操作的传统⼤规模关系型数据库应⽤,并不那么适⽤。 虽然基于空间的架构模型不需要集中式的数据储存,但通常还是需要这样⼀个,来进⾏初始化内存中数据框 架,和异步的更新各处理单元的数据。通常也会创建⼀个单独的分区,来从隔离常⽤的断电就消失的数据和 不常⽤的数据,这样减少处理单元之间对对⽅内存数据的依赖。 值得注意的是,虽然这个架构的另⼀个名字是云架构,处理单元(以及虚拟化中间件)都没有放在云端服务 或者 PaaS上。他们同样可以简单的放在本地服务器,这也是为什么我更倾向叫它 “基于空间的架构 ”。 从产品实现的⾓度讲,这个架构中的很多组件都可以从第三⽅获得,⽐如 GemFire, JavaSpaces, GigaSpaces, IBM Object Grid, nCache,和 Oracle Coherence。由于架构的实现根据⼯程的预算和需求⽽ 异,所以作为架构师,你应该在实现或选购第三⽅产品前⾸先明确你的⺫标和需求。 部署管理器 其他考虑 架构分析 下⾯的表格是这个架构的特征分析和评分。每个特征的评分是基于⼀个典型的架构实现来给出的。要知道这 个模式相对别的模式的对⽐,请参⻅最后的附录 A。 评分:⾼ 分析:综合能⼒是对环境变化做出快速反应的能⼒。因为处理单元(应⽤的部署实例)可以快速的启动和关 闭,整个应⽤可以根据⽤户量和负载做出反应。使⽤这个架构通常在应对代码变化上,由于较⼩的应⽤规模 和组件间相互依赖,也会反映良好。 评分:⾼ 分析:虽然基于空间的架构通常没有解耦合并且功能分布,但他们是动态的,也是成熟的基于云的⼯具,允 许应⽤轻松的部署到服务器。 评分:低 分析:测试⾼⽤户负载既昂贵⼜耗时,所以在测试架构的可伸缩性⽅⾯很困难 评分:⾼ 分析:通过内存中数据存取和架构中的缓存机制可获得⾼性能 评分:⾼ 分析:⾼伸缩性是源于⼏乎不依赖集中式的数据库,从⽽去除了这个限制伸缩性的瓶颈。 评分:低 分析:主要是因为难以熟悉这个架构开发所需得⼯具和第三⽅产品,因此使⽤该架构需要较⼤的学习成本。 ⽽且,开发过程中还需要特别注意不要影响到性能和可伸缩性。 图 A-1 总结了在这个报告中,对于架构模式的每部分进⾏的模式分析所产⽣的影响。这个总结帮助你确定哪 些模式可能是最适合你的情况。例如 ,如果你的架构模式重点是可伸缩性,你可以在这个图表看看事件驱动模 综合能⼒ 易于部署 可测试性 性能 伸缩性 易于开发 附录 A 模式分析总结 式 ,microservices模式 ,和基于空间模式,这些对于你来说可能是很好的架构模式的选择。同样的 ,如果你的程 序注重的是分层架构模式 ,你可以参考图看到部署、性能和可伸缩性的在你的架构中所存在的⻛险。 同时这个图表将指导你选择正确的模式 ,因为在选择⼀种架构模式的时候,有更多的因素需要考虑。你必须分 析你的环境的各个⽅⾯ ,包括基础设施的⽀持 ,开发⼈员技能 ,项⺫预算 ,项⺫最后期限 ,和应⽤程序⼤⼩等等。选 择正确的架构模式是⾄关重要的 ,因为⼀旦⼀个架构被确定就很难改变。 Mark•Richards是⼀位有丰富经验的软件架构师,他参与架构、设计和实施 microservices体系结构、⾯向服务 的体系结构和在 J2EE中的分布式系统和其他技术。⾃ 1983年以来,他⼀直从事软件⾏业 ,在应⽤、继承和企 业架构⽅⾯有⼤量的经验和专业知识。 Mark在 1999到 2003年间担任新英格兰 Java⽤户组的主席。他是许多技术书籍和视频的作者 ,包括软件架构基 础 (O‘Reilly视频 )、企业消息传递 (O'Reilly视频 ),《 Java消息服务,第⼆版》 (O'Reilly)和《软件架构师应该知 道的 97件事》 (O'Reilly)的特约作者。 Mark拥有⼀个计算机科学硕⼠学位并且多次获得 IBM、 Sun、开放集团 和 BEA等颁发的架构师和开发⼈员认证。 他是 Fluff Just Stuff(NFJS)研讨会系列(⼀个不定期会议)议⻓ ,并且有过上百次的在世界各地公益会议和⽤ 户组上围绕技术主题的演讲经验 )。 Mark不⼯作的时候经常会到⽩⾊⼭脉或阿帕拉契⼭径徒步旅⾏。 关于作者
还剩30页未读

继续阅读

下载pdf到电脑,查找使用更方便

pdf的实际排版效果,会与网站的显示效果略有不同!!

需要 8 金币 [ 分享pdf获得金币 ] 1 人已下载

下载pdf

pdf贡献者

likeo

贡献于2015-04-21

下载需要 8 金币 [金币充值 ]
亲,您也可以通过 分享原创pdf 来获得金币奖励!
下载pdf