《大型网站技术架构》读书笔记6 架构-网站的伸缩性架构

网站的伸缩性架构

• 网站的伸缩性指不需要改变网站的软硬件设计，仅仅通过改变部署的服务器数量就可以扩大或者缩小网站的服务处理能力。
• 大型网站的“大型”，在用户层面可以理解为大量用户及大量访问；在技术层面可以理解为网站部署大量的服务器。
• 只要技术上能做到向集群中加入服务器的数量和集群的处理能力成线性关系，那么网站就可以以此手段不断提升自己的规模。

网站架构的伸缩性设计

• 分为两类：一类是根据功能进行物理分离实现伸缩，不同的单个服务器部署不同的服务，提供不同的功能；一类是单一功能通过集群实现伸缩，集群内的多台服务器部署相同的服务，提供相同的功能。

不同功能进行物理分离实现伸缩

• 不仅可以用在网站发展的早期，而且可以在网站发展的任何阶段使用。
• 纵向分离（分层后分离）：将业务处理流程上的不同部分分离部署，实现系统伸缩性。
• 横向分离（业务分割后分离）：将不同的业务模块分离部署，实现系统伸缩性。每个页面都可以独立部署，专门维护。

单一功能通过集群规模实现伸缩

• 将相同服务部署在多台服务器上构成一个集群整体对外提供服务。
• 集群伸缩性可分为：应用服务器集群伸缩性和数据服务器集群伸缩性。
• 数据服务器集群可分为：缓存数据服务器集群和存储数据服务器集群。

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

• 所有服务器都部署相同应用的应用服务器集群
• 采用负载均衡可实现应用服务器伸缩性
• 负载均衡SLB（Server Load Balancer）是一种对流量进行按需分发的服务，通过将流量分发到不同的后端服务器来扩展应用系统的吞吐能力，并且可以消除系统中的单点故障，提升应用系统的可用性。
• 负载均衡服务器，即HTTP请求分发装置，可以感知或者可以配置集群的服务器数量，可以及时发现集群中新上线或下线的服务器，并能向新上线的服务器分发请求，停止向已下线的服务器分发请求。
• 负载均衡服务器的实现可以分成两个部分：

1. 根据负载均衡算法和web服务器列表计算得到集群中一台web服务器地址
2. 将请求数据发送到该地址对应的web服务器上

• 开源软件负载均衡: Nginx, LVS, Haproxy (Nginx和Haproxy通常做七层负载均衡, LVS做四层负载均衡. 但是Nginx也可以通过stream模块做四层负载均衡, Haproxy也可以做四层负载均衡 )
• 商业的硬件负载均衡: 设备F5、Netscale ;
• 负载均衡（Load Balance）建立在现有网络结构之上，它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。
• 目前负载均衡技术大多数是用于提高诸如在Web服务器、FTP服务器和其它关键任务服务器上的Internet服务器程序的可用性和可伸缩性。
• 负载均衡分类：
  1）二层负载均衡（mac）
  根据OSI模型分的二层负载，一般是用虚拟mac地址方式，外部对虚拟MAC地址请求，负载均衡接收后分配后端实际的MAC地址响应.
  2）三层负载均衡（ip）
  一般采用虚拟IP地址方式，外部对虚拟的ip地址请求，负载均衡接收后分配后端实际的IP地址响应. (即一个ip对一个ip的转发, 端口全放开)
  3）四层负载均衡（tcp）
  在三次负载均衡的基础上，即从第四层"传输层"开始, 使用"ip+port"接收请求，再转发到对应的机器。
  4）七层负载均衡（http）
  从第七层"应用层"开始, 根据虚拟的url或IP，主机名接收请求，再转向相应的处理服务器。
• 四层的负载均衡就是基于IP+端口的负载均衡：在三层负载均衡的基础上，通过发布三层的IP地址（VIP），然后加四层的端口号，来决定哪些流量需要做负载均衡，对需要处理的流量进行NAT处理，转发至后台服务器，并记录下这个TCP或者UDP的流量是由哪台服务器处理的，后续这个连接的所有流量都同样转发到同一台服务器处理。
  对应的负载均衡器称为四层交换机（L4 switch），主要分析IP层及TCP/UDP层，实现四层负载均衡。此种负载均衡器不理解应用协议（如HTTP/FTP/MySQL等等）。
  实现四层负载均衡的软件有：
  F5：硬件负载均衡器，功能很好，但是成本很高。
  lvs：重量级的四层负载软件
  nginx：轻量级的四层负载软件，带缓存功能，正则表达式较灵活
  haproxy：模拟四层转发，较灵活
