ImageVerifierCode 换一换
格式:DOCX , 页数:13 ,大小:781.21KB ,
资源ID:19307405      下载积分:3 金币
快捷下载
登录下载
邮箱/手机:
温馨提示:
快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。 如填写123,账号就是123,密码也是123。
特别说明:
请自助下载,系统不会自动发送文件的哦; 如果您已付费,想二次下载,请登录后访问:我的下载记录
支付方式: 支付宝    微信支付   
验证码:   换一换

加入VIP,免费下载
 

温馨提示:由于个人手机设置不同,如果发现不能下载,请复制以下地址【https://www.bdocx.com/down/19307405.html】到电脑端继续下载(重复下载不扣费)。

已注册用户请登录:
账号:
密码:
验证码:   换一换
  忘记密码?
三方登录: 微信登录   QQ登录  

下载须知

1: 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。
2: 试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。
3: 文件的所有权益归上传用户所有。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 本站仅提供交流平台,并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

版权提示 | 免责声明

本文(架构设计之架构演化模式与核心要素Word下载.docx)为本站会员(b****5)主动上传,冰豆网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知冰豆网(发送邮件至service@bdocx.com或直接QQ联系客服),我们立即给予删除!

架构设计之架构演化模式与核心要素Word下载.docx

1、文件服务器需要存储大量用户上传的文件,因此需要更大的硬盘。使用缓存随着用户逐渐增多,网站又一次面临挑战:数据库压力太大导致访问延迟,进而影响整个网站的性能,用户体验受到影响。网站访问遵循二八定律:80%的业务访问集中在20%的数据上。既然大部分的业务访问集中在一小部分数据上,那么如果把这一小部分数据缓存在内存中,是不是就可以减少数据库的访问压力,提高整个网站的数据访问速度,改善数据库的写入性能了呢?网站使用的缓存可以分为两种:缓存在应用服务器上的本地缓存和缓存在专门的分布式缓存服务器上的远程缓存。本地缓存的访问速度更快一些,但是受应用服务器内存限制,其缓存数据量有限,而且会出现和应用程序争用内

2、存的情况。远程分布式缓存可以使用集群的方式,部署大内存的服务器作为专门的缓存服务器,可以在理论上做到不受内存容量限制的缓存服务,如图所示。使用应用服务器集群使用缓存后,数据访问压力得到有效缓解,但是单一应用服务器能够处理的请求连接有限,在网站访问高峰期,应用服务器成为整个网站的瓶颈。使用集群是解决高并发、海量数据问题的常用手段。当一台服务器的处理能力、存储空间不足时,不要企图去换更强大的服务器,对大型网站而言,不管多么强大的服务器,都满足不了网站持续增长的业务需求。这种情况下,更恰当的做法是增加一台服务器分担原有服务器的访问及存储压力。只要能通过增加一台服务器的方式改善负载压力,就可以以同样的

3、方式持续增加服务器不断改善系统性能,从而实现系统的可伸缩性。应用服务器集群是可伸缩集群架构设计中较为简单成熟的一种,如图所示。通过负载均衡调度服务器,可将来自用户浏览器的访问请求分发到应用服务器集群中的任何一台服务器上,如果有更多的用户,就在集群中加入更多的应用服务器,使应用服务器的负载压力不再成为整个网站的瓶颈。读写分离网站在使用缓存后,使绝大部分数据读操作访问都可以不通过数据库就能完成,但是仍有一部分读操作和全部的写操作需要访问数据库,在网站的用户达到一定规模后,数据库因为负载压力过高而成为网站的瓶颈。目前大部分的主流数据库都提供主从热备功能,通过配置两台数据库主从关系,可以将一台数据库服

4、务器的数据更新同步到另一台服务器上。网站利用数据库的这一功能,实现数据库读写分离,从而改善数据库负载压力,如图所示。应用服务器在写数据的时候,访问主数据库,主数据库通过主从复制机制将数据更新同步到从数据库,这样当应用服务器读数据的时候,就可以通过从数据库获得数据。为了便于应用程序访问读写分离后的数据库,通常在应用服务器端使用专门的数据访问模块,使数据库读写分离对应用透明。反向代理和CDN随着业务不断发展,用户规模越来越大,不同地区的用户访问网站时,速度差别也极大。为了提供更好的用户体验,网站需要加速网站访问速度。主要手段有使用CDN和反向代理,如图所示。CDN和反向代理的基本原理都是缓存,区别

