关于nginx:高可用系列文章之二-传统分层架构技术方案

前文链接

高可用系列文章之一 – 概述 – 东风微鸣技术博客 (ewhisper.cn)

三 技术计划

3.1 概述

单点是零碎高可用最大的危险和敌人，应该尽量在零碎设计的过程中防止单点。

保障系统的高可用, 方法论上，高可用保障的准则是「集群化」(或「冗余」), 只有一个单点，该单点宕机所有服务都会受影响而不可用；如果有冗余或备份，其中一个点宕机还有其余冗余或备份节点可能提供服务。

保证系统高可用，架构设计的外围准则是：冗余。

有了冗余之后，还不够，每次呈现故障须要人工染指复原势必会减少零碎的 MTTR。所以，又往往是通过「主动故障转移」来实现零碎的高可用。

在上面的技术计划中，具体介绍了如何通过 冗余 + 主动故障转移 来保证系统的高可用个性。

3.2 制造业零碎的典型架构

制造业零碎个别采纳分层架构, 最简略的典型架构的展现如下:

​ 备注:

数据库以 MySQL 为例.

常见的零碎架构如上, 分为:

1. 客户端层: 典型调用形式浏览器(browser) 和客户端(client)

2. 应用服务层: 实现外围应用逻辑, 通常是 HTTP 协定或 TCP 协定. 这一层细分, 往往还包含:

   1. 表示层: 次要是 web 浏览页面;
   2. 业务逻辑层: 对具体问题进行逻辑判断和执行操作, 同时也是表示层和数据层的桥梁
   3. 可选: 服务层: 如果实现了服务化, 如 SOA 或微服务化, 就会有这一层;
   4. 数据拜访层: 实现对数据的增删改查等操作, 并将后果反馈到业务逻辑层
   5. 可选: 数据缓存层: 缓存减速拜访存储
3. 数据库层: 数据库固话数据存储.

整个零碎的高可用, 是通过对每一层的 冗余 + 主动故障转移 来综合实现的.

备注:

通过更加细化和粗疏的分层, 也能够进步 可用性. 如将以上架构细化为:

1. 客户端层;
2. 可选新增: 反向代理层
3. 可选新增: 表示层 (Web Server) 层
4. 应用服务层 (App Server) 层
5. 可选新增: 服务调用层
6. 可选新增: 缓存层
7. 数据库层

本文暂不波及这一内容.

3.3 制造业零碎的举荐高可用架构

通过 冗余 这一外围准则, 优化后的高可用架构如下图所示:

阐明:

• 实线 : 申请调用
• 点 + 横线: 心跳检测
• 点虚线: 尚未实在产生的申请调用
• 短横虚线: 数据库主从同步
• “X” – 对应节点宕机不可用.

高可用计划调整阐明如下:

1. 在客户端层和应用服务层之间, 新增: 负载平衡层. 负责将客户端申请通过某种负载平衡形式迷信地负载到应用服务外层;

2. 负载平衡层: 这一层蕴含以下 2 个组件:

   1. NGINX: 负责 TCP/HTTP 申请的负载反向代理 / 负载平衡;
   2. Keepalived: 负责对外提供单个 IP, 且对 2 台 NGINX 进行心跳检测和故障时的故障转移;
3. 应用服务层: 应用服务器至多为 2 个.
4. 数据库层 : 数据库进行 主从同步, 读写拆散

备注:

上图中, 也画出了高可用的另一种实施方案, 本文不做具体探讨:

• 利用横向拆分: 单体利用 (monolithic application) 依据重要性进行拆分, 将重要性高的服务和重要性低的服务进行拆分, 独自部署.
• 重要性高的利用, 如低提早类利用, 流水线上利用等;
• 重要性低的利用, 如高提早类利用, 报表利用等.

除此之外, 还能够依据理论业务状况进一步将 数据库 进行拆分, 本文亦不做具体探讨:

• 数据库拆为 2 个库, 其中一个库通过数据同步从另一个库定时 (实时或非实时) 同步数据. 举例说明: 业务库, 报表库. (业务库定期同步数据给报表库)
• 重要性高的利用, 读取写入业务库;
• 重要性低的利用. 如报表类利用. 不容许应用业务库, 而是应用报表库.

