CDN与Load Balance（负载均衡）

CDN工作机制：

内容分发网络(Content Delivery Network)。构筑在现有Internet上的一种先进的流量分配网络。

目的是在现有Internet中增加一层新的网络架构，将网站的内容分不到最接近用户的网络“边缘”，提高用户访问网站的响应速度，有点类似于“镜像”，但其有负载均衡的特点。

CDN = Cache（缓存） + Mirror（镜像） + GSLB（整体负载均衡）

目前CDN都以缓存网站中的静态数据为主，如CSS、JS、图片和静态页面等数据。

CDN架构

CDN.PNG

如图所示，以用户访问某个静态文件（如CSS），域名为cdn.taobao.com，首先向LDNS请求，经过迭代解析后回到Name Server解析，一般每个公司都会有一个DNS解析服务器，这个DNS解析服务器通常会把它重新CNAME解析到另一个域名，这个域名最终会被指向CDN全局中的DNS负载均衡服务器，再由这个GTM来最终分配是哪个地方的访问用户，返回给离此访问用户最近的CDN节点，若在此节点找不到文件，将回到源站去获取

负载均衡Load Balance

目的：提高服务器相应速度并利用效率，避免单点失效，解决网络拥塞问题，实现地理位置无关性，为用户提供较一致的访问质量

3种负载均衡架构：

• 链路负载均衡（基于DNS）

LB1.PNG

即DNS解析为不同IP，用户通过IP访问不同服务器，负载均衡由DNS解析控制
优点：用户会直接访问目标服务器，不经过代理服务器，访问速度会更快
缺点：DNS在用户本地和LDNS均有缓存，一旦某台Web Server挂掉，将很难及时更新用户域名解析结构，导致用户无法访问域名（配置修改后，生效不及时）

• 集群负载均衡

  分为硬件负载和软件负载

  • 硬件负载

LB2.PNG

使用一台专门硬件设备转发请求，比如大名鼎鼎的 F5 Network Big-IP，性能好，但价格昂贵，负载均衡的算法方面还支持很多灵活的策略，同时还具有一些防火墙等安全功能，不能动态扩容（无法面对访问量陡然增大超出服务极限问题）

• 软件负载

  
  
  

  LB3.PNG
  
  

  最普遍的方式，直接使用PC搭建，但一般一次访问请求要经过多次代理服务器，增加网络延时，需要投入技术优化成本

• OS负载均衡

  利用OS级别的软中断或者硬件中断达到负载均衡

在Web服务或者分布式数据集群后两种使用多一些

负载均衡算法

在有负载均衡的以上几种架构后，那么选择哪一台服务器也是需要一定算法的，有以下几种经典的算法：

• 轮询策略

  实际应用中，轮询也会有多种方式，有按顺序轮询的、有随机轮询的、还有按照权重来轮询的。前两种比较好理解，第三种按照权重来轮询，是指给每台后端服务设定一个权重值，比如性能高的服务器权重高一些，性能低的服务器给的权重低一些，这样设置的话，分配流量的时候，给权重高的更多流量，可以充分的发挥出后端机器的性能。

• 负载度策略

  负载度策略是指当「负载均衡器」往后端转发流量的时候，会先去评估后端每台服务器的负载压力情况，对于压力比较大的后端服务器转发的请求就少一些，对于压力比较小的后端服务器可以多转发一些请求给它。

  这种方式也带来了一些弊端，因为需要动态的评估后端服务器的负载压力，那这个「负载均衡器」除了转发请求以外，还要做很多额外的工作，比如采集 连接数、请求数、CPU负载指标、IO负载指标等等，通过对这些指标进行计算和对比，判断出哪一台后端服务器的负载压力较大。

• 响应策略

  响应策略是指，当用户请求过来的时候，「负载均衡器」会优先将请求转发给当前时刻响应最快的后端服务器（不管服务器负载度、配置）

• 哈希策略

  将请求中的某个信息进行hash计算，然后根据后端服务器台数取模，得到一个值，算出相同值的请求就被转发到同一台后端服务器中。

  常见的用法是对用户的IP或者ID进行这个策略，然后「负载均衡器」就能保证同一个IP来源或者同一个用户永远会被送到同一个后端服务器上了，一般用于处理缓存、会话等功能的时候特别好用。

参考：

《深入分析Javaweb技术内幕》