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

199 阅读9分钟

大型网站技术架构

概述

大型网站软件系统的特点

  • 高并发,大流量(大流量访客)
  • 高可用(系统 7*24 小时不间断服务)
  • 海量数据
  • 用户分布广泛,网络情况复杂
    • 全球各地网络情况千差万别
    • 国内,各个运营商网络互通难
  • 安全环境恶劣
  • 需求快速变更,发布频繁
  • 渐进式发展

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

初始阶段的网站架构

应用程序、数据库、文件等所有资源都在一台服务器上。通常服务器操作系统使用 Linux, 应用程序使用 PHP 开发,然后部署在 Apache 上,数据库使用 MySQL,汇集各种免费开源软件及一台廉价服务器就可以开始网站的发展之路了。

应用服务和数据服务分离

随着网站的发展,一台服务器逐渐不能满足需求:越来越多的用户访问导致性能越来越差,越来越多的数据导致存储空间不足。

解决方法:将应用和数据分离。分离后网站使用三台服务器:

  • 应用服务器(处理大量的业务逻辑,更快更强大的 CPU)
  • 文件服务器(足够大的硬盘)
  • 数据库服务器(更加快速的磁盘检索和数据缓存,更快的硬盘,更大的内存)

使用缓存改善网站性能

用户量过大、数据过多时,产生数据库压力太大导致访问延迟。

网站使用的缓存可以分两种:

  • 本地缓存
    • 缓存在应用服务器上,缓存数量有限,而且会出现和应用程序争用内存的情况。
  • 远程缓存(缓存在分布式缓存服务器上)
    • 使用集群的方式,部署大内存的服务器作为专门的缓存服务器。

微信图片_20220720114327.jpg

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

微信图片_20220720114732.jpg 通过负载均衡调度服务器,可将来自用户浏览器的访问请求分发到应用服务器集群中的任何一台服务器上,如果有更多的用户,就在集群中加入更多的应用服务器,使应用服务器的负载压力不再成为整个网站的瓶颈。

数据库读写分离

网站使用缓存后,绝大部分数据读操作访问都可以不通过数据库就能完成,但是仍有一部分读操作和全部的写操作需要访问数据库,在网站的用户的达到一定规模后,数据库因为负载压力过高而成为网站的瓶颈。

目前大部分的主流数据库都提供主从热备功能,通过配置两台数据库主从关系,可以将一台数据库服务器的数据更新到另一台服务器上。网站利用数据库的这一功能,实现数据库读写分离,从而改善数据库负载压力。

微信图片_20220720115945.jpg

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

CDN和反向代理的基本原理都是缓存,区别在于CDN部署在网络提供商的机房,使用户在请求网站服务时,可以从距离自己最近的网络提供商机房获取数据;而反向代理则部署在网站的中心机房,当用户请求到达中心机房后,首先访问的服务器是反向代理服务器,如果反向代理服务器中缓存着用户请求的资源,就将其直接返回给用户。

微信图片_20220720135352.jpg

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

微信图片_20220720140025.jpg

分布式数据库是网站数据库拆分的最后手段,只有在单表数据规模非常庞大的时候才使用。

使用 NoSQL 和 搜索引擎

微信图片_20220720140215.jpg

NoSQL 和搜索引擎都是源自互联网的技术手段,对可伸缩的分布式特性具有更好的支持。应用服务器则通过一个统一数据访问模块访问各种数据,减轻应用程序管理诸多数据源的麻烦。

业务拆分

根据产品线划分,将一个网站拆分成许多不同的应用,每个应用独立部署维护。应用之间可以通过一个超链接简历关系(在首页上的导航链接每个都只想不同的应用地址)

分布式服务

微信图片_20220720141114.jpg

大型网站的架构模式

什么是模式?这个来自建筑学的词汇是这样定义的:

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

网站架构模式

分层

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

分布式

对于大型网站,分层和分割地一个主要目的是为了切分后地模块便于分布式部署,即将不同模块部署在不同的服务器上,通过远程调用协同工作。

优点:意味着可以使用更多地计算机完成同样的功能,计算机越多,CPU、 内存、存储的资源也就越多,能够处理的并发访问呢和数据量就越大,能够服务更多的用户。

缺点:数据难以报纸一致;服务器可能宕机;开发管理维护困难。

分布式设计要根据具体情况量力而行。

常用的分布式方案有以下几种:

  • 分布式应用和服务
  • 分布式静态资源
  • 分布式数据和存储
  • 分布式计算
  • 分布式配置
  • 分布式锁
  • 分布式文件

集群

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

缓存

  • CDN

    内容分发网络,部署在距离终端用户最近地网络服务商,用户的网络请求总是先到达他的网络服务商那里,在这里缓存网站的一些静态资源(较少变化的数据), 可以就近以最快的速度返回给用户,如视频网站和门户网站会将用户访问量大的热点内容缓存在 CDN.

  • 反向代理(将部分数据缓存在反向代理服务器上)

  • 本地缓存

  • 分布式缓存

异步

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

冗余

防止出现服务器宕机,数据丢失等情况,需要一定程度上的服务器冗余运行,数据冗余备份。

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

早期,微博也是简单的 LAMP(linux + Apache + MySQL + PHP) 架构,支撑起最新的新浪微博,应用程序用 PHP 开发,所有的数据,包括微博、用户、关系都存储在 MySQL 数据库中。

后来随着业务的发展,形成了如下架构:

微信图片_20220722135652.jpg

新浪微博的早期架构中,微博发布使用同步推模式,用户发表微博后,系统会立即将这条微博导入到数据库所有的粉丝订阅列表中。当用户量比较大时,特别是明星用户发布微博时,会引起大量的数据库写操作,超出数据库负载,系统性能急剧下降,用户响应延迟加剧。

后来新浪微博改用异步推拉结合的模式,用户发表微博后,系统将微博写入消息队列后立即返回,用户响应迅速,消息队列消费者任务将微博推送给所有当前在线粉丝的订阅列表中,非在线用户登陆后再根据关注列表拉取微博订阅列表。

大型网站核心架构要素

关于什么是架构,一种比较通俗的说法是“最高层次的规划,难以改变的决定”。

具体到软件架构,维基百科是这样定义的:有关软件整体架构与组件抽象的描述,用于指导大型软件系统各个方面的设计。

一般来说,除了当前的系统功能需求外,软件架构还需要关注性能、可用性、伸缩性、拓展性和安全性这 5 个构架要素。

性能

  • 浏览器端
    • 浏览器缓存、使用页面压缩、合理布局页面、减少 Cookie 传输等
  • CDN
  • 在反向代理服务器上,缓存热点文件。
  • 在应用服务器端,使用本地缓存和分布式缓存。
  • 通过异步操作将用户请求发送至消息队列等待后续任务处理,而当前请求直接返回响应给用户。
  • 组件集群。
  • 在代码层面,使用多线程、改善内存管理。
  • 数据库服务器端,优化 索引、缓存、SQL 优化等。

可用性

大型网站通常会有上万台服务器,每天都必定会有一些服务器宕机,因此网站高可用架构设计的前提是必然会出现服务器宕机,而高可用设计的目标就是当服务器宕机的时候,服务或者应用依然可用。

伸缩性

服务器集群实现。

拓展性

如何设计网站的架构使其能够快速响应需求变化,是网站可拓展架构主要的目的。