上面逐个进行分层阐述.

3.4 客户端层 -> 负载平衡层 高可用

客户端层 到 负载平衡层 高可用, 通过 负载平衡层 的冗余来实现的. 具体实现形式如下:

至多有 2 台 nginx, 其中一台提供服务, 另一台冗余以保障高可用. 并通过 Keepalived 的 virtual IP 来提供同一 IP(如上图为: 1.2.5.6), 通过心跳探测来进行故障检测和故障转移.

在上图中, NGINX 主节点提供对外服务.

当 NGINX 主节点 (如: 192.168.0.1) 产生宕机, Keepalived 可能探测到, 会主动进行故障转移, 将流量主动转移到 NGINX 从节点(如: 192.168.0.2). 因为应用的是雷同的 virtual IP(仍为: 1.2.5.6), 这个切换过程对调用方是通明的.

3.5 负载平衡层 -> 应用服务层高可用

负载平衡层 到 应用服务层 的高可用, 是通过 应用服务层 的冗余来实现的. 在 NGINX 的配置文件 nginx.conf 中, 能够通过 upstream 指令配置多个应用服务器, 并且 nginx 可能探测到多个应用服务器的存活性.

知识点:

在 NGINX 开源版本中, 如果不应用第三方插件，NGINX 的存活探测为: 被动 探测.

当 应用服务层 其中一个节点宕机的时候, nginx 可能探测到, 会主动进行故障转移, 不会将流量散发到产生故障的节点, 而是散发到其余的失常应用服务器节点, 整个过程由 NGINX 主动实现, 对调用方通明.

3.6 应用服务层 -> 数据库层高可用

数据库层倡议采纳「主从同步, 读写拆散」架构. 数据库的高可用, 又可细分为:「读库高可用」和「写库高可用」两类.

备注:

因为制造业采纳了多种数据库, 包含但不限于:

• Oracle
• SQL Server
• MySQL

不同数据库的高可用解决方案并不完全相同, 所以本文不对数据库的具体高可用技术做细节形容. 只进行实践阐述.(以 MySQL 为例)

常见的数据库高可用计划有:

1. MySQL: 主从同步;
2. Oracle: RAC
3. SQL Server: Alwayon

3.6.1 读库高可用

读库高可用, 是通过读库的冗余来实现的.

如果要对读库实现高可用, 一般来说至多有 2 个从库, 数据库连接池会建设与读库的多个连贯, 每次申请会路由到这些读库.

当读库 – 从 1 产生宕机的时候, 应用服务层的 数据库连接池 可能探测到, 会主动的进行故障转移, 将流量主动迁徙到其余的读库, 如读库 – 从 2, 整个过程由数据库连接池主动实现, 对调用方是通明的.

备注:

须要利用零碎或中间件的数据库连贯层实现 数据库连接池 性能.

3.6.2 写库高可用

写库的高可用, 是通过写库的冗余来实现的.

以 MySQL 为例, 能够设置两个 MySQL 双主同步, 一台对线上提供服务, 另一台冗余以保障高可用.

3.7 技术选型

3.7.1 负载均衡器技术选型

选型后果:

• 负载均衡器: NGINX + Keepalived

• 版本:

  • NGINX: 1.16.1 ( 选型版本至多每半年评估一次, 依据评估后果对版本进行调整)
  • Keepalived: 2.0.10(❗️ 选型版本至多每半年评估一次, 依据评估后果对版本进行调整)
• 操作系统类型: Linux
• 操作系统版本: SUSE 12 (按需调整，遵循制造业的相干技术规范要求.)

定义及概述:

在分布式系统中，负载平衡（load balance）是一种无效的将网络申请调配到多个服务器的过程。通过将负载进行负载平衡，能够无效地改良零碎响应工夫，进步零碎的可用性。随着零碎变的愈发简单，用户增多和网络流量增大，负载平衡曾经成为零碎设计中的必要一环。

负载均衡器能够是硬件也能够是软件，它会将网络申请散发到服务器集群上。

选型过程概述

常见的硬件负载均衡器包含:

• F5
• A10

常见的软件负载均衡器包含:

• Nginx
• LVS
• HAProxy

