《大型网站技术架构》阅读笔记

前言

在看《大型网站技术架构-核心原理与案例分析》的一些整理汇总，其中图片部分来源于书籍。

基本信息

《大型网站技术架构-核心原理与案例分析》 作者：李智慧 2013年出版

目录：

• 概述：1、架构演化。2、架构模式。3、核心架构要素
• 架构：高性能、高可用性、伸缩性、可扩展性、安全。
• 案例：①淘宝网架构演化。②维基百科高性能架构。③海量分布式存储系统Doris高可用架构。④网购秒杀系统。⑤大型网站典型故障。
• 架构师：需要具备的特质；职场攻略；架构师分类

关键词含：一致性Hash算法…。

---

一、概述

1.1、架构演化

演化历程

1. 初始阶段的网站架构：一台服务器，上面同时拥有应用程序，数据库，文件，等所有资源。例如 LAMP 架构
2. 应用和数据服务分离：三台服务器（硬件资源各不相同），分别是应用服务器，文件服务器和数据库服务器
3. 使用缓存改善网站性能：分为两种，缓存在应用服务器上的本地缓存和缓存在专门的分布式缓存服务器的远程缓存
4. 使用应用服务器集群改善网站并发处理能力：通过负载均衡调度服务器来将访问请求分发到应用服务器集群中的任何一台机器
5. 数据库读写分离：数据库采用主从热备，应用服务器在写数据时访问主数据库，主数据库通过主从复制机制将数据更新同步到从数据库。应用服务器使用专门的数据访问模块从而对应用透明
6. 使用反向代理和 CDN 加速网站响应：这两者基本原理都是缓存。反向代理部署在网站的中心机房，CDN 部署在网络提供商的机房
7. 使用分布式文件系统和分布式数据库系统：数据库拆分的最后手段，更常用的是业务分库
8. 使用 NoSQL 和搜索引擎：对可伸缩的分布式有更好的支持
9. 业务拆分：将整个网站业务拆分成不同的应用，每个应用独立部署维护，应用之间通过超链接建立联系/消息队列进行数据分发/访问同一数据存储系统
10. 分布式服务：公共业务提取(例如用户、商品管理)出来独立部署，由这些可复用的业务进行连接数据库，提供公共业务服务，应用系统只需要管理用户界面，分布式服务调用公共业务完成具体业务操作。

演化的价值观

• 大型网站架构的核心价值是随网站所需灵活应对
• 驱动大型网站技术发展的主要力量是网站的业务发展

误区

• 一味追随大公司的解决方案
• 为了技术而技术
• 企图用技术解决所有问题

图例

---

1.2、架构模式

模式的关键在于模式的可重复性

• 分层：横向切分。（将庞大的软件系统切分，将网站软件系统分成应用层、服务层、数据层）

• 分割：纵向切分。（例如在应用层将不同业务进行分割，如将购物、论坛、搜索、广告分割成不同业务；若是某个业务较庞大、复杂，如购物业务可进一步分割为机票酒店业务、3c业务、小商品业务。对于该些小粒度的业务还可进行拆分为首页、搜索列表、商品详情等模块）

• 分布式：分层和分割的主要目的是为了切分后的模块便于分布式部署。常用方案：

• • 分布式应用和服务
  • 分布式静态资源
  • 分布式数据和存储
  • 分布式计算：除了一些在线业务，还有一些用户没有直观感受的后台业务。目前网站普遍使用Hadoop、MapReduce分布式计算框架进行类批处理计算。
  • 分布式配置，分布式锁，分布式文件，等等

• 集群：多台服务器部署相同的应用构成一个集群，通过负载均衡设备共同对外提供服务

• 缓存：将数据放距离计算最近的位置加快处理速度，改善性能第一手段，可以加快访问速度，减小后端负载压力。使用缓存 两个前提条件 ：1.数据访问热点不均衡；2.数据某时段内有效，不会很快过期；3、二八原则，针对于大量20%部分查询内容作缓存，若是一直更新的资源没有必要作缓存

• • CDN
  • 反向代理
  • 本地缓存
  • 分布式缓存

