可扩展的Web架构观点与设计【英皇体育】

 体验式活动     |      2021-08-22 01:36
本文摘要:Figure 1: Example of a scalable web app design. Source: erwindev 对于每个Web应用法式而言,决议其乐成的基本因素之一是其能否凭据客户的要求无缝有效地适应增长或扩展的能力。可扩展的Web应用法式是一个网站,它能够处置惩罚用户和负载的增加(无论是逐渐增加还是突然增加),而不会中断最终用户的运动。在当今世界,客户对设计欠佳的应用法式的耐心和同情心有限。没有等候网页加载,上传图像或处置惩罚表单的观点。

英皇体育

> Figure 1: Example of a scalable web app design. Source: erwindev 对于每个Web应用法式而言,决议其乐成的基本因素之一是其能否凭据客户的要求无缝有效地适应增长或"扩展"的能力。可扩展的Web应用法式是一个网站,它能够处置惩罚用户和负载的增加(无论是逐渐增加还是突然增加),而不会中断最终用户的运动。在当今世界,客户对设计欠佳的应用法式的耐心和同情心有限。没有等候网页加载,上传图像或处置惩罚表单的观点。

如果您的应用法式设计不妥,而且能够实时处置惩罚请求,那么它一定会被遗弃。在本文中,我将引导您完成一些可扩展Web应用法式的体系结构设计。通过详细先容每个体系结构的每个角落来使博客变得冗长是不理想的,我想充当缓解者,我将尽我所能来简要地和说明性地解释焦点观点,并指导您 一些良好的资源,可供进一步阅读和研究。

该博客的内容将组织如下:· 整体架构· 通过微服务架构扩展· 带走· 下一步是什么?· 参考文献构建和运行可扩展的网站或应用法式到底意味着什么? 在原始级别上,它只是通过Internet将用户与远程资源毗连起来-使它具有可伸缩性的部门是资源或对这些资源的会见漫衍在多个服务器上,这使得设计大型Web系统容易堕落而且 有问题的。那么,为什么需要结实和可扩展的Web体系结构? 在其降生之前,Web应用法式是如何构建的?一,整体架构"整体"一词的意思是"一块大石头",因此当我们谈论整体时,我们转达的是大型统一块的想法。

在软件体系结构中,单片应用法式是一个独立的,单层的传统软件应用法式,它在单个代码库中包罗整个应用法式代码。这是此架构的说明:> Figure 2: Monolithic architecture. Source: Image Source 从图2中可以看到,应用法式的所有层和组件都精密毗连。

接纳这种架构的应用法式易于开发,测试,部署和治理,因为所有内容都驻留在一个存储库中。将差别的组件捆绑到一个统一的事情空间中并没有庞大性。如果所需资源稀少而且需要处置惩罚的请求数量很少,那么单片应用法式可能会乐成,可是越来越多的人对它们感应沮丧,尤其是当其精密捆绑的属性带来一些主要缺点时,需要重新扩展应用法式以扩展盘算能力:· 当层中的次要代码更改需要重新部署整个应用法式时,一连集成/一连部署(CI / CD)会很贫苦。

· 当组件被分组到一个代码库中时,单片应用法式就会泛起单点故障。万一任何层都有错误,则有可能破坏整个应用法式。

· 灵活性和可伸缩性也是整体应用法式中的挑战,因为更改一层通常需要对所有其他层举行修改和测试。随着代码巨细的增加,治理起来可能会有些棘手。

· 由于使用差别的技术实现差别的组件可能会使跨组件集成面临兼容性问题,因此使用单片式体系结构构建庞大的应用法式限制了技术的使用。这些挫折导致了可扩展性和结实性大大提高的体系结构的降生,我们将在以下各节中举行深入探讨。二。

通过微服务架构扩展与单片架构相反,微服务架构是将服务划分为多个松散耦合在一起的单独模块的应用法式结构,它们通过轻量级机制(通常是HTTP资源API,WebSocket或AMQP)相互通信。松散耦合意味着每个服务在特定上下文界限内实现特定的端到端域或业务功效,而且每个服务必须自主开发并独立部署。每个服务应独立于大型应用法式而拥有其相关的域数据模型和域逻辑(主权和疏散数据治理)。

纵然没有正式界说微服务架构样式,也有一些配合的特征,所有遵循该架构的应用法式都应展现出可扩展性。这些特征包罗智能端点和哑管道,疏散式治理,基础架构自动化和故障隔离。让我们在以下部门中讨论每个特征。1.集成模式:智能端点和哑管道当微服务应用法式将其结构拆分为松散耦合的多个组件时,自然要问的问题是:成对组件在哪些协议中举行通信? 在给定协议的情况下,应以哪种模式在整个应用法式中路由数据?a。