联合制作行业最佳实际, 以及制造业的理论状况思考, 制造业在全国乃至寰球领有多座工厂, 每个工厂领有独立的机房. 采纳硬件负载平衡老本过高. 确定采纳 软件负载均衡器 作为负载平衡技术实现. 上面对软件负载均衡器逐个进行阐述:

NGINX:

Nginx(“engine x”)是一款是由俄罗斯的程序设计师 Igor Sysoev 所开发高性能的 Web 和 反向代理 服务器.

长处:

1. 工作在网络的 4 层 (TCP/UDP) 和 7 层(HTTP/websocket)，能够针对 http 利用做一些分流的策略，比方针对域名、目录构造，其正则规定比 HAProxy 更为弱小和灵便, 同时 NGINX 目前是应用最宽泛的负载均衡器和 Web Server，实用场景丰盛.
2. Nginx 对网络稳定性的依赖十分小，实践上能 ping 通就就能进行负载性能；相同 LVS 对网络稳定性依赖比拟大；
3. Nginx 装置和配置比较简单，测试起来比拟不便，NGINX 领有欠缺的且可自定义的日志, 包含 access 日志和 error 日志。LVS 的配置、测试须要破费比拟长的工夫。
4. NGINX 能够承当高负载压力且稳固，在硬件不差的状况下很容易能撑持几万次的并发量。
5. Nginx 能够通过端口检测到应用服务器的故障，如依据服务器解决网页返回的状态码、超时等等，并且会把返回谬误的申请从新提交到另一个节点。如用户正在上传一个文件，而解决该上传的节点刚好在上传过程中呈现故障，Nginx 会将上传切到另一台服务器重新处理，如果是 LVS 就间接断掉了。
6. Nginx 不仅仅是一款优良的负载均衡器 / 反向代理软件，它同时也是功能强大的 Web 应用服务器。LNMP 也是近几年十分风行的 web 架构，在高流量的环境中稳定性也很好。
7. Nginx 作为 Web 反向减速缓也比拟成熟，速度比传统的 Squid 服务器更快，在将来场景用, 也能够扩大 NGINX 的用处。
8. Nginx 可作为反向代理应用，作为反向代理, Nginx 应用最宽泛, 同类产品还有 lighttpd 了，不过 lighttpd 目前还没有做到 Nginx 齐全的性能，配置也不清晰易读，社区材料也远远没 Nginx 沉闷。
9. Nginx 也可作为动态网页和图片服务器，这方面的性能也无对手。
10. Nginx 社区十分沉闷，第三方模块也很多。

毛病:

1. 对后端服务器的健康检查, 开源版 NGINX 反对持 被动检测 . 不反对 被动检测.
2. 对于负载平衡的会话放弃, 开源版 NGINX 默认不反对cookie 会话放弃. 然而能通过 ip_hash 实现源地址会话放弃, 且能够通过第三方模块实现cookie 会话放弃.

LVS:

LVS：应用 Linux 内核集群实现一个高性能、高可用的负载平衡服务器，它具备很好的可伸缩性（Scalability)、可靠性（Reliability)和可管理性（Manageability)。

长处:

1. 抗负载能力强、是工作在网络 4 层之上仅作散发之用，没有流量的产生，这个特点也决定了它在负载平衡软件里的性能最强的，对内存和 cpu 资源耗费比拟低。
2. 配置性比拟低，这是一个毛病也是一个长处，因为没有可太多配置的货色，所以并不需要太多接触，大大减少了人为出错的几率。
3. 工作稳固，因为其自身抗负载能力很强，本身有残缺的双机热备计划，如 LVS+Keepalived。
4. 无流量，LVS 只散发申请，而流量并不从它自身进来，这点保障了均衡器 IO 的性能不会收到大流量的影响。
5. 利用范畴比拟广，因为 LVS 工作在 4 层，所以它简直能够对所有利用做负载平衡，包含 http、数据库、在线聊天室等等。

毛病:

1. 软件自身不反对正则表达式解决，不能做动静拆散；而当初许多网站在这方面都有较强的需要，这个是 Nginx+Keepalived 的劣势所在。
2. 如果是网站利用比拟宏大的话，LVS 施行起来比较复杂了，特地前面有 Windows Server 的机器的话，如果施行及配置还有保护过程就比较复杂了，相对而言，Nginx + Keepalived 就简略多了。