• 异步：旨在系统解耦。异步架构是典型的消费者生产者模式，特性如下：

• • 提高系统可用性
  • 加快网站访问速度
  • 消除并发访问高峰

• 冗余：实现高可用。数据库的冷备份和热备份

• 自动化：包括发布过程自动化，自动化代码管理，自动化测试，自动化安全检测，自动化部署，自动化监控，自动化报警，自动化失效转移，自动化失效恢复，自动化降级，自动化分配资源

• 安全：密码，手机校验码，加密，验证码，过滤，风险控制

---

1.3、核心要素

架构是“最高层次的规划，难以改变的规定”。主要关注五个要素：

• 性能
• 可用性(Availability)
• 伸缩性(Scalability)
• 扩展性(Extensibility)
• 安全性

---

二、架构层面

2.1、高性能【网站性能、web前端、应用服务器、存储性能】

网站性能测试

性能的测试指标主要有：

• 响应时间：指应用执行一个操作需要的时间。
  • 
• 并发数：指系统能够同时处理请求的数目。
• 吞吐量：指单位时间内系统处理的请求数量。（TPS每秒事务数、HPS每秒HTTP请求数、QPS每秒查询数）
• 性能计数器：描述服务器或者操作系统性能的一些数据指标。（Linux命令行查看，top）

性能测试方法：

• 性能测试
• 负载测试
• 压力测试
• 稳定性测试

web前端性能测试

Web 前端性能优化

1. 浏览器优化
   • 减少HTTP请求：合并css、js、图片到一个文件，多次请求转为一次请求。
   • 浏览器缓存：设置HTTP头中Cache-Control和Expires属性。
   • 启用压缩：服务器端对文件进行压缩，浏览器端解压缩。文本文件压缩率高达80%，可对css、js、html采用GZIP压缩。
   • css放最上面。js放最下面：目的是让浏览器尽快下载css渲染页面，若是js写前面可能会发生阻塞问题，造成页面解析缓慢。
   • 减少cookie传输：太大cookie会影响数据传输，对于静态资源访问携带cookie是没有作用的，针对于静态资源可以考虑使用独立域名访问，避免请求时携带cookie。
2. CDN加速：一般CDN部署在网络运营商机房，用户请求第一跳就达到CDN服务器，使其最短路径返回。
3. 反向代理：接收HTTP请求进行负载均衡分发请求(对于应用集群)，并且在web服务器前增加了一个安全屏障，可对一些内容进行缓存在代理服务器上加速用户访问，若是一些动态内容有变化，可通过内部通知机制通知反向代理缓存失效，反向代理会重新加载最新动态内容再次缓存！

应用服务器性能优化

主要手段有缓存、集群、异步

1、分布式缓存(网站性能优化第一定律：优化考虑使用缓存优化性能)：遵循二八定理，80%请求落在20%的数据上，将20%的数据进行缓存。

2、合理使用缓存。

• 不该使用缓存：①频繁修改。②无热点访问。③数据不一致与脏读(数据一旦更新也要对应更新缓存，一般缓存设置时间)。④缓存可用。
  • ④说明：缓存雪崩指的是缓存服务失效，大量请求落到数据库而宕机，导致网站不可用。一般网站会使用缓存热备提高缓存可用性(指的是当缓存服务器宕机，将缓存访问切换到热备服务器)，这种方案不太好，缓存不应该当做一个可靠的数据源来使用。正解：使用分布式缓存集群(缓存数据分别到集群多台服务器上，若是某一台宕机那么只有部分数据丢失，重新从数据库加载数据即可，不会有很大影响)。
• 缓存预热：缓存存放热点数据，采用LRU(最近最久未用算法)对不断访问的数据进行筛选淘汰出来，该过程需要花费较长时间。最好的方式是进行缓存预热，将一些常用的数据在服务启动时从数据库加载到缓存中。
• 缓存穿透：

3、分布式缓存架构：缓存部署在多个服务器组成的集群中，以集群方式来提供缓存服务。两种架构①JBoss Cache代表的更新同步分布式缓存。②Memcached为代表不互相通信分布式缓存。