通讯协议在差别流程之间建设通信结构时,有许多产物和方法强调要在通信机制自己中投入大量精神。一个很好的例子就是企业服务总线(ESB),其中ESP产物通常包罗用于消息路由,编排,转换和应用业务规则的庞大工具。

(ESB也是微服务和面向服务的体系结构(SOA)之间的基础区别。两者之间的进一步比力可以在[2]中找到)。

相反,微服务倾向于一种替代方法:"智能端点和哑管道"。微服务应用法式的目的是尽可能地淘汰耦合和凝聚力-它们拥有自己的域逻辑,在传统的Unix意义上更像是过滤器-吸收请求,适当地应用逻辑并发生响应,这通常使用两种常见的方法举行编排 通讯形式:请求-响应和视察者。在请求-响应通信模式中,微服务使用结构万维网的原理:一个服务通过发出显式请求来挪用另一服务,通常是存储或检索数据。

然后,该服务期待一个响应,无论是资源还是确认。实施此模式的最基本方法是使用HTTP,最好遵循REST原则。两个服务之间基于尺度HTTP的通信管道通常如下所示:> Figure 3: HTTP communication protocol in Microservices. Source: [1] 图3显示了服务之间的HTTP通信协议的简朴抽象。负载平衡器可用作中间件层,以将请求路由到支持服务的实例之一。

只管REST设计模式很是普遍而且广为人知,但它具有同步性和阻塞性的局限性。异步可以使用第二个协议范式,即视察者模型来实现。

在微服务中,更确切地说是应该是公布/订阅模式,而不是视察者模型(可以在[3]处分析两者之间的差异)。公布/订阅模式是一种基于事件的隐式挪用,其中生产服务(公布者)公布一个事件,监视该事件的一个或多个消费者服务(订阅者)通过异步运行逻辑来响应该事件,而公布者对此并不相识。

事件。订户可以通过使用RabbitMQ,ZeroMQ,Kafka或Redis公布/订阅订阅消息行列/署理服务(因此引用中的哑管道)来确认事件的发生。可以在[4]处更仔细地相识通信协议。现在,让我们讨论在整个应用法式中路由/收集数据以实现无缝服务集成的模式。

b。聚合模式在微服务领域,Aggregator是指一个基本的网页,该网页挪用种种服务以获取所需的信息或实现所需的功效。在需要通过组合来自多个服务的数据举行输出的情况下,此模式很是有用。例如,假设我们有一个滴允许用法式,该应用法式用于检察详细信息并为体育,影戏和其他运动等种种运动预订门票。

假设每个运动都由一个服务来治理,如图所示:> Figure 4: Using Aggregation in Ticket Booking System with AWS Lambda. Source: Dzone 通过REST端点公然治理运动的三个服务,每个服务都在AWS Lambda上实现。在这里,聚合器服务为其数据挪用其他三个服务,并将数据链接到其REST端点,该端点公然给客户端。更全面的分析和代码可以在[5]中找到。

c。API网关在微服务架构中,客户端通常需要使用多个服务中的功效。如果直接执行该消耗,则客户端需要处置惩罚对服务端点的多次挪用,这会带来许多严重影响服务延迟的问题,例如过多的网络往返,跨领域关注(授权,SSL等),精密耦合。

客户端应用法式与内部微服务设计之间的联系[6]。> Figure 5: API Gateway implemented as a custom service. Source: [2] API网关是一项为某些服务组提供单入口的服务。

它位于客户端应用法式和服务之间,充当反向署理,将请求从客户端路由到服务。为相识决上述问题,它提供了跨领域功效,例如SSL终止,身份验证,负载平衡,缓存等。它也可以用作反向署理或网关路由,而且可以举行请求聚合(类似于将多个请求批处置惩罚在一起)。我们不仅可以通过宁静,实时地处置惩罚更多请求来通过API网关扩展更大的系统,还可以通过基于业务界限和客户端应用将其隔离到多个API网关中来扩展API网关服务自己。

例如,可以有三个API网关,每个网关处置惩罚移动客户端的移动API,浏览器中的JS客户端的浏览器API,第三方开发人员的公共API(有关网关隔离的先容,请参见[6]关于Azure的信息) API网关):> Figure 6: Multiple custom API Gateways. Source: [2] d。连锁或责任链(CoR)> Figure 7: Chain of Responsibility Structure. Source: Wikipedia 责任链是一种行为设计模式,它通过将请求沿沿着称为处置惩罚法式或处置惩罚元素的独立工具链通报来的多个链状输出合并,从而生成单个组合输出。

