大型网站技术架构-读书笔记

大型网站技术架构-读书笔记

大型网站的特点:

  • 高并发,大流量的访问
  • 高可用的服务
  • 海量数据
  • 用户分布广,网络环境复杂
  • 安全环境恶劣
  • 需要快速变更,发布频繁
  • 渐进式发展,大型网站都是从一个小网站开始,渐进的演化。

架构演化历程

大型网站的技术挑战主要来自于庞大的用户,高并发的访问和海量的数据,任何简单的业务一旦需要处理数以P计的数据和面对数以亿计的用户,问题就会变得很棘手。大型网站架构主要就是解决这类问题。

小型网站阶段

大型网站都是从小型网站发展而来。小型网站最开始没有什么人访问,只要一台服务器就可以。应用程序,数据库,文件等所有资源都在一台服务器上。

应用服务和数据服务分离

随着业务的发展,一台服务器满足不了需求:

  • 过多的用户访问导致性能越来越差
  • 过多的数据导致存储空间不足。

这时候就要将应用和数据分离。应用和数据分离后网站使用3台服务器:应用服务器,文件服务器和数据服务器。

这3台服务器对硬件资源的要求各不相同,应用服务器需要处理大量的业务逻辑,需要更快的cpu;数据库服务器需要快速磁盘检索和数据缓存,需要更大的内存和更快的磁盘;文件服务器需要存储大量文件,需要更大的硬盘。

应用和数据分离后,不同特性的服务器承担不同的服务角色,网站的并发处理能力和数据存储空间得到了很大的改善。但是随着用户的增多,数据库压力太大导致访问延迟。

使用缓存改善网站性能

网站的访问特点遵循着二八定律:大部分业务访问集中在一小部分数据上,那么如果把这部分数据缓存在内存中,会减少数据库的访问压力。

网站的缓存分为两种:

  • 缓存在应用服务器上的本地缓存。
  • 缓存在专门的分布式缓存服务器上的远程缓存。

本地缓存的访问速度更快一些,但是受应用服务器内存限制,其缓存数据量有限,而且会出现和应用程序争用内存的情况。远程分布式缓存可以使用集群的方式,部署大内存的服务器作为专门的缓存服务器,可以在理论上做到不受内存容量限制的缓存服务。

使用缓存后,数据访问压力得到缓解,但是单一应用服务器能处理的请求连接有限,应用服务器成了网站的瓶颈。

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

使用集群是网站解决高并发,海量数据问题的常用手段。当一台服务器的处理能力,存储空间不足时,考虑通过水平扩容的方式来分担服务器的访问和存储压力。

通过负载均衡调度服务器,可以将用户访问请求分发到应用服务器集群的任何一台服务器上,如果有更多用户就在集群中加入更多的应用服务器。

数据库读写分离

网站使用缓存后,大多数读操作都可以不通过数据库完成,但是仍有部分读操作(缓存不命中,缓存过期,缓存淘汰)和全部写操作需要访问数据库,因此当网站的用户达到一定规模后,数据库成了瓶颈问题。

目前大部分的主流数据库都支持主从热备功能。通过设置两台数据库的主从关系,可以将一台数据库服务的数据更新同步到另一台服务器上。将写请求落在主库,读请求落在从库,实现数据库的读写分离,从而改善数据库负载压力。

应用服务器在写数据的时候,访问主数据库,主数据库通过主从复制机制将数据更新同步到从数据库,这样当应用服务器读数据的时候,就可以通过从数据库获得数据。为了便于应用程序访问读写分离后的数据库,通常在应用服务器端使用专门的数据访问模块,使数据库读写分离对应用透明。

反向代理和CDN加速网站响应

为了提供更好的用户体验,留住用户,网站需要加速网站访问速度。主要手段有使用CDN和反向代理。CDN和反向代理的基本原理都是缓存,区别在于CDN部署在网络提供商的机房,使用户在请求网站服务时,可以从距离自己最近的网络提供商机房获取数据;而反向代理则部署在网站的中心机房,当用户请求到达中心机房后,首先访问的服务器是反向代理服务器,如果反向代理服务器中缓存着用户请求的资源,就将其直接返回给用户。使用CDN和反向代理的目的都是尽早返回数据给用户,一方面加快用户访问速度,另一方面也减轻后端服务器的负载压力。

分布式文件系统和分布式数据库系统

任何强大的单一服务器都满足不了大型网站持续增长的业务需求。数据库经过读写分离后,从一台服务器拆分成两台服务器,但是随着网站业务的发展依然不能满足需求,这时需要使用分布式数据库。文件系统也是一样,需要使用分布式文件系统。

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