4、异步操作(消息队列，削峰作用)。

• 过程说明：使用消息队列后，用户请求数据发送给消息队列后立即返回，由消息队列的消费者进程从消息队列中获取数据再进行异步写入数据库。

5、使用集群：通过负载均衡技术来构建一台对多台，将并发访问请求进行合理分发。

6、代码优化：①多线程。②资源复用(线程池)。③数据结构。④垃圾回收

• ①：IO阻塞型=[任务执行时间/（任务执行时间-IO等待时间）] x CPU内核数，线程数最佳数量与CPU内核数量成正比，与IO阻塞成反比；CPU型-不要超过CPU内核数。【保证线程安全：①设置成无状态。②使用局部变量。③合理使用锁】
• ②单例、对象池。
• ③合理使用Hash。
• ④合理分配年轻代和老年代，尽量避免少进行Full GC。
  • 

存储性能优化

• 机械硬盘 vs. 固态硬盘
  • 固态硬盘：无机械装置，数据存储在可持久记忆的硅晶片上，因此就可以像内存一样快速访问，相对于机械硬盘具有更小功能与震动。
• B+ 树 vs. LSM 树
  • B+ 树：专门针对磁盘存储优化的N叉排序树，以树节点为单位存储在磁盘中，从根开始查找所需数据所在的节点编号与磁盘位置，将其加载到内存中后再继续查找，直到找到所需数据。
  • LSM：N阶合并树，写操作都在内存中执行，这些数据在内存仍然是排序树，超过一定阈值会和磁盘上最新排序树合并；若磁盘上的排序树超过阈值就会和磁盘上下一级的排序树合并。进行读操作会先从内存中的排序树查找，没有找到才会从磁盘上找。
    • 特点：在LSM树上更新一次无需磁盘访问，在内存即可完成，速度远快于B+树，当数据访问以写操作为主，而读操作则集中在最近写入的数据上时，使用LSM树可以极大程度减少磁盘访问次数，加快访问速度。
• RAID vs. HDFS
  • RAID：磁盘冗余阵列，改善磁盘的访问延迟，增强可用性和容错能力，实现数据在多块磁盘上并发读写与数据备份。
  • HDFS(Hadoop分布式文件系统)：可看做在服务器集群上实现了类似RAID功能，不需要磁盘RAID。(系统在整个存储集群的多态服务器上进行数据并发读写与备份)。
    • 实现RAID1复制功能：以块为单位管理文件内容，一个文件分割为若干个Block，应用程序进行写文件时，写完一个Block，将将其自动复制到另外两台机器，保证Block有三个副本，这样即使两台服务器宕机，数据依然可访问。
    • 实现RAID0并发访问：对文本进行处理计算时，通过MapReduence并发计算任务框架，可启动多个计算子任务，同时读取多个文件的多个Block。

---

2.2、高可用【不同层、应用、服务、数据、软件发布、监控】

架构

高可用的网站架构：目的是保证服务器硬件故障时服务依然可用、数据依然保存并能够被访问。

主要手段：数据和服务的冗余备份及失效转移，一旦某些服务器宕机，就将服务切换到其他可用的服务器上，如果磁盘损坏，则从备份的磁盘读取数据。

不同层

针对于不同层保证高可用：

• 应用层：使用负载均衡设备将一组服务器组成一个集群共同对外提供服务，当负载均衡设备通过心跳检测等手段监控到某台应用服务器不可用时，就将其从集群列表中剔除，并将请求分发到集群中其他可用的服务器上，使集群保持可用，实现高可用。
• 服务层：同样也使用集群，这些服务器被应用层分布式服务框架访问，分布式服务调用框架会在应用层客户端程序中实现软件负载均衡，并通过注册中心来对提供服务的服务器进行心跳检测，若是发现服务不可用，则立即通知客户端程序修改服务访问列表，剔除不可用服务器。
• 数据层：需要在写入时进行数据同步复制，将数据写入到多态服务器上，实现数据冗余备份，一旦当数据库宕机时，应用程序将访问切换到备份数据的服务器上。

应用

高可用的应用：显著特点是应用的无状态性

