2024-11-01

Java Spring

应用服务的高可用性架构

需求

为了解决系统高可用性、数据一致性和灾难恢复需求而设计出对应的架构。减少系统故障带来的影响，保证业务连续性，并且在发生意外时能够迅速恢复系统。

最常见的高可用架构便是主备模式（Active-Standby）和双活模式（Active-Active）。主备模式有大致笼统的分为热备份和冷备份。根据具体的可用性需求对某台机器故障时恢复速度的需求进行选择。

架构说明

主备模式（热备，冷备同时存在）

因为一个项目中对不同的服务有不同的高可用需求，所以将冷备和热备应用于同一项目中的不同服务，需求达到的同时还最大限度的节省资源。

目前主备模式使用的工具为keepalived，keepalived使用vrrp（虚拟路由冗余协议）协议，对多台服务器进行选举和抢占机制来选择master服务器，并使master服务器担任业务逻辑处理。

vrrp为虚拟路由冗余协议，其原理是将多台服务器识别为一台虚拟机器，通过配置虚拟设备的IP地址为缺省网关，实现缺省网关的备份。具体原理请查看章节（VRRP）

但是需要说明的是keepalived大多是用来做路由器冗余的工具，而我目前的项目中则直接用于转发到应用服务中。

keepalived通过权重和master/backup配置选择主服务，此时master的网络信息中将会添加一条虚拟IP地址的信息。所有针对虚拟ip发起的请求就会转发到master中。接下来是interface应用热备的架构图：

architecture-beta 
    group dmz(server)[DMZ]
    group app(server)[APP]
    service dmz2(server)[nginx keepalived] in dmz
    service dmz1(server)[nginx keepalived] in dmz
    service api1(server)[interface keepalived] in app
    service api2(server)[interface keepalived] in app
    junction apiPoint in server
    junction dmzPoint in server
    service gov(internet)[user]

    dmz1:L --> R:apiPoint
    dmz2:L --> R:apiPoint
    apiPoint:L --> R:api1
    apiPoint:L --> R:api2
    dmzPoint:L --> R:dmz1
    dmzPoint:L --> R:dmz2
    gov:L --> R:dmzPoint

TypeError: Cannot read properties of undefined (reading 'v')

备用图：

其中interface需要做到高可用，当其中一个服务停止运行后keepalived会立即停止，这时备用机的keepalived将会获取到虚拟地址，所有的请求直接转发到备用服务上，此时因为备用的api已经启动了，对于user来说没有影响。同时zabbix监控服务进程并对停止的服务进行告警。

同时在app的机器上还存在于另外一套服务，app内的nginx对app中的服务进行访问，同样使用了主备模式。接下来是api应用冷备的架构图：

architecture-beta 
    group app(cloud)[APP]
    group app1(server)[APP1 with keepalived] in app
    group app2(server)[APP2 with keepalived] in app
    service nginx2(server)[nginx] in app2
    service nginx1(server)[nginx] in app1
    service api1(server)[api] in app1
    service api2(server)[api] in app2
    service route(internet)[user]

    route:B --> T:nginx1
    route:B --> T:nginx2
    nginx1:B --> T:api1
    nginx2:B --> T:api2

备用图：

TypeError: Cannot read properties of undefined (reading 'v')

冷备流程图中APP1和APP2就是热备流程图中APP的两台机器。其中APP2的所有服务都是冷备份，当APP1的keepalived停止服务后APP2的api和nginx将会启动。因为使用用户较少，并且高可用性的需求与interface相比不需要特别及时。所以使用了冷备份的形式。

但是上面的架构中api会受到interface存活状态的影响。当app服务器中的interface停止服务后，keepalived会停止运行，同时api会被迫停止服务。这在我目前做的项目中是符合需求的。

双活模式

双活模式则是同时启用两台服务，并使用负载均衡对两台机器分发请求，使压力平分给两组机器。使用硬件负载从而对请求转发更加可信。

双活分为本地双活和异地双活，数据异地双活可能存在数据同步效率问题，应用异地双活没有太大问题（因为也不必要异地双活）。

应用服务的高可用性架构

需求

为了解决系统高可用性、数据一致性和灾难恢复需求而设计出对应的架构。减少系统故障带来的影响，保证业务连续性，并且在发生意外时能够迅速恢复系统。

最常见的高可用架构便是主备模式（Active-Standby）和双活模式（Active-Active）。主备模式有大致笼统的分为热备份和冷备份。根据具体的可用性需求对某台机器故障时恢复速度的需求进行选择。

架构说明

主备模式（热备，冷备同时存在）

因为一个项目中对不同的服务有不同的高可用需求，所以将冷备和热备应用于同一项目中的不同服务，需求达到的同时还最大限度的节省资源。

目前主备模式使用的工具为keepalived，keepalived使用vrrp（虚拟路由冗余协议）协议，对多台服务器进行选举和抢占机制来选择master服务器，并使master服务器担任业务逻辑处理。