收到请求后,每个处置惩罚法式都市决议处置惩罚该请求,还是将其通报给链中的下一个处置惩罚法式。该请求沿着火车行进,直到所有处置惩罚人员都有时机对其举行处置惩罚。处置惩罚法式还可以决议不进一步处置惩罚,并停止将请求向下通报给链。通过将服务封装在"管道"抽象中,CoR简化了工具互连。

取代发送者和吸收者维护对所有候选吸收者的引用,每个发送者保持对链的头部的单个引用,而每个吸收者保持对链中其直接后继的单个引用。由于所有这些服务都使用同步HTTP请求/响应消息通报,因此直到请求通过所有服务并生成相应的响应,客户端才获得输出。因此,建议不要接纳这种模式。

e。分支模式分支设计模式是一种模式,您可以在其中同时处置惩罚来自两个或多个独立服务的请求和响应。它扩展了聚合器和链设计模式,在该模式中,它使用聚合器凭据需求从多条链或单条链中发生响应。

> Figure 8: Example of Branch Pattern Structure. Source: JavaCodeGeeks 在上图中,网页或复合微服务的服务A可以同时挪用两个差别的链,在这种情况下,这类似于Aggregator设计模式。或者,服务A只能基于从客户端收到的请求来挪用一个链。

f。SagaSaga是一系列当地生意业务。Saga中的每个服务执行其自己的事务并公布事件。

其他服务侦听该事件并相应地执行。如果一项生意业务失败,则Saga会发出赔偿生意业务,以回滚先前生意业务发生的影响。

Saga的类型有两种:· 编排:卖力协调所有生意业务并指导到场者服务凭据先前生意业务执行期间/之后发生的事件执行当地生意业务的协调器:> Figure 12: Saga pattern with an orchestrator for Ordering service. Source: Dzone · 编舞:没有这种类型的中央协调员。每个到场服务都执行其事务并公布事件。其他服务凭据这些事件举行操作并相应地执行生意业务。

他们可能不会凭据情况公布其他事件:> Figure 13: Saga pattern with no orchestrator for Ordering service. Source: The Couchbase Blog 2.权力下放的治理集中治理的结果之一是倾向于在单一技术平台上实现尺度化。由于并非每个问题都是钉子,也不是每个解决方案都是锤子,所以这个问题很棘手,因此使用正确的工具完成正确的事情更为可取。将整体组件拆分为独立运营的服务,我们在构建每个组件时都有一个选择。

服务可以使用差别的语言(C ++,Go,Node.js等)和差别的数据存储(SQL,NoSQL)。在开发历程中使用多种语言的能力意味着可以使用适合该特定组件的语言和框架来构建每个组件。

此外,团队可以在公布时使用新的语言和框架来构建新的组件和服务。疏散数据治理:数据库模式承袭微服务的焦点原则,在思量我们的数据库结构时,请快速思量以下几点:· 服务必须是松散耦合的。

它们可以独立开发,部署和扩展。· 商业生意业务可能会强制跨越多个服务的稳定量· 商业生意业务可能会查询多个服务拥有的数据· 有时会复制数据库并对其举行分片以举行扩展· 差别的服务有差别的数据存储要求思量到上述原则,让我们形貌微服务应用法式应遵循的一些数据库设计模式。a。

每个服务的数据库> Figure 9: Database per Service pattern for two service instances. Source: microservices.io 整体应用法式倾向于使用单个逻辑数据库存储持久性数据,而微服务则通过让每个服务治理自己的数据库来疏散数据存储决议的权限,这些数据库可以是同一数据库技术的差别实例(棕场应用法式),也可以是完全差别的数据库系统(Polyglot Persistance –绿场应用法式) )。每个数据库都是为一项服务专门设计的,而且只能由其他服务通过公然的API会见。

b。每个服务共享数据库> Figure 10: Shared Database per Service for two services. 上面,我们提到了每个服务只有一个数据库对于微服务来说是理想的。

可是,如果应用法式是一个棕色的领域,厥后又转换为微服务,那么非规范化就不那么容易了。因此,单片和微服务之间的中间解决方案是让差别的服务(图13中的服务1和服务2)共享一个数据库。每个服务都使用当地ACID事务自由会见其他服务所拥有的数据,这对已经构建了整体应用法式并仍然保持漫衍式服务模型意义的开发人员更为熟悉。