1. 通过负载均衡进行无状态服务的失效转移：一旦某个服务不可用，负载均衡服务器会根据心跳检测发现该服务器失去响应，就会将其从列表剔除，紧接着之后将请求发送到其他服务器上。
2. 应用服务集群的session管理：事实上服务是有状态的，在集群环境下，session有如下几种管理方式：
   • Session复制：应用服务器开启web容器的session复制，在集群中的几台服务器之间同步session，使得所有的服务器都保存所有用户的session，这样任何一台服务器都不会导致session丢失，服务器使用时只需从本机获取即可。
     • 缺点：集群规模较大时，集群服务器之间大量通信进行session复制，占用大量资源，而且所有登陆用户在每台服务器上都有备份，那么就必然会出现服务器内存不够的情况。针对于大型网站核心应用集群就是数千台服务器，在线用户达千万，不适用这种方案。
   • Session绑定：通过负载均衡的源地址Hash算法，通过负载均衡服务器将同一IP请求分发到指定一台服务器上，此时就能够保证整个会话期间，用户所有请求都在同一台服务器上处理，该方式也称为会话粘滞。
     • 缺点：若是某台服务器宕机，那么该机器Session不存在，此时用户请求切换到其他机器上由于没有Session就无法完成业务处理。
   • 利用Cookie记录Session：将Session记录在客户端，每次发请求就携带session发到服务器。
     • 缺点：Cookie有大小限制；每次请求携带cookie影响性能；若是用户关闭cookie，那么访问就不正常。若是所需要记录的Session信息较少，也可以使用这种方式。
   • Session服务器：独立部署的Session服务器(集群)统一管理Session，应用服务器每次读取Session都会访问Session服务器。该解决方案就是对应用服务器状态分离，分为无状态服务器、有状态服务器，并根据是否有状态来设计架构。
     • 有状态Session服务器：利用分布式缓存、数据库等，在这些产品上封装，若是对Session有较高要求，利用Session服务器来集成单点登陆(SSO)、用户服务，需要开发专门的Session服务器。

服务

高可用的服务：无状态的服务，可使用类似负载均衡的失效转移策略，此外还有如下策略：

• 分级管理：根据应用是否核心、服务是否优先使用更好来对服务进行分级。不同服务在服务部署上也要进行必要的隔离，避免一个服务宕机产生连锁反应。
  • 低优先级的服务通过启动不同的线程或者部署在不同的虚拟机上进行隔离。
  • 高优先级的服务部署在不同的物理机上，核心服务和数据甚至需要部署到不同领域的数据中心。
• 超时设置：若是一个请求由于服务端的宕机、线程死锁问题导致长时间不能响应，那么就需要采取策略。
  • 策略：应用程序中设置服务调用超时时间，一旦超时，通信框架抛出异常，根据服务调度策略，来决定是重试还是将请求转移到其他提供相同服务的其他服务器上。
• 异步调用：举个例子若是一个注册功能，需要调用三个服务：①用户信息写入数据库。②发送账号注册成功邮件。③开通对应权限。若是同步调用，一旦中间步骤阻塞不能发送邮件时，会到之后其他两个服务也无法执行，导致用户注册失败。
  • 异步方式：用户进行注册发送请求，应用程序将注册信息发送给消息队列服务器后立即返回用户注册成功响应。接着对应三个服务操作分别从消息队列获取用户注册信息来异步执行。即使邮件服务队列阻塞，邮件不能成功发送，也不会影响其他服务执行，如邮件服务队列阻塞导致邮件不能成功发送，用户的注册操作依旧可以顺利完成，只是晚一点收到注册成功邮件而已。
  • 不适合异步：①获取用户信息，若是通过服务调用得不偿失。②对于必须确认服务调用成功才能继续下一步操作应用也不适用！
• 服务降级：网站访问高峰期，会有大量并发导致性能下降，严重导致宕机一些服务不可用。为保证核心应用的运行，需要对服务进行降级，两种手段如下：
  • 拒绝服务：①拒绝优先级低的应用，减少服务调用并发数，确保核心应用正常使用。②随机拒绝部分请求调用，节约资源，让一部分请求得以成功。
  • 关闭服务：直接关闭掉不重要的服务，目的是为重要服务功能让出资源。例如淘宝：在系统最繁忙的时段关闭"评价"、"确认收货"等非核心功能。
