这次笔记主写接入层, 根据我们的实际项目出发, 经验浅薄, 可能有不对之处, 还望指出. 下回写逻辑层和存储层相关的笔记.
首先要知道我们的目的是什么?
保证系统的 7*24 小时可用
保证用户访问响应时间
保证系统的安全性
统一接入层, 规范应用系统部署
一般而言, 有 Nginx 就可以了, 但当流量具有一定规模时候, 这样的架构就变得不稳定了, 如: 用户响应时间过长, 偶尔来个瘫痪什么的. 所以为了提高可用性及整体的吞吐量, 会引入接入层, 这里使用 LVS 四层负载均衡, DNS 解析到 LVS 的 IP 地址, 然后 LVS 转发至 Nginx, 最后到后端的 RS. 如图:
很多公司都是从开始的单点服务, 即一台服务搞定了一切 -> 到后来服务隔离, 引入 Nginx, 保证高可用 ->Nginx/LVS/F5/HAProxy 进行负载均衡, 还有分流, 削峰填谷, 热点缓存, 这些东西下个笔记会涉及颇多.
我们接着看这张:
看完这张图你或许会无语, 为什么这么搞? LVS+HAProxy+Nginx 这几个好像可以做同样的事情, 目前使用最广泛的三种负载均衡软件都被你们用了, 有没有? 其实不然, 这层架构体系, 也是运维部根据公司具体的业务流量迭代出来的.
先看下访问过程:
用户在浏览器输入域名回车
如果本地缓存里没有该域名对应的 ip 地址 (浏览器缓存 + 本地缓存, 谷歌浏览器中输入: chrome://net-internals/#dns 看到缓存页面, 本地的缓存在 hosts 中)
那么到 DNS 进行域名解析, DNS 将域名的解析权交给 CNAME 指向的 CDN 专用 DNS 服务器
为了得到实际 IP, 浏览器向 CDN 的全局负载均衡设备发起内容 URL 访问请求.
全局负载均衡 DNS 根据用户 IP, 将当时最接近的节点 IP 返回给用户浏览器 (这里不考虑 CDN 中设置的 URL 相关策略)
浏览器得到 IP, 进行访问, 然后到 LVS 这层.
我们知道 LVS 处于四层, HAProxy 基于四层和七层, 提供 TCP 和 HTTP 应用的负载均衡综合解决方案, 这里我们使用七层. Nginx 七层. 基于他们各个特点可以去 Google 一下, 这里不做详细笔记了. 四层的负载是根据三层的 IP 地址 (VIP)+ 四层的端口号来实现, 我们实际只实现了高可用并没有进行负载均衡, 真正的负载放到了 HAProxy,LVS 做了一件事就是分发即分流作用, 访问不同的业务, 走不同的服务. 后期流量增大可考虑负载, 也可以很方便的进行扩展, 即它的伸缩性很强. 需要认识的一点是请求的响应不走 LVS. 项目实施 LVS/DR+Keepalived 实现双机热备.
HAProxy 实现负载均衡, 策略: static-rr 根据权重进行轮询, 对 HTTP 反向代理, 设置链接拒绝, 虚拟主机, 会话保持, 还有它的监控服务, 我们制定的实现当服务异常或宕机之后会向运维部发送短信和邮件, 当然, 业务服务也一样, 不过有更健全监控系统. 从实际效率来讲要比 Nginx 出色的多, 且稳定性接近 F5.
而 Nginx 的实现是一个 Nginx 对应一 Tomcat 服务, Nginx 和 Tomact 在同一服务器上, 每个服务都两台, 进行互备, 提高可用性. 具体作用如下: 缓存功能, 增加命中率, 减少回源. 接口访问过滤策略, 每个接口都会带有版本号及 Token 等信息. 日志记录功能, 访问日志, 对于这个信息爆炸式的年代, 日志重要性不言而喻; 错误日志, 正确的检测不仅可以发现服务性能的瓶颈, 亦可及时发现问题, 以及日志分割等. 这里可以直接搭建 ELK 平台, 对日志进行友好的查询和展示.
以上内容, 只是我们为什么这么做, 并不是应该这么做或者说我们用到的只是它们的一部分功能, 可能还有的东西理解不到位. 公司使用架构方案是根据网站的规模, 不同阶段来使用不同的技术. 你的 QPS 就几十个, 有必要选用硬件负载 F5,Radware,Array,NetScaler 吗? 有钱也需要从实际出发, 要不然后期我们优化什么?
来源: https://www.cnblogs.com/mottled/p/8963886.html