不出所料,纵然单个数据库更易于操作且更熟悉开发,它可能会带来多个问题,例如架构耦合,运行时耦合或多个服务数据的存储扩展不足。c。下令查询职责隔离(CQRS)> Figure 11: CQRS Model. Source: Martin Fowler 在微服务架构中,服务可以查询从多个其他服务收集的数据。对于普通数据库,我们使用一个系统来对数据举行修改和查询数据。

使用CQRS,系统的一部门处置惩罚下令,这些下令捕捉修改状态的请求,而系统的另一部门处置惩罚查询。例如,使用事件源数据库实现,开发人员可能选择将下令作为事件来处置惩罚和处置惩罚,也许将下令列表存储在数据存储中。同时,查询模型可以查询事件存储并凭据存储的事件建立投影以组合域工具的状态。这种分散形式允许差别类型的缩放。

我们系统的下令和查询部门可以存在于差别的服务或差别的硬件中,而且可以使用完全差别类型的数据存储。例如,通过使用查询模型的多种实现,您甚至可以支持差别类型的读取花样,也许支持数据的基于图形的表现或数据的基于键/值的形式。

可以在这里仔细检察此模式。3.基础设施自动化更快的公布周期是微服务体系结构的主要优势之一。可是,如果没有良好的CI / CD流程,您将无法实现微服务所答应的敏捷性(当我们谈论CI / CD时,我们实际上是在谈论几个相关观点:连续集成,连续交付和连续部署)。设计结实的CI / CD流程时应接纳允许团队独立构建和部署自己的服务而不会影响或破坏其他团队的方式。

此外,CI / CD流程应首先在dev / test / QA / staging情况中部署服务新版本以举行验证,然后才气在生产中生效。早在2019年夏季,我在Got It的任务之一就是实施CI / CD管道治理工具,以使用AWS CodePipeline加速基础架构更新和产物迭代周期。任务的目的很简朴:构建内部门户的后端,使工程师可以使用Boto3设置管道的触发器,部署管道并返回任何错误(如果有的话),以提高暂时情况中的团队速度和事情吞吐量。

该工具在Got It的产物生态系统中饰演着重要角色,有助于实现微服务架构所答应的敏捷性。已往,用于单片应用法式的管道往往共享它们正在构建的应用法式的相同特征。由于两个差别的项目可能具有差别的管道,因此对于整体应用法式,公司可能必须处置惩罚1-5个管道(假设有1-5个项目)。

对于微服务体系结构,如果将每个整体分为5个微服务,则数量迅速跃升至25。凭据此盘算,如果管道数量继续线性增长,那么拥有50多个项目(每个项目都划分为10个微服务)的大型组织一次维护500多个管道也就屡见不鲜了。这就解释了为什么在处置惩罚CI / CD管道设计时要特别思量对旧管道举行维护和增加服务,以及建立新管道。CodeFresh提出了一种简朴但功效强大的设计来解决上述问题。

这里的基本思想是单个应用法式的所有服务都具有险些相同的生命周期。它们以类似的方式举行编译,打包和部署。因此,我们没有为每个服务使用多个管道,而是由所有多个服务共享一个管道。

> Figure 14: Pipeline designs in Monolith vs Microservices. Source: CodeFresh 现在,管道的构建很是简朴,因为它仅包罗一个用于多个git触发器的共享管道,每个触发器都来自特定微服务的git泉源。当在应用法式中添加新的微服务时,管道已经存在,而且仅添加了该微服务的新触发器。

因此,随着微服务数量的增长,唯一增加的是触发器列表。所有管道完全相同。4.故障隔离微服务架构的利益之一是组件或功效的故障隔离。换句话说,如果一个服务瓦解,则其他组件可以继续运行,直到该服务恢复为止。

以电子商务应用法式为例。理想情况下,每当客户实验购置商品或检察某个商品时,我们的应用法式都市凭据所选商品给出关于下一步该买什么商品的建议,以实验缔造更多的销售额。

在这种情况下,故障隔离意味着如果推荐服务因某种原因泛起故障,客户仍然可以使用结帐服务举行购置。可能不会向客户提供建议,而且可能会失去一些潜在的销售,但并不是全部。身份验证服务的瓦解可能更具破坏性,可是用户可以继续填写自己的购物车,而不是完全中断服务,而且在准备结帐时,可以显示一个屏幕,警告他们是否无法举行购物。

在完成购置后,他们应该稍后再试。此外,由于我们可以在发生故障时快速回滚,因此中断时间很短,而且可以将业务影响最小化。