• 幂等性设计：对于应用调用服务失败后，会重新调用请求发送到其他服务器，该失败可能是虚假的失败。例如服务已经处理成功但是由于网络故障应用没有收到响应，这是应用重新提交请求导致服务重复调用，若是这个服务是转账操作，就会产生严重后果。
  • 方案：①数据库unique key，设置唯一主键id。②数据库乐观锁实现。③防重Token令牌(全局唯一Token，使用Redis来进行校验)。【流程：执行某个业务操作时，首先向服务器获取一个业务token，服务器生成token时在redis中进行存储后将token返回，紧接着拿这个token来进行业务请求，服务器会取到token来执行redis删除操作，若是删除成功表示第一次执行，失败表示重复执行，这里重复执行是针对于同一个token的业务请求】
  • 注意：并不是所有的接口都要进行幂等性校验，因为一些服务天然具有幂等性，例如用户性别修改设置，查询数据等等，但是对于转账交易、秒杀商品等操作，是需要进行幂等性校验的，这样才能够继续执行。

数据

高可用的数据：主要手段是数据备份和失效转移机制。涉及CAP原理（分别是可用、一致、伸缩性，一般采用CP，放弃C）。

• 数据一致性(Consisitency)、数据可用性(Availibility)、分区耐受性(Partition Tolerance)

1、数据备份

冷备：定期将数据备份到存储介质上物理保存，若是系统存储坏了，就从冷备设备中恢复数据。缺点是不能保证数据最终一致和数据可用性。

热备：分为异步热备、同步热备

• 异步热备：多份数据副本写入操作异步执行。对于热备操作是主服务写操作的代理模块通过异步线程同步到从服务器。在用户请求返回前，数据库写入操作一定完成。
• 同步热备：在用户请求返回前，数据库写入操作以及同步热步操作都完成。

2、失效转移：服务器集群中一旦一台服务器宕机，那么应用服务器针对这台服务器的所有读写操作路由到其他服务器上

三步骤如下：

1. 失效确认：通过心跳检测或应用程序访问失败记录，若是出现失败，需要再进行一次确认。一旦进行失效转移会进行后序一系列操作。
2. 访问转移：一旦确认宕机，就需要将读写请求路由到其他的服务器上。
   • 对于完全对等服务器(服务器存储数据一模一样，一般为主从)，则会直接根据配置进行路由切换；若是不对等，需要重新计算路由。
3. 数据恢复：从健康的服务器恢复数据，恢复到设定值。【原因是若是某台宕机，数据存储的副本数据就会减少，那么就一定要将数据恢复到设定值，防止之后再出现宕机造成数据永久丢失】

软件质量保证手段或措施

一般使用发布脚本来进行网站发布：①关闭负载均衡服务器上一台或一小批服务器。②关闭这些服务器，将软件代码上传启动。③接着打开负载均衡服务器之前关闭的服务器路由。(若是执行到这步还没发布完成，重复操作)

1、web自动化测试技术：工具如ThoughtWorks开发的Selenium(运行在浏览器，编写脚本模拟用户操作)，一些大公司会开发自己的测试工具来进行对全站网站的测试。

2、预发布验证：一般经过测试好的项目代码不会直接发布到一些负载均衡上的服务器里，而是先发布在预发布机器上(与实际对外开放的服务器一样，区别仅仅在于不对外开放只用于测试)，经过开发、测试工程师测试完成之后才会正式发布到服务器上。

• 可能造成问题：由于在预发布服务器运行的项目使用的是线上数据库的数据，在上面进行的测试不当就会造成线上问题。快速失败理念：一旦系统启动发现问题就立刻抛出异常，停止启动让工程师进行排查。

3、代码控制：主干开发、分支发布或分支开发、主干发布，一般网站采用分支开发，主干发布。(也就是要进行代码功能新增、修改新切一个分支，完成之后合并到主干，主干永远保持最新的版本来进行发布)