5、在于CDN部署在网络提供商的机房,使用户在请求网站服务时,可以从距离自己最近的网络提供商机房获取数据;而反向代理则部署在网站的中心机房,当用户请求到达中心机房后,首先访问的服务器是反向代理服务器,如果反向代理服务器中缓存着用户请求的资源,就将其直接返回给用户。使用分布式文件系统和分布式数据库系统数据库经过读写分离后,从一台服务器拆分成两台服务器,但是随着网站业务的发展依然不能满足需求,这时需要使用分布式数据库。文件系统也是一样,需要使用分布式文件系统,如图所示。分布式数据库是网站数据库拆分的最后手段,只有在单表数据规模非常庞大的时候才使用。不到不得已时,网站更常用的数据库拆分手段是业务分库,将

6、不同业务的数据库部署在不同的物理服务器上。使用NoSQL和搜索引擎随着网站业务越来越复杂,对数据存储和检索的需求也越来越复杂,网站需要采用一些非关系数据库技术如NoSQL和非数据库查询技术如搜索引擎,如图所示。业务拆分大型网站为了应对日益复杂的业务场景,通过使用分而治之的手段将整个网站业务分成不同的产品线。具体到技术上,将一个网站拆分成许多不同的应用,每个应用独立部署维护。应用之间可以通过一个超链接建立关系(在首页上的导航链接每个都指向不同的应用地址),也可以通过消息队列进行数据分发,当然最多的还是通过访问同一个数据存储系统来构成一个关联的完整系分布式服务随着业务拆分越来越小,存储系统越来越庞

7、大,应用系统的整体复杂度呈指数级增加,部署维护越来越困难。既然每一个应用系统都需要执行许多相同的业务操作,比如用户管理、商品管理等,那么可以将这些共用的业务提取出来,独立部署。由这些可复用的业务连接数据库,提供共用业务服务,而应用系统只需要管理用户界面,通过分布式服务调用共用业务服务完成具体业务操作,如图所示。大型网站的架构演化到这里,基本上大多数的技术问题都得以解决。架构模式为了解决应用系统面临的高并发访问、海量数据处理、高可靠运行等一系列问题与挑战,大型互联网公司在实践中提出了许多解决方案,以实现高性能、高可用、易伸缩、可扩展、安全等各种技术架构目标。这些解决方案又被更多公司重复使用,从而

8、逐渐形成架构模式。分层分层是企业应用系统中最常见的一种架构模式,将系统在横向维度上切分成几个部分,每个部分负责一部分相对比较单一的职责,然后通过上层对下层的依赖和调用组成一个完整的系统。在网站架构中,通常将应用系统分为应用层、服务层、数据层,如下图所示。通过分层,可以更好地将一个庞大的软件系统切分成不同的部分,便于分工合作开发和维护。各层之间具有一定的独立性,只要维持调用接口不变,各层可以根据具体问题独立演化发展而不需要其他层必须做出相应调整。但是分层架构也有一些挑战,就是必须合理规划层次边界和接口,在开发过程中,严格遵循分层架构的约束,禁止跨层调用及逆向调用。在实践中,大的分层结构内部还可以

9、继续分层。分层架构是逻辑上的,三层结构可以部署在同一个物理机器上。但是随着网站业务的发展,必然需要对已经分层的模块分离部署,使网站拥有更多的计算资源以应对越来越多的用户访问。分割分层是将软件在横向方面进行切分,分割则是在纵向方面对软件进行切分。网站越大,功能越复杂,服务和数据处理的种类也越多。将这些不同的功能和服务分割开来,包装成高内聚低耦合的模块单元,一方面有助于软件的开发和维护;另一方面,便于不同模块的分布式部署,提高网站的并发处理能力和功能扩展能力。大型网站分割的粒度可能会很小。比如在应用层,将不同业务进行分割,例如将购物、论坛、搜索、广告分割成不同的应用,由独立的团队负责,部署在不同的