可以隔离故障,并今后缓解。为此,面临服务部门故障,我们需要有效的计谋/模式。a。

断路器模式这是我在Sam Newman的Building Microservices中找到的与该模式有关的有趣示例:在您自己的家中,存在断路器来掩护您的电气设备免受电源尖峰的影响。如果泛起尖峰,则断路器会烧断,从而掩护了昂贵的家用电器。您还可以手动禁用断路器以切断部门衡宇的电源,从而使您可以宁静地使用电子设备。

[8]实际上,在微服务架构中,我们将有一个或多个服务挪用其他服务以举行数据/任何其他事务。在最终返回错误之前,下游服务可能会因负载过重或其他相关资源而关闭,或者响应速度可能很慢。如果多次重试该请求,可能会更糟,这会花费大量时间,直到我们最终收到错误消息。因此,为制止此类问题,我们实施了断路器。

一种典型的实现方式是使用署理作为电路屏障。对下游资源的一定数量的请求失败后,断路器被炸断,在特定时间段内向该服务发出请求而跳闸:> Figure 15: Use Circuit Breaker model to trip request to downstream service 当断路器关闭时,有一些选择:一种是将请求排队,然后稍后重试,如果请求是异步作业的一部门,则这是适当的。

如果请求是同步伐用链的一部门,则最好快速失败,然后将错误流传到整个链上,或者选择微妙的功效降级。其他一些计谋可以在[7]中找到。总结可伸缩Web体系结构设计的六项原则包罗可用性,可靠性,一致性,可伸缩性,可治理性和成本。

在软件体系结构中,单片应用法式是一个独立的,单层的传统软件应用法式,它在单个代码库中包罗整个应用法式代码。只管单片应用法式可以在较小的应用法式规模上取得乐成,但它带来了可伸缩性问题,例如在代码更改,单点故障,庞大的修改和测试以及受限的技术杠杆作用下重新部署整个CI / CD管道。微服务架构提供了恒久的敏捷性。

它们使您可以基于许多可独立部署的服务建立应用法式,从而在庞大,大型和高度可扩展的系统中实现更好的可维护性,每个服务均具有细化和自治的生命周期。由于服务相互独立运行,因此我们也具有开发,部署和扩展的自主权,因为每个服务都可以独立扩展。这样,只有需要更多处置惩罚能力或网络带宽的服务才可以按需扩展,从而节约了扩展应用法式其他不需要扩展的区域的成本。

下一步是什么?在下一篇文章中,我们来看看另外两种架构来扩展您的Web应用法式:面向服务的架构(SOA)和带有AWS Lambda的无服务器架构(FaaS)。请继续关注下一篇文章!五,参考资料[1] KeyCDN。比力URI和URL。2018年10月4日,https://www.keycdn.com/support/comparing-uri-vs-url[2] Edureka !。

英皇体育

微服务与SOA。Youtube,2018年3月12日,https://www.youtube.com/watch?v = EpyPFnjue38[3] Ahmed Shamim Hassan。视察者vs Pub-Sub模式。

Hackernoon,2017年10月28日,https://hackernoon.com/observer-vs-pub-sub-pattern-50d3b27f838c[4] Nathan Peck,微服务原理:智能端点和哑管道。中等,2017年9月1日,https://medium.com/@nathankpeck/microservice-principles-smart-endpoints-and-dumb-pipes-5691d410700f[5] Satrajit Basu,使用AWS Lambda的微服务聚合器设计模式。Dzone,2018年9月7日,https://dzone.com/articles/microservices-aggregator-design-pattern-using-aws[6] Microsoft,API网关模式与直接客户端到微服务的通信。

微软文档,2019年1月7日,https://docs.microsoft.com/zh-cn/dotnet/architecture/microservices/architect-microservice-container-applications/direct-client-to-microservice-communication-versus-the- api网关模式[7] Microsoft,处置惩罚部门故障的计谋。微软文档,2018年10月16日,https://docs.microsoft.com/zh-cn/dotnet/architecture/microservices/implement-resilient-applications/partial-failure-strategies[8]纽曼,山姆。构建微服务。

O'Reilly,2015年。(本文翻译自Dung Le的文章《Scalable Web Architectures Concepts & Design》,参考:https://medium.com/distributed-knowledge/scalable-web-architectures-concepts-design-6fd372ee4541)。


本文关键词:可扩展,的,英皇体育,Web,架构,观点,与,设计,【,英皇

本文来源:英皇体育-www.lqswwhg.cn