4、自动化发布：让发布成为流程化，尽量少的让人工进行干预。

5、灰度发布：针对于软件刚刚发布，就发现软件问题，此时需要发布回滚，卸载发布软件使其复原。

对于大网站可能有上万台服务器，这时候就要使用灰度发布的策略，每天只发布一部分服务器，后一天没问题再发布一部分，最终经过几天全部发布。

其他用途：也常用于用户测试，在部分服务器上发布新版本，比较用户对两个版本的满意度来确定最终的方案。

网站运行监控

要对发布上线的项目进行监控！

1、监控数据采集

1. 用户行为日志：①服务器端日志记录。②客户端浏览器日志收集(js脚本嵌入)。由于大型网站数据量惊人，需要网站逐步开发基于实时计算框架Storm的日志统计与分析工具。
2. 服务器性能检测：用于查看服务器性能指标，目前采用较广泛工具有Ganglia，支持大规模服务器集群。
3. 运行数据报告：监控一些业务场景相关技术与指标，如缓存命中率，平均响应延迟时间，每分钟发送邮件数，待处理任务总数。主要是在具体程序中(具体服务)中单独采集，汇总后进行统一显示。

2、监控管理：主要目的就是用于系统性能评估，来采取风控策略

• 系统警报：一旦超过阈值，通过邮件、手机短信、语音或其他方式来通知工程师或相关人员。
• 失效转移：一旦应用程序出现访问失败，进行失效转移。
• 自动优雅降级：关闭一些服务器非核心功能，来让服务器减少压力。

---

2.3、伸缩性【网站架构、应用服务器集群、分布式缓存集群、数据存储服务器集群】

大型网站的“大型”是指：

• 用户层面：大量用户及大量访问
• 功能方面：功能庞杂，产品众多
• 技术层面：网站需要部署大量的服务器

伸缩性的分为如下几个方面

• 网站架构的伸缩性设计

• • 不同功能进行物理分离实现伸缩
    • 纵向分离(分层后分离)：业务处理流程的不同部分分离。
    • 横向分离(业务分割后分离)：将不同的业务模块进行分离部署，粒度更小，甚至一个关键网页部署为一个独立服务。
  • 单一功能通过集群规模实现伸缩

• 应用服务器集群的伸缩性设计

• • HTTP 重定向负载均衡：DNS->负载均衡服务器，接着在负载均衡服务器中进行重定向返回给浏览器。
    • 问题：需要浏览器两次请求，性能差。重定向服务器自身处理能力称为瓶颈。若是HTTP302响应重定向可能造成SEO作弊，降低搜索排名，一般不用。
  • DNS 域名解析负载均衡：在DNS解析域名请求同时进行负载均衡处理。对应域名配对多个目标ip地址，通过负载均衡算法策略进行得出浏览器访问地址。
    • 常见手段：DNS域名服务器作为第一层负载均衡，部分负载均衡服务器作为第二层进行。
  • 反向代理负载均衡(在 HTTP 协议层面，应用层负载均衡)
  • IP 负载均衡(在内核进程完成数据分发)：响应后请求会经过负载均衡服务器。
    • 
  • 数据链路层负载均衡(数据链路层修改 mac 地址，三角传输模式，LVS)：响应数据不经过负载均衡服务器，直接返回给浏览器。【大型网站使用最广】
  • 负载均衡算法
    • 轮询(Round Robin, RR)：平均分配
    • 加权轮询(Weighted Round Robin, WRR)：在轮询基础上可进行配置权重，高性能的服务器分配更多请求。
    • 随机(Random)：随机分配。还有加权随机算法。
    • 最少链接(Least Connections)：记录每台服务器正在处理的连接数，找到目前最少连接数的服务器分配给它来进行处理。
    • 源地址散列(Source Hashing)：对IP地址进行Hash计算，让同一个ip地址的请求一直在对应同一台服务器进行处理。

• 分布式缓存集群的伸缩性设计

