这次笔记主写接入层,根据我们的实际项目出发,经验浅薄,可能有不对之处,还望指出。下回写逻辑层和存储层相关的笔记。

首先要知道我们的目的是什么?

  • 保证系统的7*24小时可用
  • 保证用户访问响应时间
  • 保证系统的安全性
  • 统一接入层,规范应用系统部署

  一般而言,有Nginx就可以了,但当流量具有一定规模时候,这样的架构就变得不稳定了,如:用户响应时间过长、偶尔来个瘫痪什么的。所以为了提高可用性及整体的吞吐量,会引入接入层,这里使用LVS四层负载均衡,DNS解析到LVS的IP地址,然后LVS转发至Nginx,最后到后端的RS。如图:

数据共享平台应用架构图_运维

很多公司都是从开始的单点服务,即一台服务搞定了一切->到后来服务隔离,引入Nginx,保证高可用->Nginx/LVS/F5/HAProxy 进行负载均衡,还有分流、削峰填谷、热点缓存,这些东西下个笔记会涉及颇多。
我们接着看这张:

数据共享平台应用架构图_数据共享平台应用架构图_02

  看完这张图你或许会无语,为什么这么搞?LVS+HAProxy+Nginx 这几个好像可以做同样的事情,目前使用最广泛的三种负载均衡软件都被你们用了,有没有?其实不然,这层架构体系,也是运维部根据公司具体的业务流量迭代出来的。

  先看下访问过程:

  1. 用户在浏览器输入域名回车
  2. 如果本地缓存里没有该域名对应的ip地址(浏览器缓存+本地缓存,谷歌浏览器中输入:chrome://net-internals/#dns  看到缓存页面,本地的缓存在hosts中)
  3. 那么到DNS进行域名解析,DNS将域名的解析权交给CNAME指向的CDN专用DNS服务器
  4. 为了得到实际IP,浏览器向CDN的全局负载均衡设备发起内容URL访问请求。
  5. 全局负载均衡DNS根据用户IP,将当时最接近的节点IP返回给用户浏览器(这里不考虑CDN中设置的URL相关策略)
  6. 浏览器得到IP,进行访问,然后到LVS这层。

请求的响应不走LVS。项目实施LVS/DR+Keepalived实现双机热备。

  HAProxy实现负载均衡,策略:static-rr根据权重进行轮询,对HTTP反向代理,设置链接拒绝、虚拟主机、会话保持,还有它的监控服务,我们制定的实现当服务异常或宕机之后会向运维部发送短信和邮件,当然,业务服务也一样,不过有更健全监控系统。从实际效率来讲要比Nginx出色的多,且稳定性接近F5。

  而Nginx的实现是一个Nginx对应一Tomcat服务,Nginx和Tomact在同一服务器上,每个服务都两台,进行互备,提高可用性。具体作用如下:缓存功能,增加命中率,减少回源。接口访问过滤策略,每个接口都会带有版本号及Token等信息。日志记录功能,访问日志,对于这个信息爆炸式的年代,日志重要性不言而喻;错误日志,正确的检测不仅可以发现服务性能的瓶颈,亦可及时发现问题,以及日志分割等。这里可以直接搭建ELK平台,对日志进行友好的查询和展示。

  以上内容,只是我们为什么这么做,并不是应该这么做或者说我们用到的只是它们的一部分功能,可能还有的东西理解不到位。公司使用架构方案是根据网站的规模、不同阶段来使用不同的技术。你的QPS就几十个,有必要选用硬件负载F5、Radware、Array、NetScaler吗?有钱也需要从实际出发,要不然后期我们优化什么?