江苏龙网

  1. 主页 > 生活百科 > >

互联网架构演化( 二 )

互联网架构

应用集群化，会面临很多挑战，主要的焦点是如何有效的分配用户请求 。
3.1 DNS 轮询
首先要解决的问题便是，用户如何将请求发送到不同的 Nginx 中，最常见的方式便是 DNS 轮询 。

大多域名注册商都支持多条 A 记录的解析，其实这就是 DNS 轮询，DNS 服务器将解析请求按照 A 记录的顺序，逐一分配到不同的 IP 上，这样就完成了简单的负载均衡 。
 
3.2 负载均衡器
这里的负载均衡器主要指的是 Nginx 的反向代理功能 。当用户请求发送到 Nginx 后，Nginx 需要决定将请求转发到哪台应用服务器上 。
反向代理（Reverse Proxy）是指以代理服务器来接受 internet 上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给 internet 上请求连接的客户端，此时代理服务器对外就表现为一个反向代理服务器 。
 
Nginx 对于后台服务器配置比较灵活，可以同时配置多台服务器，并根据负载策略将请求分发给后台服务器 。
3.3 会话问题
在单机时代，我们的请求只会发送到同一台机器上，不存在会话问题 。当将应用集群部署时，用户的多次请求会发送到不同的应用服务器上 。此时，如何对会话进行同步便是棘手问题 。
3.3.1 Session Sticky
这种方案主要由 Nginx 处理，让同样 session 请求每次都发送到同一台服务器进行处理 。
互联网架构演化

文章插图
 
 
Nginx 会将相同用户的请求发送到同一台应用服务器中 。
 
这是最简单的策略，但存在一定的问题：
  1. Web 服务器重启 Session 丢失；
  2. 负载均衡需要进行应用层解析（第7层），性能损耗较大；
  3. 负载均衡器变为一个有状态的点，不易容灾；
3.3.2 Session Replication
会话问题的根源在于 Session 由多个应用维护，我们可以使用某种机制，在多台 Web 服务间进行 Session 的数据同步 。
互联网架构演化

文章插图
 
 
由 Session 同步器在各个 Java 应用程序间完成 Session 的同步，最终使每个服务器中都存在所有用户的 Session 数据 。
 
这个方案的问题：
  1. 造成网络开销；
  2. 每台 Web 服务器都保存所有的 Session，内存开销大；
3.3.3 集中式Session
我们可以将 Session 从 Web 服务中抽取出来，并对其进行集中存储 。
互联网架构演化

文章插图
 
 
将 Session 信息保存到 Session 存储集群中，Java 应用程序不在负责 Session 的存储 。
 
这个方案的问题：
  1. 读取Session引入了网络开销；
  2. 存储设施问题影响应用；
3.3.4 Cookie Based Session
还可以将 session 数据放在 cookie 中，然后在 Web 服务器上从 cookie 中生成对应的 Session 数据 。
互联网架构演化

文章插图
 
 
将 Session 数据编码到 Cookie 中，每次 Java 应用程序使用 Session 时，都从 Cookie 中重建 Session 。
 
该方案的问题：
  1. 受到 Cookie 大小的限制；
  2. 存在安全性问题；
  3. 每次都携带巨大的 Cookie，带宽消耗严重；
  4. 每次都进行 Session 数据恢复，加大应用服务器的负担；
随着系统访问量的持续增加，面对大量的数据读取请求，数据库有些不堪重负 。
此时，我们需要对数据库进行优化 。
 
4 数据库读写分离
通常情况下，数据库的读会帅选成为系统的瓶颈 。对此，我们可以使用数据库主从机制，通过添加多个从库来减缓读压力 。
互联网架构演化

文章插图
 
 
与之前部署相比，该架构只是为数据库增加了若干个从库：
  1. 对数据库实施 主从 部署策略；
  2. 对于数据的写请求，只能在 主库 上进行；
  3. 对于数据的读请求，可以在任意的 从库 上进行；
  4. 主库与从库间，通过 数据库同步策略 进行数据同步 。
由于主库与从库间的数据同步需要时间，会出现数据不一致的情况，这块是业务上需要慎重考虑的一点 。


推荐阅读


上一篇：天龙八部真实实力排名 天龙八部武功最厉害的是谁

下一篇：体型最大的狮子是什么狮? 狮子高多少米