HAProxy:

HAProxy 是一个应用 C 语言编写的自在及凋谢源代码软件，其提供高可用性、负载平衡，以及基于 TCP 和 HTTP 的应用程序代理。

长处:

1. HAProxy 反对虚拟主机。
2. HAProxy 的长处可能补充 Nginx 的一些毛病，比方反对 Session 的放弃，Cookie 的疏导；同时反对通过获取指定的 url 来检测后端服务器的状态。
3. HAProxy 跟 LVS 相似，自身就只是一款负载平衡软件。
4. HAProxy 反对 TCP 协定的负载平衡转发。
5. HAProxy 负载平衡策略比拟丰盛

毛病:

1. 不反对 POP/SMTP 协定
2. 不反对 SPDY 协定
3. 不反对 HTTP cache 性能。
4. 重载配置的性能须要重启过程，尽管也是 soft restart，但没有 Nginx 的 reload 更为平滑和敌对。
5. 多过程模式反对不够好

选型论断:

LVS 试用场景繁多, 且存在硬伤(即: 前面有 Windows Server 的机器的话, 施行比较复杂). 间接排除.

HAPorxy 针对 HTTP 的反对没有 NGINX 丰盛, 且重启中断绝对 NGINX 工夫更长.

另外, nginx 除了以后能够用作负载均衡器之外, 还能够用作 web server, http 缓存等场景, 且容易上手.

最终确定抉择 NGINX 作为某制造业公司负载均衡器.

3.7.2 NGINX 高可用技术计划选型

NGINX 高可用技术计划只有一种, 即: NGINX + Keepalived 实现高可用.

keepalived开源我的项目包含三个组成部分：

• keepalivedLinux 服务器的守护程序。

• 虚构路由器冗余协定（VRRP）的实现，用于治理虚构路由器（虚构 IP 地址或 VIP）。

  VRRP 确保始终存在一个主节点。备用节点侦听来自主节点的 VRRP 通告包。如果在超过配置的播送距离的三倍的工夫内未收到播送包，则备用节点将作为主节点接管，并将配置的 VIP 调配给本人。

• 一种运行状况查看工具，用于确定服务（例如，Web 服务器，PHP 后端或数据库服务器）是否已启动并且能够运行。

  如果节点上的服务未通过配置的运行状况查看次数，keepalived 则将虚构 IP 地址从主（被动）节点重新分配给备用（被动）节点。

3.7.3 NGINX 负载平衡策略

选型后果:

负载平衡策略: RR(轮询, 默认策略)

会话放弃策略: (非必须)

• 不须要会话放弃, 则不进行配置.
• 须要依据源地址进行会话放弃: ip_hash

NGINX 负载平衡策略:

1. 轮询调度算法: rr (默认调度算法).
2. 加权循环调度算法: wrr. 实用场景: nginx 服务器性能不雷同, 性能高的须要负载更多申请.
3. 最小的连接数: least_conn. 

4. 会话放弃策略:

   1. IP 会话放弃: ip_hash
   2. hash – 指定服务器组的负载平衡办法，其中客户机 - 服务器映射基于 hash 值。key 能够蕴含文本、变量及其组合。

选型过程:

负载平衡策略，依据理论状况按需抉择，无特殊要求的状况下抉择 rr 即可。
会话放弃策略, 须要依据特定的场景进行抉择:

• 不须要会话放弃, 则不进行配置.
• 须要依据源地址进行会话放弃: ip_hash
• 须要进行 cookie 会话放弃: sticky
• 源地址会话放弃和 cookie 会话放弃均无奈满足需要, 则可能须要通过 hash 来定制会话放弃策略.

3.7.3 应用服务层 -> 数据库层高可用选型

略.

因为利用零碎的多样性, 本文不对应用服务层 -> 数据库层高可用选型做束缚. 仅提供顶层架构要求:

1. 数据库: 主从同步, 读写拆散

2. 利用:

   1. 实现数据库连接池性能. 能够配置多个数据库连贯.
   2. 依据利用功能模块的重要性进行横向拆封. 将: 报表, 数据统计, 批处理类性能与低提早重要业务性能剥离开来.

参考文件