10、服务器上。分布式对于大型网站,分层和分割的一个主要目的是为了切分后的模块便于分布式部署,即将不同模块部署在不同的服务器上,通过远程调用协同工作。分布式意味着可以使用更多的资源完成同样的功能,能够处理的并发访问和数据量也更大。但分布式在解决网站高并发问题的同时也带来了其他问题。典型的有下面几点:意味着服务调用必须通过网络,这可能会对性能造成比较严重的影响。服务器越多,宕机的概率也就越大,造成的服务不可用可能会导致很多应用不可访问,使网站可用性降低。数据在分布式的环境中保持数据一致性非常困难,分布式事务也难以保证。系统依赖错综复杂,开发管理维护困难。因此分布式设计要根据具体情况量力而行。常用的分布

11、式方案有:分布式服务、分布式数据库、分布式计算、分布式配置、分布式锁和分布式文件系统等。集群使用分布式虽然已经将分层和分割后的模块独立部署,但是对于用户访问集中的模块,还需要将独立部署的服务器集群化,即多台服务器部署相同应用构成一个集群,通过负载均衡设备共同对外提供服务。因为服务器集群有更多服务器提供相同服务,因此可以提供更好的并发性,当有更多用户访问的时候,只需要向集群中加入新的机器即可。同时当某台服务器发生故障时,负载均衡设备或者系统的失效转移机制会将请求转发到集群中其他服务器上,提高系统的可用性。缓存缓存就是将数据存放在距离计算最近的位置以加快处理速度。缓存是改善软件性能的第一手段,在复

12、杂的软件设计中,缓存几乎无处不在。比如常见的反向代理、Redis(未开启持久化)、CDN等。使用缓存有两个前提条件,一是数据访问热点不均衡,某些数据会被更频繁的访问,这些数据应该放在缓存中;二是数据在某个时间段内有效,不会很快过期,否则缓存的数据就会因已经失效而产生脏读,影响结果的正确性。缓存除了可以加快数据访问速度,还可以减轻后端应用和数据存储的负载压力,网站数据库几乎都是按照有缓存的前提进行负载能力设计的。异步应用系统的一个重要目标是降低耦合性。系统解耦的手段除了前面提到的分层、分割、分布式等,还有一个重要手段是异步,业务之间的消息传递不是同步调用,而是将一个业务操作分成多个阶段,每个阶段

13、之间通过共享数据的方式异步执行进行协作。异步架构是典型的生产者消费者模式,两者不存在直接调用,只要保持数据结构不变,彼此功能实现可以随意变化而不互相影响,这对网站扩展新功能非常便利。除此之外,使用异步消息队列还有如下优点:提高系统可用性。消费者服务器发生故障,数据会在消息队列服务器中存储堆积,生产者服务器可以继续处理业务请求,系统整体表现无故障。消费者服务器恢复正常后,继续处理消息队列中的数据。加快网站响应速度。处在业务处理前端的生产者服务器在处理完业务请求后,将数据写入消息队列,不需要等待消费者服务器处理就可以返回,响应延迟减少。消除并发访问高峰。用户访问网站是随机的,存在访问高峰和低谷。使

14、用消息队列将突然增加的访问请求数据放入消息队列中,等待消费者服务器依次处理,就不会对整个网站负载造成太大压力。但需要注意的是,使用异步方式处理业务可能会对用户体验、业务流程造成影响,需要网站产品设计方面的支持。冗余网站需要724小时连续运行,但是服务器随时可能出现故障,特别是服务器规模比较大时,出现某台服务器宕机是必然事件。要想保证在服务器宕机的情况下网站依然可以继续服务,不丢失数据,就需要一定程度的服务器冗余运行,数据冗余备份,这样当某台服务器宕机时,可以将其上的服务和数据访问转移到其他机器上。访问和负载很小的服务也必须部署至少两台服务器构成一个集群,其目的就是通过冗余实现服务高可用。数据库

