网站技术架构读书笔记-概述

1. 大型网站架构演化

1.1大型网站软件系统的特点

  • 高并发,大流量:Google,QQ,淘宝海量用户与PV

  • 高可用:系统7*24小时不间断服务

  • 海量数据:需要存储,管理海量数据,使用大量服务器

  • 用户分布广泛,网络情况复杂:地域广泛,各地网络情况千差万别

  • 安全环境恶劣:互联网的开放性是的站点易受攻击

  • 需求快速变更,发布频繁:快速迭代,满足需求

  • 渐进式发展:逐步发展,并非开始就有全局规划

1.2大型网站架构演化发展历程

  • 1.2.1 初始阶段的网站架构

image

应用程序,数据库,文件等所有资源都在一台服务器上。

  • 1.2.2 应用服务于数据服务分离

image

不同特性的服务器承担不同的服务角色

  • 1.2.3 使用缓存改善网站性能

image

大部分业务访问集中在小部分数据上,二八法则。缓存分为两种:本地缓存,远程缓存(分布式缓存)

  • 1.2.4 使用应用服务器集群改善网站的并发处理能力

image

使用集群是网站解决高并发,海量数据问题的常用手段。

  • 1.2.5 数据库读写分离

image

面前大部分主流数据库都提供主从热备功能,通过配置两台数据库主从管理,可以实现读写分离。

  • 1.2.6 使用反向代理和CDN加速网站响应

image

原因:用户规模大,广后不同地区的用户访问速度差别很大。
CDN和反向代理的基本原理都是缓存,区别在于CDN部署在网络提供商的机房,使用户在请求网站服务时,可以从距离自己最近的网络提供商机房获取数据;二反向代理则部署在网站的中心机房,当用户请求到达中心机房后,首先访问的服务器是反向代理服务器,如果反向代理服务器中缓存着用户请求的资源,就将直接返回给用户。使用CDN和反向代理的目的都是尽早返回数据给用户,一方面加快用户访问速度,另一方面也是减轻后端服务器的负责压力。

  • 1.2.7 使用分布式文件系统和分布式数据库系统

image

分布式数据库是网站数据库拆分的最后手段,只有在单表数据规模非常庞大的时候才使用。不到不得已的时候,网站更常用的数据库拆分手段是业务分库,将不同业务的数据库部署在不同的物理服务器上。

  • 1.2.8 使用NoSql和搜索引擎

image
业务复杂后,可以使用如上架构来满足。应用服务器则通过一个统一数据访问模块访问各种数据,减轻应用程序管理诸多数据源的麻烦。

  • 1.2.9 业务拆分

image

大型汪涵为了应对日益复杂的业务场景,通过使用分而治之的手段将整个网站业务分成不同的产品线。具体到技术上,也会根据产品线划分,将一个网站拆分成许多不同的应用,每个应用独立部署维护。应用之间可以通过一个超链接建立关系,也可以通过消息队列进行数据分发,当然最多的还是通过访问同一个数据存储系统来构成一个关联的完整系统。

  • 1.2.10 分布式服务

image

将多个业务线公共的业务提取出来,独立部署,提供共用业务服务。

1.3 大型网站架构演化的价值观

网站的价值在于它能为用户提供什么价值,在于网站能做什么,而不在于它是怎么做的,所以在网站还很小的时候就去追求网站的架构是舍本逐末,得不偿失的。小型网站最需要做的就是为用户提供好的服务来创造价值,得到用户认可,活下去,野蛮生长。

  • 1.3.1 大型网站架构技术的核心价值是随网站所需灵活应对
  • 1.3.2 驱动大型网站技术发展的主要力量是网站的业务发展:是业务成就了技术,事业成就了人,而不是相反。

1.4 网站架构设计误区

  • 1.4.1 一味追随大公司的解决方案
  • 1.4.2 为了技术而技术:网站技术是为业务二存在的,除此毫无意义。
  • 1.4.3 企图是技术解决所有问题:技术是用来解决业务问题的,二业务的问题,也可以通过业务的手段去解决。

2. 大型网站架构模式

模式:每一个模式描述了一个在我们周围不断重复发生的问题及该问题解决方案的核心。这样,你就能一次又一次地使用该方案而不必做重复工作。