vrrp为虚拟路由冗余协议，其原理是将多台服务器识别为一台虚拟机器，通过配置虚拟设备的IP地址为缺省网关，实现缺省网关的备份。具体原理请查看章节（VRRP）

但是需要说明的是keepalived大多是用来做路由器冗余的工具，而我目前的项目中则直接用于转发到应用服务中。

keepalived通过权重和master/backup配置选择主服务，此时master的网络信息中将会添加一条虚拟IP地址的信息。所有针对虚拟ip发起的请求就会转发到master中。接下来是interface应用热备的架构图：

architecture-beta 
    group dmz(server)[DMZ]
    group app(server)[APP]
    service dmz2(server)[nginx keepalived] in dmz
    service dmz1(server)[nginx keepalived] in dmz
    service api1(server)[interface keepalived] in app
    service api2(server)[interface keepalived] in app
    junction apiPoint in server
    junction dmzPoint in server
    service gov(internet)[user]

    dmz1:L --> R:apiPoint
    dmz2:L --> R:apiPoint
    apiPoint:L --> R:api1
    apiPoint:L --> R:api2
    dmzPoint:L --> R:dmz1
    dmzPoint:L --> R:dmz2
    gov:L --> R:dmzPoint

备用图：

其中interface需要做到高可用，当其中一个服务停止运行后keepalived会立即停止，这时备用机的keepalived将会获取到虚拟地址，所有的请求直接转发到备用服务上，此时因为备用的api已经启动了，对于user来说没有影响。同时zabbix监控服务进程并对停止的服务进行告警。

同时在app的机器上还存在于另外一套服务，app内的nginx对app中的服务进行访问，同样使用了主备模式。接下来是api应用冷备的架构图：

architecture-beta 
    group app(cloud)[APP]
    group app1(server)[APP1 with keepalived] in app
    group app2(server)[APP2 with keepalived] in app
    service nginx2(server)[nginx] in app2
    service nginx1(server)[nginx] in app1
    service api1(server)[api] in app1
    service api2(server)[api] in app2
    service route(internet)[user]

    route:B --> T:nginx1
    route:B --> T:nginx2
    nginx1:B --> T:api1
    nginx2:B --> T:api2

备用图：

TypeError: Cannot read properties of undefined (reading 'v')

冷备流程图中APP1和APP2就是热备流程图中APP的两台机器。其中APP2的所有服务都是冷备份，当APP1的keepalived停止服务后APP2的api和nginx将会启动。因为使用用户较少，并且高可用性的需求与interface相比不需要特别及时。所以使用了冷备份的形式。

但是上面的架构中api会受到interface存活状态的影响。当app服务器中的interface停止服务后，keepalived会停止运行，同时api会被迫停止服务。这在我目前做的项目中是符合需求的。

双活模式

双活模式则是同时启用两台服务，并使用负载均衡对两台机器分发请求，使压力平分给两组机器。使用硬件负载从而对请求转发更加可信。

双活分为本地双活和异地双活，数据异地双活可能存在数据同步效率问题，应用异地双活没有太大问题（因为也不必要异地双活）。

architecture-beta 
    group app(cloud)[APP]
    group app1(server)[APP1] in app
    group app2(server)[APP2] in app
    service nginx2(server)[nginx] in app2
    service nginx1(server)[nginx] in app1
    service api1(server)[api] in app1
    service api2(server)[api] in app2
    service route(internet)[user]
    service f5(server)[load equalization] in app

    route:B --> T:f5
    f5:B --> T:nginx1
    f5:B --> T:nginx2
    nginx1:B --> T:api1
    nginx2:B --> T:api2

TypeError: Cannot read properties of undefined (reading 'v')

VRRP

vrrp为虚拟路由冗余协议，其原理是将多台服务器识别为一台虚拟机器，通过配置虚拟设备的IP地址为缺省网关，实现缺省网关的备份。

vrrp协议定义了三种状态机：初始状态（Initialize）、活动状态（Master）、备份状态（Backup）。

初始状态：为VRRP不可用状态，在此状态时设备不会对VRRP通告报文做任何处理。
活动状态：当VRRP设备处于Master状态时，它将会承担虚拟路由设备的所有转发工作，并定期向整个虚拟内发送VRRP通告报文。
备份状态：当VRRP设备处于Backup状态时，它不会承担虚拟路由设备的转发工作，并定期接受Master设备的VRRP通告报文，判断Master的工作状态是否正常。

状态机转换关系:

VRRP选举机制:

应用服务的高可用性架构

应用服务的高可用性架构

需求

架构说明

主备模式（热备，冷备同时存在）

双活模式

应用服务的高可用性架构

需求

架构说明

主备模式（热备，冷备同时存在）

双活模式

VRRP

评论

分类

标签云

最新文章

标签

最新文章

标签

Your browser is out-of-date!