15、除了定期存档进行冷备份外,还需要对数据库进行主从分离,实时同步实现热备份。自动化与安全目前应用系统的自动化架构设计主要集中在发布运维方面。包括自动化发布、自动化代码管理、自动化测试、自动化安全监测、自动化部署、自动化监控、自动化告警、自动化失效转移与恢复、自动化降级和自动化分配资源等。系统在安全架构方面也积累了许多模式:通过密码和手机校验码进行身份认证;登录、交易等操作需要对网络通信进行加密,网站服务器上存储的敏感数据如用户信息等也进行加密处理;为了防止机器人程序滥用网络资源攻击网站,网站使用验证码进行识别;对于常见的用于攻击网站的XSS攻击、SQL注入、进行编码转换等相应处理;对于垃圾信息、

16、敏感信息进行过滤;对交易转账等重要操作根据交易模式和交易信息进行风险控制。架构核心要素关于什么是架构,维基百科是这样定义的:“有关软件整体结构与组件的抽象描述,用于指导大型软件系统各个方面的设计”。一般说来,除了功能需求外,软件架构还需要关注性能、可用性、伸缩性、扩展性和安全性这5个要素。性能性能是网站的一个重要指标,任何软件架构设计方案都必须考虑可能会带来的性能问题。也正是因为性能问题几乎无处不在,所以优化网站性能的手段也非常多,主要的方式可以总结如下:浏览器:浏览器缓存、使用页面压缩、合理布局页面、减少Cookie传输等CDN和反向代理本地缓存和分布式缓存异步消息队列应用层:服务器集群代码

17、层:多线程、改善内存管理等数据层:索引、缓存、SQL优化等,以及合理使用NoSQL数据库可用性网站高可用的主要手段是冗余,应用部署在多台服务器上同时提供访问,数据存储在多台服务器上互相备份,任何一台服务器宕机都不会影响应用的整体可用,也不会导致数据丢失。对于应用服务器而言,多台应用服务器通过负载均衡设备组成一个集群共同对外提供服务,任何一台服务器宕机,只需把请求切换到其他服务器即可,但是一个前提条件是应用服务器上不能保存请求的会话信息。对于存储服务器,需要对数据进行实时备份,当服务器宕机时需要将数据访问转移到可用的服务器上,并进行数据恢复以保证继续有服务器宕机的时候数据依然可用。除了运行环境,

18、网站的高可用还需要软件开发过程的质量保证。通过预发布验证、自动化测试、自动化发布、灰度发布等手段,减少将故障引入线上环境的可能。伸缩性衡量架构伸缩性的主要标准有:是否可以用多台服务器构建集群,是否容易向集群中添加新的服务器,加入新的服务器后是否可以提供和原来的服务器无差别的服务,集群中可容纳的总的服务器数量是否有限制。对于应用服务器集群,通过使用合适的负载均衡设备就可以向集群中不断加入服务器。对于缓存服务器集群,需要使用高效的缓存路由算法,避免加入新服务器导致路由大面积失效。关系数据库很难做到大规模集群的可伸缩性,因此关系数据库的集群伸缩性方案必须在数据库之外实现,通过路由分区等手段将部署有多

19、个数据库的服务器组成一个集群。至于大部分NoSQL数据库产品,由于其先天就是为海量数据而生,因此其对伸缩性的支持通常都非常好。扩展性衡量架构扩展性的主要标准就是不同产品之间是否很少耦合。在网站增加新的业务产品时,是否可以实现对现有产品透明无影响,不需要任何改动或者很少改动既有业务功能就可以上线新产品。网站可伸缩架构的主要手段是事件驱动架构和分布式服务。事件驱动架构在网站通常利用消息队列实现,将用户请求和其他业务事件构造成消息发布到消息队列,消息的处理者作为消费者从消息队列中获取消息进行处理。通过这种方式将消息产生和消息处理分离开来,可以透明地增加新的消息生产者任务或者新的消息消费者任务。分布式服务则是将业务和可复用服务分离开来,通过分布式服务框架调用。新增产品可以通过调用可复用的服务实现自身的业务逻辑,而对现有产品没有任何影响。可复用服务升级变更的时候,也可以通过提供多版本服务对应用实现透明升级,不需要强制应用同步变更。安全性网站的安全架构就是保护网站不受恶意访问和攻击,保护网站的重要数据不被窃取。衡量网站安全架构的标准就是针对现存和潜在的各种攻击与窃密手段,是否有可靠的应对策略。

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1