2.1 网站架构模式

为了解决大型网站面临的高并发访问,海量数据处理,高可靠运行等一系列问题与挑战,大型互联网公司在实践中提出了许多解决方案,以实现网站高性能,高可用,易伸缩,可扩展,安全等各种技术架构牧宝。这些解决方案又被更多网站重复使用,从而逐渐形成大型网站架构模式。

2.1.1 分层

分层结构在计算机世界无处不在,在大型网站架构中也采用分层结构,将网站软件系统分为应用层,服务层,数据层。

image.png

但是分层架构也有一些挑战,就是必须合理规划层次边界和接口,在开发过程中,严格遵循分层架构的约束,进制跨层次的调用及逆向调用。

分层架构是逻辑上的,在物理部署上,三层结构可以部署在同一个物理机器,但是随着网站业务的发展,必然需要对已经分层的模块分离部署,使网站拥有更多的计算资源以应对越来越多的用户访问。当然可以在继续细分层。

2.1.2 分割

如果说分层是将软件在横向方面进行切分,那么分割就是在纵向方面对软件进行切分。将不同的功能和服务分割开来,包装秤高内聚低耦合的模块单元,一方面有助于软件的开发和维护;另一方面,便于不同模块的分布式部署,提高网站的并发处理能力和功能扩展能力。

2.1.3 分布式

对于大型网站,分层和分割的一个主要目的是为了切分后的模块便于分布式部署,即将不同模块在不同的服务器,通过远程调用协同工作。分布式意味着可以使用更多的计算机完成同样的功能。资源越多能够处理的并发访问和数据量就越大,进而能够为更多的用户提供服务。

带来的问题:1,分布式意味着服务调用必须通过网络,这可能会对性能造成比较严重的影响;2,服务器越多,服务器宕机的概率越大,一台服务器宕机造成的服务不可用可能会导致很多应用不可访问,使可用性降低。3,数据在分布式的环境中保持数据一致性也非常困难。4,导致网站以来错综复杂,开发管理维护困难。

在网站应用中,常用的分布式方案有以下几种:

  • 分布式应用和服务:将分层和分割后的应用和服务模块分布式部署,除了可以改善网站性能和并发性,加快开发和发布速度,减少数据库连接资源消耗外;还可以使不同应用复用共同的服务,便于业务功能的扩展。
  • 分布式静态资源:网站的静态资源独立分布式不是,并采用独立的域名,即人们常说的动静分离。这样减轻应用服务器负载压力,独立域名加快浏览器并发加载速度。
  • 分布式数据和存储:海量数据西药巨大的存储空间。
  • 分布式计算:严格来说,应用,服务,实时数据都是计算。目前网站普遍使用Hadoop及其MapReduce分布式计算框架进行此类批处理计算。
  • 分布式文件系统:云存储
  • 分布式锁:分布式环境下实现并发和协同。
  • 分布式配置:支持网站线上服务器配置实时更新。

2.1.4 集群

多台服务器部署想通应用构成一个集群,通过负载均衡设备共同对外提供服务。集群可以有效的提高站点并发和提供系统的可用性。

2.1.5 缓存

缓存就是讲数据存放在距离计算最近的位置以加快处理速度。缓存是改善软件性能的第一手段。

  • CDN: 内容分发网络,以距离用户就近的服务商返回用户一些静态资源。
  • 反向代理:反向代理属于网站前端架构的一部分,不是在网站的前端,当用户请求到达网站的数据中心时,最先访问到的就是反向dialing服务器,这里缓存汪涵的静态资源,无需将请求继续转发给应用服务器就能返回给用户。
  • 本地缓存:在应用服务器本地缓存着热点数据,可以直接在本机内存中直接访问数据,而不需访问数据库。
  • 分布式缓存:大型网站的数据量庞大,本地缓存无法满足,将数据缓存在一个专门的分布式缓存集群中。

使用缓存有两个前提条件:1,数据访问热点不均衡,有热点数据。2,数据在某个时间段内有效,不会很快过期,负责容易失效产生脏读,影响结果的正确性。