使用NoSQL和搜索引擎

随着业务的复杂,对数据存储和检索的需求也越来越复杂,需要采用一些非关系数据库技术如NoSQL和非数据库查询技术如搜索引擎。

NoSQL和搜索引擎对可伸缩的分布式有更好的支持。应用服务器则通过一个统一数据访问模块访问各种数据,减轻应用程序管理诸多数据源的麻烦。

业务分拆

大型网站为了应对复杂的业务场景,通过使用分而治之的手段将网站业务分为不同的产品线。如大型购物交易网站就会将首页、商铺、订单、买家、卖家等拆分成不同的产品线,分归不同的业务团队负责。

具体到技术上,也会根据产品线划分,将一个网站拆分成许多不同的应用,每个应用独立部署维护。应用之间可以通过一个超链接建立关系(在首页上的导航链接每个都指向不同的应用地址),也可以通过消息队列进行数据分发,当然最多的还是通过访问同一个数据存储系统来构成一个关联的完整系统。

分布式服务

随着业务拆分越来越小,存储系统越来越庞大,应用系统的整体复杂度呈指数级增加,部署维护越来越困难。由于所有应用要和所有数据库系统连接,在数万台服务器规模的网站中,这些连接的数目是服务器规模的平方,导致存数据库接资源不足,拒绝服务。

既然每一个应用系统都需要执行许多相同的业务操作,比如用户管理、商品管理等,那么可以将这些共用的业务提取出来,独立部署。由这些可复用的业务连接数据库,提供共用业务服务,而应用系统只需要管理用户界面,通过分布式服务调用共用业务服务完成具体业务操作。

架构模式

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

分层

分层是一种最常见的架构模式,将系统在横向维度上切分成几个部分,每个部分负责一部分相对比较单一的职责。然后通过上层对下层的依赖和调用组成一个完整的系统。分层架构思想在计算机世界中无处不在,例如网络的7层通信协议可以看做是一种分层架构;计算机硬件,操作系统和应用软件也可以看做是一种分层结构。在大型网站架构中也采用分层结构,将网站软件系统分为应用层,服务层和数据层。

  • 应用层: 负责具体业务和视图展示。如网站首页及搜索输入和结果展示。
  • 服务层: 为应用层提供服务支持。如用户管理服务,购物车服务等。
  • 数据层: 提供数据存储访问服务。如数据库,缓存,文件,搜索引擎等。

通过分层可以更好地将一个庞大的软件系统切分成不同的部分,便于分工合作开发和维护;各层间有一定的独立性,只要维持调用接口不变,各层可以根据具体问题独立演化发展。

但是分层架构也有一些挑战,就是必须合理规划层次边界和接口,在开发过程中,严格遵循分层架构的约束,禁止跨层次的调用以及逆向调用。在实践中大的分层还可以再细分

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

虽然分层架构模式最初的目的是规划软件清晰的逻辑结构便于开发维护,但在网站的发展过程中,分层结构对网站支持高并发向分布式方向发展至关重要。因此在网站规模还很小的时候就应该采用分层的架构,这样将来网站做大时才能有更好地应对。

分割

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

大型网站分割的粒度可能会很小。比如在应用层,将不同业务进行分割,例如将购物、论坛、搜索、广告分割成不同的应用,由独立的团队负责,部署在不同的服务器上;在同一个应用内部,如果规模庞大业务复杂,会继续进行分割,比如购物业务,可以进一步分割成机票酒店业务、3C业务,小商品业务等更细小的粒度。而即使在这个粒度上,还是可以继续分割成首页、搜索列表、商品详情等模块,这些模块不管在逻辑上还是物理部署上,都可以是独立的。同样在服务层也可以根据需要将服务分割成合适的模块。

分布式

