1. 网站架构的伸缩性设计
1.1. 不同功能进行物理分离实现伸缩
纵向分离（分层后分离）：将业务处理流程上的不同部分分离部署，实现系统伸缩性。
横向分离（业务分割后分离）：将不同的业务模块分离部署，实现系统伸缩性。
1.2. 单一功能通过集群规模实现伸缩
将不同功能分离部署可以实现一定程度的伸缩性，但是随着网站的访问量逐步增加，即使分离到最小粒度的独立部署，单一的服务器也不能满足业务规模的要求。因此必须使用服务器集群，即将相同服务部署在多态服务器上构成一个集群整体对外提供服务。
2. 应用服务器集群的伸缩性设计
2.1. HTTP 重定向负载均衡
利用 HTTP 重定向协议实现负载均衡。
这种负载均衡方案的优点是比较简单。缺点是浏览器需要两次请求服务器才能完成一次访问，性能较差：重定向服务器自身的处理能力有可能成为瓶颈，整个集群的伸缩性规模有限；使用 HTTP 302 响应码重定向，可能使搜索引擎判断为 SEO 作弊，降低搜索排名。
2.2. DNS 域名解析负载均衡
利用 DNS 处理域名解析请求的同时进行负载均衡处理的一种方案。
在 DNS 服务器中配置多个 A 记录，如：
114.100.40.1 www.mysite.com 114.100.40.2 www.mysite.com 114.100.40.3 www.mysite.com
每次域名解析请求都会根据负载均衡算法计算一个不同的 IP 地址返回，这样 A 记录中配置的多个服务器就构成一个集群，并可以实现负载均衡。
DNS 域名解析负载均衡的优点：
- 将负载均衡的工作转交给了 DNS，省掉了网站管理维护的麻烦。
- 同时，许多 DNS 服务器还支持基于地理位置的域名解析，即将域名解析成距离用户地理最近的一个服务器地址，这样可以加快用户访问速度，改善性能。
DNS 域名解析负载均衡的缺点：
- DNS 是多级解析，每一级 DNS 都可能缓存 A 记录，当某台服务器下线后，即使修改了 DNS 的 A 记录，要使其生效也需要较长时间。这段时间，依然会域名解析到已经下线的服务器，导致用户访问失败。
- DNS 的负载均衡的控制权在域名服务商那里，网站无法对其做更多改善和更强大的管理。
2.3. 反向代理负载均衡
大多数反向代理服务器同时提供反向代理和负载均衡的功能。
反向代理服务器的优点是部署简单。缺点是反向代理服务器时所有请求和响应的中转站，其性能可能会成为瓶颈。
2.4. IP 负载均衡
在网络层通过修改请求目标地址进行负载均衡。负载均衡服务器（网关服务器）在操作系统内核获取网络数据包，根据负载均衡算法计算得到一台真实 Web 服务器 10.0.0.1，然后将目的 IP 地址修改为 10.0.0.1，不需要通过用户进程。真实 Web 服务器处理完成后，响应数据包回到负载均衡服务器，负载均衡服务器再将数据包原地址修改为自身的 IP 地址（114.100.80.10）发送给浏览器。
IP 负载均衡在内核完成数据分发，所以处理性能优于反向代理负载均衡。但是因为所有请求响应都要经过负载均衡服务器，集群的最大响应数据吞吐量受制于负载均衡服务器网卡带宽。
2.5. 数据链路层负载均衡
数据链路层负载均衡是指在通信协议的数据链路层修改 mac 地址进行负载均衡。
这种方式又称作三角传输方式，负载均衡数据分发过程中不修改 IP 地址，只修改目的 mac 地址，通过配置真实物理服务器集群所有机器虚拟 IP 和负载均衡服务器 IP 地址一致，从而达到不修改数据包的源地址和目的地址就可以进行数据分发的目的，由于实际处理请求的真实物理服务器 IP 和数据请求目的 IP 一致，不需要通过负载均衡服务器进行地址转换，可将响应数据包直接返回给用户浏览器，避免负载均衡服务器网卡带宽成为瓶颈。这种负载方式又称作直接路由方式。
在 Linux 平台上最好的链路层负载均衡开源产品是 LVS(Linux Virtual Server)。
2.6. 负载均衡算法
负载均衡服务器的实现可以分为两个部分：
- 根据负载均衡算法和 Web 服务器列表计算得到集群中一台 Web 服务器的地址。
- 将请求数据发送到该地址对应的 Web 服务器上。
负载均衡算法通常有以下几种：
- 轮询（Round Robin） - 所有请求被依次分发到每台应用服务器上，即每台服务器需要处理的请求数据都相同，适合于所有服务器硬件都相同的场景。
- 加权轮询（Weighted Round Robin） - 根据服务器硬件性能情况，在轮询的基础上，按照配置权重将请求分发到每个服务器，高性能服务器能分配更多请求。
- 随机（Random） - 请求被随机分配到各个应用服务器，在许多场合下，这种方案都很简单实用，因为好的随机数本身就很平均，即使应用服务器硬件配置不同，也可以使用加权随机算法。
- 最少连接（Least Connection） - 记录每个应用服务器正在处理的连接数，将新到的请求分发到最少连接的服务器上，应该说，这是最符合负载均衡定义的算法。
- 源地址 Hash（Source Hash） - 根据请求来源的 IP 地址进行 Hash 计算，得到应用服务器，这样来自同一个 IP 地址的请求总在同一个服务器上处理，该请求的上下文信息可以存储在这台服务器上，在一个会话周期内重复使用，从而实现会话粘滞。
3. 分布式缓存集群的伸缩性设计
一致性 HASH 算法
4. 数据存储服务器集群的伸缩性设计
4.1. 关系型数据库的伸缩性设计
- 主从复制 - 主流关系型数据库一般都支持主从复制。
- 分库 - 根据业务对数据库进行分割。制约条件是跨库的表不能进行 Join 操作。
- 分表 - 使用数据库分片中间件，如 Cobar 等。
4.2. NoSql 数据库的伸缩性设计
一般而言，Nosql 不支持 SQL 和 ACID，但是强化了对于高可用和伸缩性的支持。
欢迎工作一到五年的Java工程师朋友们加入Java程序员开发： 721575865
群内提供免费的Java架构学习资料（里面有高可用、高并发、高性能及分布式、Jvm性能调优、Spring源码，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多个知识点的架构资料）合理利用自己每一分每一秒的时间来学习提升自己，不要再用"没有时间“来掩饰自己思想上的懒惰！趁年轻，使劲拼，给未来的自己一个交代！