网站数据库几乎都是按照有缓存的前提进行负载能力设计的。

2.1.6 异步

计算机软件发展的一个重要目标和驱动力是降低软件耦合性。大型网站架构中,系统解耦合的手段除了前面提到的分层,分割,分布,还有异步。

在单一服务器内部可通过多线程共享内存队列的方式实现异步,处在业务操作前面的线程将输出写入到队列,后面的线程从队列中读取数据进行处理;在分布式系统中,多个服务器集群通过分布式消息队列实现异步,分布式消息队列可以看做内存队列的分布式部署。异步架构是典型的生产者消费者模式,两者不存在直接调用。只要保持数据结构不变,碧玺功能实现可以随意变化而不互相影响。

异步消息队列还有以下特性:

  • 提高系统可用性:就算一侧故障也不会影响整体功能。
  • 加快网站响应速度:异步,不需要等待直接结果返回。
  • 消除并发访问高峰:如促销活动,热点事件等。

带来的问题:使用异步方式处理业务可能会对用户体验,业务流程造成影响,需要网站产品设计方面的支持。

2.1.7 冗余

在大型站点服务中,某台服务器宕机是必然事件,当有服务器冗余运行时,可以切换到正常服务器上。访问和负载很小的服务也必须部署至少两台服务器构成一个集群,其目的就是通过冗余实现服务器高可用。数据库可冷热备。为了抵御地震,海啸等,大型站点还会对整个数据中心进行备份,全球部署灾备数据中心。网站程序和数据实时同步到多个灾备数据中心。

2.1.8 自动化

通过减少人工干预,可以有效减少故障。

  • 自动化发布
  • 自动化代码管理
  • 自动化测试
  • 自动化安全监测
  • 自动化部署
  • 自动化监控
  • 自动化报警
  • 自动化失效转移:将失效的服务器从集群隔离出去,不再处理系统中的应用请求。
  • 自动化失效恢复:将故障消除后的服务中心启动,同步数据保持数据的一致性。
  • 自动化降级:通过拒绝部分请求及关闭部分不重要的服务奖系统负载降至一个安全水平。
  • 自动化分配资源:将空闲支援分配给重要的服务,扩大其部署规模。

2.1.9 安全

  • 数据通信加密
  • web安全:XSS攻击,SQL注入等
  • 敏感信息过滤

2.2 架构模式在新浪微博的应用

几经周折,形成了如下架构:

image.png

最下层是基础服务层,中间是平台服务和应用服务层,上一层是API和新浪微博的业务层,各种客户端和第三方应用。

在新浪微博的早期架构中,微博发布使用同步推模式,用户发表微博后立即将这条微博插入到数据库所有粉丝订阅列表中,这样突发事件会超出数据库负载。后来新浪微博改用异步推拉集合模式,用户发表微博后系统将微博吸入消息队列立即返回,用户响应迅速,详细队列消费者任务将微博推送给所有当前在线粉丝的订阅列表中,非在线用户登录后再根据关注聊表拉取微博订阅列表。

由于微博频繁刷新,微博使用多级缓存。热门微博和明星用户的微博魂村在所有的微博服务器上,在线用户的微博和近期微博缓存在分布式缓存集群中。刷微博操作几乎全部都是缓存访问操作。

微博还启用了多个数据中心,用户可以就近访问,改善系统性能,同事也是数据冗余复制的灾备中心。

微博还开发了一系列自动化工具。

2.3 小结

好的设计绝对不是模仿,不是生搬硬套某个模式,而是对问题深刻理解之上的创造与创新,即使是微创新,也是让人耳目一新的似曾相识。山寨和创新的最大区别不在于是否抄袭,是否模仿,而在于对问题和需求是否真正理解与把握。

3. 大型网站核心架构要素

什么是架构:最高层次的规划,难以改变的决定。这些规划和决定奠定了事物未来发展的方向和最终的蓝图。

具体到软件架构,维基百科的定义:有关软件整体结构与组件的抽象描述,用于指导大型软件系统各个方向的设计。 系统的各个重要组成部分及其关系构成了系统的架构,这些组成部分可以使具体的功能模块,也可以使非功能的设计与决策,他们相互关系组成一个整体,共同构成了一个软件系统的架构。