分层和分割的一个主要目的是为了切分后的模块便于分布式部署:即不同的模块部署在不同的服务器上,通过远程调用协同工作。但是分布式在解决高并发问题的同时也带来了其他问题。

  • 分布式意味着服务调用必须通过网络,这可能对性能造成比较严重的影响;
  • 服务器越多,服务器宕机的概率也越大,一台服务器宕机造成的服务不可用可能会导致很多应用不可访问;
  • 数据在分布式环境保持数据一致性也非常困难,分布式事务也很难保证;
  • 分布式还导致网站依赖错综复杂,开发管理维护困难;

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

  • 分布式应用和服务: 将分层和分割后的应用和服务模块分布式部署,可以改善网站性能和并发性、加快开发和发布速度、减少数据库的连接资源消耗,复用共同的服务,便于业务功能扩展。
  • 分布式静态资源: 网站的静态资源如JS,CSS,Logo图片等资源独立分布式部署,并采用独立的域名,即动静分离。静态资源分布式部署可以减轻应用服务器的负载压力;通过使用独立域名加快浏览器并发加载速度
  • 分布式数据和存储:大型网站需要处理PB级别的海量数据,单台机器无法提供如此大的存储空间,需要分布式存储。除了对传统的关系数据库进行分布式部署外,为网站应用而生的各种NoSQL产品几乎都是分布式的。
  • 分布式计算:严格说来,应用、服务、实时数据处理都是计算,网站除了要处理这些在线业务,还有很大一部分用户没有直观感受的后台业务要处理,包括搜索引擎的索引构建、数据仓库的数据分析统计等。这些业务的计算规模非常庞大,目前网站普遍使用MR,Spark,Flink分布式计算框架进行计算,将计算程序分发到各个节点进行分布式计算。

还有可以支持网站线上服务器配置实时更新的分布式配置;分布式环境下实现并发和协同的分布式锁;支持云存储的分布式文件系统等。

集群

分布式虽然已经将分层和分割后的模块独立部署,但是对于用户访问集中的模块(比如网站的首页),还需要将独立部署的服务器集群化,即多台服务器部署相同应用构成一个集群,通过负载均衡设备共同对外提供服务。

因为服务器集群有更多服务器提供相同的服务,因此可以提供更好的并发特性,当有更高并发要求时,只需要向集群中加入新的机器。同时,因为一个应用由多台服务器提供,当某台服务器发生故障时,负载均衡设备或者系统的失效转移机制会将请求转发到集群中的其他服务器上,使服务器故障不影响用户使用。所以在网站应用中,访问量很小的服务也会至少部署两台服务器来构成集群,以提高可用性。

缓存

缓存就是将数据存放在距离计算最近的位置以加快处理速度。缓存是改善软件性能的第一手段,现代CPU越来越快的一个重要因素就是使用了更多的缓存,在复杂的软件设计中,缓存几乎无处不在。大型网站架构设计在很多方面都使用了缓存设计。

  • CDN: 即内容分发网络,部署在距离终端用户最近的网络服务商,用户的网络请求总是先到达他的网络服务商那里,在这里缓存网站的一些静态资源(较少变化的数据),可以就近以最快速度返回给用户,如视频网站和门户网站会将用户访问量大的热点内容缓存在CDN。
  • 反向代理:反向代理属于网站前端架构的一部分,部署在网站的前端,当用户请求到达网站的数据中心时,最先访问到的就是反向代理服务器,这里缓存网站的静态资源,无需将请求继续转发给应用服务器就能返回给用户。
  • 本地缓存:在应用服务器本地缓存着热点数据,应用程序可以在本机内存中直接访问数据,而无需访问数据库。
  • 分布式缓存:大型网站的数据量非常庞大,即使只缓存一小部分,需要的内存空间也不是单机能承受的,所以除了本地缓存,还需要分布式缓存,将数据缓存在一个专门的分布式缓存集群中,应用程序通过网络通信访问缓存数据。

使用缓存有两个前提条件,一是数据访问热点不均衡,某些数据会被更频繁的访问,这些数据应该放在缓存中;二是数据在某个时间段内有效,不会很快过期,否则缓存的数据就会因已经失效而产生脏读,影响结果的正确性。网站应用中,缓存除了可以加快数据访问速度,还可以减轻后端应用和数据存储的负载压力,这一点对网站数据库架构至关重要,网站数据库几乎都是按照有缓存的前提进行负载能力设计的。

异步

计算机软件发展的一个重要目标和驱动力是降低软件耦合性。事物之间直接关系越少,就越少被彼此影响,越可以独立发展。大型网站架构中,系统解耦合的手段除了前面提到的分层、分割、分布等,还有一个重要手段是异步,业务之间的消息传递不是同步调用,而是将一个业务操作分成多个阶段,每个阶段之间通过共享数据的方式异步执行进行协作。

在单一服务器内部可以通过多线程共享内存队列的方式实现异步,处在业务操作前面的线程将输出写入到队列,后面的线程从队列中读取数据进行处理;在分布式系统中,多个服务器集群通过分布式消息队列实现异步,分布式消息队列可以看作内存队列的分布式部署。