• 七层的负载均衡就是基于虚拟的URL或主机IP的负载均衡：在四层负载均衡的基础上（没有四层是绝对不可能有七层的），再考虑应用层的特征，比如同一个Web服务器的负载均衡，除了根据VIP加80端口辨别是否需要处理的流量，还可根据七层的URL、浏览器类别、语言来决定是否要进行负载均衡。举个例子，如果你的Web服务器分成两组，一组是中文语言的，一组是英文语言的，那么七层负载均衡就可以当用户来访问你的域名时，自动辨别用户语言，然后选择对应的语言服务器组进行负载均衡处理。
  对应的负载均衡器称为七层交换机（L7 switch），除了支持四层负载均衡以外，还有分析应用层的信息，如HTTP协议URI或Cookie信息，实现七层负载均衡。此种负载均衡器能理解应用协议。
  实现七层负载均衡的软件有：
  haproxy：天生负载均衡技能，全面支持七层代理，会话保持，标记，路径转移；
  nginx：只在http协议和mail协议上功能比较好，性能与haproxy差不多；
  apache：功能较差
  Mysql proxy：功能尚可。
  总的来说，一般是lvs做4层负载；nginx做7层负载(也能做4层负载, 通过stream模块)；haproxy比较灵活，4层和7层负载均衡都能做。
• 四层负载均衡和七层负载均衡之间的区别
  -七层负载均衡基本都是基于http协议的，适用于web服务器的负载均衡。在中间传输层执行，它处理消息的传递，但不考虑消息的内容。（nginx）
  -四层负载均衡主要是基于tcp协议报文，可以做任何基于tcp/ip协议的软件的负载均衡。在高级应用层上执行，会处理每个消息的实际内容。(haproxy、LVS)

负载均衡技术

• HTTP重定向负载均衡：利用HTTP重定向协议实现负载均衡。nginx就采用的这个负载均衡技术
  
  优点：比较简单
  缺点：浏览器需要两次请求服务器才能完成一次访问，性能较差
• DNS域名解析负载均衡：利用DNS处理域名解析请求的同时进行负载均衡处理
  
  优点：将负载均衡的工作转交给DNS，省掉了网站管理维护负载均衡服务器的麻烦，同时许多DNS还支持基于地理位置的域名解析，即会将域名解析成距离用户地理最近的一个服务器地址，这样可加快用户访问速度，改善性能。
  缺点：目前的DNS是多级解析，每一级DNS都可能缓存A记录，当下线某台服务器后，即使修改了DNS的A记录，要使其生效也需要较长时间，这段时间，DNS依然会将域名解析到已经下线的服务器，导致用户访问失败；而且DNS负载均衡的控制权在域名服务商那里，网站无法对其做更多改善和更强大的管理。
• 反向代理负载均衡：可利用反向代理缓存资源，以改善网站性能。大多数反向代理服务器同时提供负载均衡的功能，管理一组Web服务器，将请求根据负载均衡算法转发到不同Web服务器上。Web服务器处理完成的响应也需要通过反向代理服务器返回给用户。反向代理服务器则需要配置双网卡和内部外部两套IP地址。
  
  优点：其是和反向代理服务器功能集成在一起，部署简单。
  缺点：反向代理服务器是所有请求和响应的中转站，其性能可能会成为瓶颈。
• IP负载均衡：在网络层通过修改请求目标地址进行负载均衡。
  
  优点：IP负载均衡在内核进程完成数据分发，较反向代理负载均衡（在应用程序中分发数据）有更好的处理性能。
  缺点：所有请求响应都需要经过负载均衡服务器，集群的最大响应数据吞吐量不得不受制于负载均衡服务器网卡带宽。
• 数据链路层负载均衡：在通信协议的数据链路层修改mac地址进行负载均衡。这种数据传输方式又称为三角传输模型。这种负载均衡方式又称为直接路由方式（DR）。目前大型网站使用最广的一种负载均衡手段。
  
  优点：将响应数据包直接返回给用户浏览器，避免负载均衡服务器网卡带宽成为瓶颈。
  缺点：。

负载均衡算法

