《大型网站技术架构》学习笔记(一)

简介

趁周末时间膜拜了大佬写的《大型网站技术架构》一书,也是对系统架构有了一些入门级的了解。看了前面三章,感觉通熟易懂,受益匪浅,想以笔记的方式记录一下。

大型网站架构的演化

发展历程

初始阶段的网站架构

应用程序、文件、数据库

LAMP=linux+apache+mysql+php

存在的问题

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

应用服务和数据服务分离

特点

应用和数据分离后,不同特征的服务器承担不同的服务角色,网站的并发处理能力和数据存储空间得到很大改善

存在的问题

随着用户逐渐增多,数据库压力太大导致访问延迟

使用缓存改善网站性能

特点

淘宝买家浏览的商品集中在少部分成交数多、评价良好的商品上;百度搜索关键词集中在少部分热门词汇上;只有经常登陆的用户才会发微博、刷微博。就像二八定律,80%的业务访问集中在20%的数据上,既然大部分业务访问集中在一小部分数据上,那么就把这一小部分数据缓存在内存中,就可以减少数据库的访问压力。

应用本地缓存

本地缓存访问的速度更快一些,但是受应用服务器内存的影响,其缓存数据量有限,而且会和应用程序争用内存的情况。

分布式缓存

远程分布式缓存可以使用集群的方式,部署大内存的服务器作为专门的缓存服务器,可以在理论上做到不受内存容器限制的缓存服务。

思考🤔:什么数据适用于应用本地缓存?什么数据适用分布式缓存?参考

存在的问题

但是单一应用服务器能够处理的请求连接有限,在网站访问高峰期,应用服务器成为整个网站的瓶颈。

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

特点

使用集群是网站解决高并发、海量数据问题的常用手段。当一台服务器处理能力、存储空间不足时,不要企图去更换更强大的服务器,对大型网站而言,不管多么强大的服务器,都满足不了网站持续增长的业务需求。这种情况下,更恰当的做法是增加一台服务器分担原有服务器的访问及存储压力。(同时采用集群部署的方式提升系统的伸缩性)

依赖项

需要引入负载均衡调度服务器,将来自用户浏览器的访问请求分发到应用服务器集群中的任何一台服务器上。

仍存在的问题

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

数据库读写分离

特点

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

依赖项

为了便于应用程序访问读写分离后的数据库,通常在应用服务器使用专门的数据访问模块,使数据库读写分离对应用透明(读写分离,一般需要中间件或者AOP,对性能有一定的损耗)

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

特点

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

什么是反向代理

正向代理:所谓的正向一般指的客户端到服务端的请求方向,正向代理也就是代理客户端(请求的发起方),与无法访问的服务端建立请求,帮助客户端访问无法访问的服务器资源。比如VPN翻墙软件

反向代理:反向代理也就是代理服务端(真实处理请求的那方),将请求转发给内部服务进行处理,帮助服务器做负载均衡,安全防护等。比如gateway服务集群

共同点:两者都能通过缓存,提高访问速度。

作用

使用CDN和反向代理的目的都是尽早返回数据给用户,一方面加快用户访问速度,另一方面也减轻后端服务器的负载压力。

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

特点

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

使用NoSQL和搜索引擎

特点

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

业务拆分

特点

根据业务对应用服务进行拆分,分不同的产品线,交由不同的业务团队和技术团队负责。

依赖项

服务注册中心或者消息队列,进行应用服务间的业务通信

分布式服务

特点

将不同模块的公共业务提取出来,作为公共业务服务,独立部署。比如连接数据库,应用缓存等操作都维护在这个服务中,然后以集群多实例的方式进行部署。

演化价值观

  • 网站的价值在于它能给用户提供什么价值,在于网站能做什么,而不在于它是怎么做的。
  • 大型网站都是从小型网站发展而来,小型网站要做的就是为用户提供好的服务来创造价值,得到用户的认可,野蛮生长。
  • 驱动大型网站技术发展的主要力量是网站的业务发展。是业务成就了技术,是事业成就了人,而不是相反。
  • 所以网站架构师应该对成就自己技术成绩的网站事业心存感激,并努力提高技术反馈业务。

网站架构设计误区

  • 一味追随大公司的解决方案

  • 为了技术而技术

  • 企图用技术解决所有的问题

    • 12306真正的问题其实不在于它的技术架构,而在于它的业务架构(比如整点售票)
    • 技术是用来解决业务问题的,而业务的问题,也可以通过业务的手段去解决。

大型网站的架构模式

模式的定义(建筑学)

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

  1. 分层(横向分,比如应用层、服务层、数据层)

    比如:网络的7层协议;计算机硬件、操作系统、应用软件也是一种分层结构

  2. 分割(纵向分,按业务功能进行分)

    1. 比如:将购物、论坛、搜索、广告分割成不同的应用
  3. 分布式:会带来分布式事务和数据不一致问题,同时可用性降低

    1. 分布式应用和服务
    2. 分布式静态资源
    3. 分布式数据和存储
    4. 分布式计算
    5. 分布式锁、分布式配置、分布式文件
  4. 集群:提高可用性

  5. 缓存:改善性能

  6. 异步:提高可用性、加快网站响应,削峰填谷

    1. 比如,生产消费者模式
  7. 冗余:数据灾备(冷备份、热备份)

  8. 自动化:自动化测试、自动化部署,自动化监控报警

  9. 安全:防止XSS攻击、SQL注入

大型网站核心架构要素

什么是架构

最高层次的规划,难以改变的决定

除了当前系统的功能需求外,软件架构还需要关注性能,可用性,伸缩性、扩展性和安全性

性能

定义

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

  1. 浏览器端
  2. CDN缓存
  3. 应用服务端缓存
  4. 异步
  5. 集群多实例
  6. 多线程
  7. 数据库
可用性
  1. 应用服务器
  2. 存储服务器
  3. 软件开发过程中的质量保证(持续交互)
伸缩性

定义

通过不断向集群中加入服务器的手段来缓解不断上升的用户并发访问压力和不断增长的数据存储需求

  1. 应用服务器集群
  2. 缓存服务器集群(较难)
扩展性

定义

不同于其他架构要素关注非功能性需求,网站的扩展性架构直接关注网站的功能需求,衡量的主要标准是在网站增加新的业务产品时,是否可以实现对现有产品透明无影响,不需要任何改动或者很少改动既有业务功能就可以上线新产品。

  1. 事件驱动架构
  2. 分布式服务
安全性

定义

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