异步架构是典型的生产者消费者模式,两者不存在直接调用,只要保持数据结构不变,彼此功能实现可以随意变化而不互相影响,这对网站扩展新功能非常便利。

  • 提高系统可用性。消费者服务器发生故障,数据会在消息队列服务器中存储堆积,生产者服务器可以继续处理业务请求,系统整体表现无故障。消费者服务器恢复正常后,继续处理消息队列中的数据。
  • 加快网站响应速度。处在业务处理前端的生产者服务器在处理完业务请求后,将数据写入消息队列,不需要等待消费者服务器处理就可以返回,响应延迟减少。
  • 消除并发访问高峰。用户访问网站是随机的,存在访问高峰和低谷,即使网站按照一般访问高峰进行规划和部署,也依然会出现突发事件,比如购物网站的促销活动,微博上的热点事件,都会造成网站并发访问突然增大,这可能会造成整个网站负载过重,响应延迟,严重时甚至会出现服务宕机的情况。使用消息队列将突然增加的访问请求数据放入消息队列中,等待消费者服务器依次处理,就不会对整个网站负载造成太大压力。

但需要注意的是,使用异步方式处理业务可能会对用户体验、业务流程造成影响,需要网站产品设计方面的支持。

冗余

网站需要7*24小时连续运行,但是服务器随时可能出现故障,特别是服务器规模比较大时,出现某台服务器宕机是必然事件。要想保证在服务器宕机的情况下网站依然可以继续服务,不丢失数据,就需要一定程度的服务器冗余运行,数据冗余备份,这样当某台服务器宕机时,可以将其上的服务和数据访问转移到其他机器上。

访问和负载很小的服务也必须部署至少两台服务器构成一个集群,其目的就是通过冗余实现服务高可用。数据库除了定期备份,存档保存,实现冷备份外,为了保证在线业务高可用,还需要对数据库进行主从分离,实时同步实现热备份。

为了抵御地震、海啸等不可抗力导致的网站完全瘫痪,某些大型网站会对整个数据中心进行备份,全球范围内部署灾备数据中心。网站程序和数据实时同步到多个灾备数据中心。

自动化

在无人值守的情况下网站可以正常运行,一切都可以自动化是网站的理想状态。目前大型网站的自动化架构设计主要集中在发布运维方面。

通过减少人为干预,使发布过程自动化可有效减少故障。发布过程包括诸多环节。自动化代码管理,代码版本控制、代码分支创建合并等过程自动化,开发工程师只要提交自己参与开发的产品代号,系统就会自动为其创建开发分支,后期会自动进行代码合并;自动化测试,代码开发完成,提交测试后,系统自动将代码部署到测试环境,启动自动化测试用例进行测试,向相关人员发送测试报告,向系统反馈测试结果;自动化安全检测,安全检测工具通过对代码进行静态安全扫描及部署到安全测试环境进行安全攻击测试,评估其安全性;最后进行自动化部署,将工程代码自动部署到线上生产环境。

此外,网站在运行过程中可能会遇到各种问题:服务器宕机、程序Bug、存储空间不足、突然爆发的访问高峰。网站需要对线上生产环境进行自动化监控,对服务器进行心跳检测,并监控其各项性能指标和应用程序的关键数据指标。如果发现异常、超出预设的阈值,就进行自动化报警,向相关人员发送报警信息,警告故障可能会发生。在检测到故障发生后,系统会进行自动化失效转移,将失效的服务器从集群中隔离出去,不再处理系统中的应用请求。待故障消除后,系统进行自动化失效恢复,重新启动服务,同步数据保证数据的一致性。在网站遇到访问高峰,超出网站最大处理能力时,为了保证整个网站的安全可用,还会进行自动化降级,通过拒绝部分请求及关闭部分不重要的服务将系统负载降至一个安全的水平,必要时,还需要自动化分配资源,将空闲资源分配给重要的服务,扩大其部署规模。

安全

互联网的开放特性使得其从诞生起就面对巨大的安全挑战,网站在安全架构方面也积累了许多模式:通过密码和手机校验码进行身份认证;登录、交易等操作需要对网络通信进行加密,网站服务器上存储的敏感数据如用户信息等也进行加密处理;为了防止机器人程序滥用网络资源攻击网站,网站使用验证码进行识别;对于常见的用于攻击网站的XSS攻击、SQL注入、进行编码转换等相应处理;对于垃圾信息、敏感信息进行过滤;对交易转账等重要操作根据交易模式和交易信息进行风险控制。

架构要素

-------------本文结束感谢您的阅读-------------
坚持分享,您的支持将鼓励我继续创作!
0%