• 轮询（Round Robin，RR）所有请求被依次分发到每台应用服务器上，即每台服务器需要处理的请求数目都相同，适合于所有服务器硬件都相同的场景。
• 加权轮询（Weighted Round Robin，WRR）根据应用服务器硬件性能的情况，在轮询的基础上，按照配置的权重将请求分发到每个服务器，高性能的服务器能分配更多请求。
• 随机（Random）请求被随机分配到各个应用服务器，在许多场合下，这种方案都很简单实用，因为好的随机数本身就很均衡。即使应用服务器硬件配置不同，也可以使用加权随机算法。
• ** 最少连接**（Least Connections）记录每个应用服务器正在处理的连接数（请求数），将新到的请求分发到最少连接的服务器上，应该说，这是最符合负载均衡定义的算法。同样，最少连接算法也可以实现加权最少连接。
• 源地址散列（Source Hashing）根据请求来源的IP地址进行Hash计算，得到应用服务器，这样来自同一个IP地址的请求总在同一个服务器上处理，该请求的上下文信息可以存储在这台服务器上，在一个会话周期内重复使用，从而实现会话黏滞。

nginx负载均衡的实现方式
轮询、加权轮询、最少连接、源地址散列iphash、
fair（按后端服务器的响应时间来分配请求，响应时间短的优先分配）

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

• 分布式缓存服务器集群中不同服务器中缓存的数据各不相同，缓存访问请求不可以在缓存服务器集群中的任意一台处理，必须先找到缓存有需要数据的服务器，然后才能访问。
• 新加入缓存服务器后应使整个缓存服务器集群中已经缓存的数据尽可能还被访问到，这是分布式缓存集群伸缩性设计的最主要目标。
• Memcached分布式缓存访问模型：路由算法负责根据应用程序输入的缓存数据KEY计算得到应该将数据写入到Memcached的哪台服务器（写缓存）或者应该从哪台服务器读数据（读缓存）。
  
  一致性Hash算法
• 通过一个叫做一致性Hash环的数据结构实现KEY到缓存服务器的Hash映射。
  
• 具体算法过程为：先构造一个长度为0_{232的整数环（这个环被称作一致性Hash环），根据节点名称的Hash值（其分布范围同样为0}232）将缓存服务器节点放置在这个Hash环上。然后根据需要缓存的数据的KEY值计算得到其Hash值（其分布范围也同样为0~232），然后在Hash环上顺时针查找距离这个KEY的Hash值最近的缓存服务器节点，完成KEY到服务器的Hash映射查找。
  新加入的节点只影响整个环中的一小段，如下图深色一段。
  
• 随着集群规模越大，继续命中原有缓存数据的概率也逐渐增大，100台服务器扩容增加1台服务器，继续命中的概率是99%。虽然仍有小部分数据缓存在服务器中不能被读到，但是这个比例足够小，通过访问数据库获取也不会对数据库造成致命的负载压力。

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

• 数据存储服务器必须保证数据的可靠存储，任何情况下都必须保证数据的可用性和正确性。
• 可分为关系数据库集群的伸缩性设计和NoSQL数据库的伸缩性设计
• 关系数据库集群的伸缩性设计
  使用数据复制的MySQL集群伸缩性方案
  
  MySQL分库分表的伸缩性方案
  目前网站在线业务应用中比较成熟的支持数据分片的分布式关系数据库产品主要有开源的Amoeba和Cobar.
  Cobar部署模型
  
  Cobar系统组件模型
  
  Cobar的伸缩有两种：Cobar服务器集群的伸缩和MySQL服务器集群的伸缩。
  Cobar服务器可以看作是无状态的应用服务器，因此其集群伸缩可以简单使用负载均衡的手段实现。而MySQL中存储着数据，要想保证集群扩容后数据一致负载均衡，必须要做数据迁移，将集群中原来机器中的数据迁移到新添加的机器中。
  具体迁移哪些数据可以利用一致性Hash算法（即路由模块使用一致性Hash算法进行路由），尽量使需要迁移的数据最少。
  实践中，Cobar利用了MySQL的数据同步功能进行数据迁移，迁移以Schema为单位。
  
  应用程序通过Cobar访问分布式关系数据库，性能基本和直接访问关系数据库相当，可以满足网站在线业务的实时处理需求。
• NoSQL数据库集群的伸缩性设计
  HBase的伸缩性主要依赖其可分裂的HRegion及可伸缩的分布式文件系统HDFS实现。