• • Memcached 分布式缓存集群的访问模型：通过Memcached 客户端来进行访问缓存服务器集群。
    • 组成：客户端（包括 API，路由算法，服务器列表，通信模块）；服务器集群
    • 
    • 写操作：应用程序输入写指令key:val => 路由算法模块(根据key与服务器列表模块计算得到编号) => 进行与服务器通信。
    • 读操作：过程与写同样，若是应用服务器提供相同的key，那么客户端总是会访问相同的服务器去读取数据。
  • Memcached 分布式缓存集群的伸缩性挑战：对分布式缓存集群进行弹性伸缩
    • 简单算法采用：余数Hash能够让集群均匀分布。 缺点：分布式缓存集群扩容会造成读取缓存命中概率一直失败。
      • 解决方案：在网站访问量较少情况时扩容缓存服务器集群，接着通过模拟请求方法进行预热缓存，将缓存服务器中数据重新分布，这对业务场景有要求，还需要技术团队通宵加班。
    • 改进路由算法，使新加入的服务器不影响大部分缓存数据正确命中：一致性Hash算法（一致性 Hash 环，虚拟层），通常使用二叉查找树实现。
      • 好处：新增机器时影响很小，命中率依旧很高。
      • 实践：一台物理服务器一般虚拟为150个服务器节点，实际根据集群规模和负载均衡进行精确需求。

• 数据存储服务集群的伸缩性设计

• • 关系数据库集群的伸缩性设计：数据复制，主存服务器、读写分离、分库。
  • NoSQL 数据库的伸缩性设计

---

2.4、可扩展【网站架构、分布式消息队列、分布式服务、数据结构、开放平台】

软件设计最具有挑战部分：分解系统的各个模块、如何定义各个模块的接口、如何复用组合不同的模块构造成一个完整的系统。

软件架构师价值·：其最大的价值不在于掌握多少先进的技术，而在于具有将一个大系统切分为N个低耦合的子模块的能力，这些子模块包含横向业务模块，也包含纵向的基础模块。能力主要来源于专业技术与经验，还有一部分源自架构师对业务场景的理解、对人性的把握、甚至对世界的认知。

系统架构设计层面的开闭原则：

1、构建可扩展的网站架构

2、利用分布式消息队列降低耦合性

• 事件驱动架构(Event Driven Architecture)

• 分布式消息队列

3、利用分布式服务打造可复用的业务平台

• Web Service 与企业级分布式服务

  • 原理过程：服务提供者通过WSDL向注册中心描述自身提供服务接口属性，注册中心使用UDDI发布服务提供者的服务，服务请求者从注册中心检索服务后通过SOAP和服务提供者通信。
  • 缺点：臃肿注册与发现机制；低效的XML序列化手段；开销较高的HTTP远程通信；复杂部署与维护。

• 大型网站分布式服务的需求及特点：服务注册、发现、服务调用；负载均衡、失效转移、高效远程通信、整合异构系统(不同语言)、对应用最少侵入、版本管理、实时监控。

• 分布式服务框架设计(Thrift, Dubbo)：最简单、高效分布式服务框架采用SOA

4、可扩展的数据结构(如 ColumnFamily设计)：无需修改表结构添加字段，无需像关系型数据库一样要提前设置多个字段。

5、利用开放平台建设网站生态圈：提供更多的增值服务才能够赚钱，方式有围绕对应业务展开一些增值业务，将一些内部服务封装成一些调用接口进行开放。让网站、用户、开发者相互形成依赖，形成一个生态圈。

---

2.5、网站安全架构【攻击、信息加密、信息过滤】

XSS 攻击和 SQL 注入攻击是构成网站应用攻击最主要的两种手段，此外还包括 CSRF,Session 劫持等手段。

1、攻击与防御

• XSS 攻击：跨站点脚本攻击（Cross Site Script）。①反射性，诱使点击url恶意脚本。②持久性，存储到数据库。
  • XSS 防御手段：①消毒：过滤HTML危险字符。②设置HttpOnly的cookie属性，避免被工具脚本窃取，用于防窃取。
• 注入攻击：①SQL注入(手段有借助开源、错误回显、盲注、消毒、参数绑定)。②OS注入（操作系统命令注入（也称为外壳程序注入））
  • 注入防御：避免盲猜数据库表名、正则匹配过滤、预编译手段(恶意SQL会当做SQL的参数)