除了当前的系统功能需求外,软件架构还需要关注性能可用性伸缩性扩展性安全性这五个架构要素,架构设计过程中需要平衡这五个要素之间的关系以实现需求和架构目标。也可能通过考察这些架构要素来衡量一个软件架构设计的优劣,判断其是否满足期望。

3.1 性能

性能是网站的一个重要指标。从浏览器到数据库,影响用户请求的所有环节都可以进行性能优化。

衡量网站性能有一系列指标,重要的有响应时间,TPS,系统性能计数器等。

对于网站而言,性能符合其余仅仅是必要条件,因为无法预知网站可能会面临的访问压力,所以必须要考察系统在高并发访问情况下,超出负载设计能力的情况下可能会出现的性能问题。网站需要长时间运行,还必须保证系统在持续运行且访问压力不均匀的情况下保持稳定的性能特性。

3.2 可用性

服务器的设计目标本身并不保证高可用,可能会出现服务器硬件问题(宕机)。

高可用的设计目标就是当服务器宕机的时候,服务或者应用依然可用。网站高可用的主要手段是冗余,应用部署在多台服务器上同事提供访问,也不会导致数据丢失。多个应用服务器通过负载均衡设备组成一个集群共同对外提供服务。

3.3 伸缩性

所谓伸缩性是指通过不断向集群中加入服务器的手段来环节不断上升的用户并发访问压力和不断增长的数据存储需求。

衡量架构伸缩性的主要标准就是是否可以用多台服务器构建集群,是否容易想急群众添加新的服务器。加入新的服务器后是否可以提供和原来的服务无差别的服务。急群众可容纳的总的服务器数据是否有限制。

对于应用服务器集群,只要服务器上不保存数据,所有服务器都是对等的,通过使用合适的负载均衡就可以像集群中不断加入服务器。

对于缓存服务器集群,加入新的服务器可能会导致缓存路由失效,进而导致集群中大部分缓存数据都无法访问。虽然缓存的数据可以通过数据库重新加载,但是如果应用已经严重依赖缓存,可能会导致整个网站崩溃。西药改进缓存路由算法保证缓存数据的可访问行。

关系型数据库虽然支持数据复制,主从热备等机制,但是很难做到大规模集群的可伸缩性,因此关系数据库的集群伸缩性方案必须在数据库职位实现,通过路由分区等手段将部署有多个数据库的服务器组成一个集群。Nosql先天就是为海量数据而生,伸缩性的支持非常好。

3.4 扩展性

网站可扩展架构主要的目的是为了使其能够快速响应需求变化。

衡量网站架构扩展性好还的主要标准就是在网站添加新的业务产品时,是否可以实现对现有产品透明无影响,不需要任何改动或者很少改动既有业务功能就可以上线新产品。不同产品间低耦合。

网站可伸缩架构的主要手段是事件驱动架构分布式服务

  • 事件驱动架构在网站通常利用消息队列实现,将用户请求和其他业务事件构成消息发布到消息队列,消息的处理者作为消费者从消息队列中获取消息进行处理。通过这种方式将消息产生和消息处理分离开来,可以透明地增加新的消息生产者任务或者新的消息消费者任务。
  • 分布式服务则是将业务和可服用服务分离开来,通过分布式服务框架调用。新增产品可以通过调用可复用的服务实现自身的业务逻辑,而对现有产品没有任何影响。可复用服务升级变更的时候,也可以通过提供多版本服务对应用实现透明升级,不需要强制应用同步变更。

有事大型站点还会吸引第三方开发者,调用网站服务,使用网站数据开发周边产品,扩展网站业务。第三方开发者使用网站服务的主要途径是大型网站提供的开放平台接口。

3.5 安全性

网站的安全架构就是保护网站不受恶意访问和攻击,保护网站的重要数据不被窃取。

衡量网站安全架构的标准就是针对现存和潜在的各种攻击与窃密手段,是否有可靠的应对策略。

3.6 总结

性能,可用性,伸缩性,扩展性和安全性是网站架构最核心的几个要素,这几个问题解决了,大型网站架构设计的大部分挑战也就克服了。

comments powered by Disqus