• CSRF 攻击：跨站点请求伪造（Cross Site Request Forgery），利用跨站请求，借助浏览器Cookie与Session来盗取用户身份进行请求。
  • CSRF 防御：主要手段是识别请求者身份。①表单Token(每次页面刷新就会刷新token，每次请求携带token来进行校验身份)。②验证码(应当在必要时使用)。③Referer check（检查referer字段，实现图片防盗链）。
• 其他攻击和漏洞：①ErrorCode(根据异常页来查找漏洞)。②HTML注释(给出一些提示信息)。③文件上传(上传exe可执行文件)。④遍历目录(遍历系统未开放的文件与目录)
  • 防御方式：①尽量避免有异常页出现，一般都是返回code码。②借助代码扫描工具，避免HTML注释漏洞。③设置上传文件白名单，只允许上传可靠文件类型。④将资源文件独立部署服务器，使用独立域名。其他文件不使用静态URL访问，动态参数不包含文件路径信息。
• Web 应用防火墙（如ModSecurity、NEC的SiteShell）：意义就是在外部请求访问我们应用服务器时先会经过对应的web应用防火墙执行引擎。
• 网站安全漏洞扫描：根据内置规则，构造具有攻击性的URL。

2、信息加密技术及密钥安全管理

方式一：单向散列加密，不同输入长度的信息通过散列计算得到固定长度的输出，不可逆。

• 算法如MD5、SHA。加强安全可以进行加盐加密。
• 场景：数据库用户密码加密。

方式二：对称加密。对大量数据文件使用一个密钥加密，一旦密钥丢失，就会造成很大的后果。

• 算法如DES、RC算法。
• 场景：信息需要安全交换或存储场合，如Cookie加密、通信加密。适用于绝大多是加密场合。

方式三：非对称加密。开放公钥，私有只在服务端存储用于解密。

• 算法如RSA。
• 场景：HTTPS浏览器数字证书，一般用于信息安全传输、数字签名加密。

密钥安全管理：①密钥算法放在单独服务器上，通过调用服务来加密解密，密钥专人保管。(缺点是造成性能瓶颈) ②加解密算法放在应用系统里，密钥放在独立服务器上，密钥存储方式是将其进行切割成数片放在不同存储介质里。

3、信息过滤与反垃圾

• 文本匹配：匹配敏感词。实现有Trie树，空间时间复杂度较好是双数组Trie算法。另一种方式是构造多级Hash表进行文本匹配。对于如阿_拉_伯需要进行降噪。
• 分类算法：针对广告贴、垃圾邮件。使用分类算法结合分类模型进行，如贝叶斯分类算法(解决概率论的一个算法)。
• 黑名单：对于过滤需求精确使用Hash表。不太精确可使用布隆过滤器。

---

实际案例

微博

微博发布业务：

初期【同步推】：用户发表微博后系统会立即将这条微博插入到所有粉丝列表。若是用户量比较大，如明星发布微博就会引起大量数据库写操作，超出数据库负载，系统性能急剧下降。
改进【异步推拉结合】：①用户发表后系统将微博写入消息队列后立即返回(加快用户响应速度)。②消费队列消费者任务将微博推送给所有当前在线粉丝队列后立即返回。③对于非在线用户登录再根据列表拉取微博订阅列表。

微博频繁刷新：

采用多级缓存策略，热门微博和明星用户微博缓存在所有微博服务器上；在线用户的微博和近期微博缓存在分布式缓存集群上。
效果：对于微博操作中刷微博操作，几乎全部都是对缓存进行访问，可获取良好系统性能。

…待补充

---

参考文章

[1]. 大型网站技术架构-全面梳理

[2]. 图解大型网站技术架构的历史演化过程

安全

• 验证HTTP Referer字段
  reid=cf7d2bae1609e403427481bea052cae9#rd)

[2]. 图解大型网站技术架构的历史演化过程

安全

• 验证HTTP Referer字段
• Referer原理与图片防盗链实现方法详解