互联网三高中的高可用是个啥?

本文详细介绍了互联网三高中的高可用性,旨在确保业务连续性。通过分层架构、冗余和自动故障转移,确保每个组件的高可用。文章探讨了接入层、反向代理层、微服务、中间件、存储层的高可用设计,包括 LVS、Nginx、Zookeeper、Redis、ES 和 MySQL 等组件的高可用实现策略,以及如何应对瞬时流量、安全、代码、部署和第三方问题,以提升系统的整体可用性。
摘要由CSDN通过智能技术生成

今天我们来聊一下互联网三高(高并发、高性能、高可用)中的高可用,看完本文相信能解开你关于高可用设计的大部分困惑

前言

高可用(High availability,即 HA)的主要目的是为了保障「业务的连续性」,即在用户眼里,业务永远是正常(或者说基本正常)对外提供服务的。高可用主要是针对架构而言,那么要做好高可用,就要首先设计好架构,第一步我们一般会采用分层的思想将一个庞大的 IT 系统拆分成为应用层,中间件,数据存储层等独立的层,每一层再拆分成为更细粒度的组件,第二步就是让每个组件对外提供服务,毕竟每个组件都不是孤立存在的,都需要互相协作,对外提供服务才有意义。

要保证架构的高可用,就要保证架构中所有组件以及其对外暴露服务都要做高可用设计,任何一个组件或其服务没做高可用,都意味着系统存在风险。

那么这么多组件该怎么做高可用设计呢,其实任何组件要做高可用,都离不开「冗余」和「自动故障转移」,众所周知单点是高可用的大敌,所以组件一般是以集群(至少两台机器)的形式存在的,这样只要某台机器出现问题,集群中的其他机器就可以随时顶替,这就是「冗余」。简单计算一下,假设一台机器的可用性为 90%,则两台机器组成的集群可用性为 1-0.1*0.1 = 99%,所以显然冗余的机器越多,可用性越高。

但光有冗余还不够,如果机器出现问题,需要人工切换的话也是费时费力,而且容易出错,所以我们还需要借助第三方工具(即仲裁者)的力量来实现「自动」的故障转移,以达到实现近实时的故障转移的目的,近实时的故障转移才是高可用的主要意义

怎样的系统可以称之为高可用呢,业界一般用几个九来衡量系统的可用性,如下

可用性级别 系统可用性% 宕机时间/年 宕机时间/月 宕机时间/周 宕机时间/天
不可用 90% 36.5 天 73 小时 16.8 小时 144 分钟
基本可用 99% 87.6 小时 7.3 小时 1.68 小时 14.4 分钟
较高可用 99.9% 8.76 小时 43.8 分钟 10.1 分钟 1.44 分钟
高可用 99.99% 52.56 分钟 4.38 分钟 1.01 秒 8.64 秒
极高可用 99.999% 5.26 分钟 26.28 秒 6.06 秒 0.86 秒

一般实现两个 9 很简单,毕竟每天宕机 14 分钟已经严重影响业务了,这样的公司迟早歇菜,大厂一般要求 4 个 9,其他要求严苛的业务要达到五个九以上,比如如果因为一个电脑的故障导致所有列车停驶,那么就会有数以万计的人正常生活受到阻碍,这种情况就要求五个九以上

接下来我们就来一起看看架构中的各个组件如何借助「冗余」和「自动故障转移」来实现高可用。

互联网架构剖析

目前多数互联网都会采用微服务架构,常见架构如下:

可以看到架构主要分以下几层

  1. 接入层:主要由 F5 硬件或 LVS 软件来承载所有的流量入口
  2. 反向代理层:Nginx,主要负责根据 url 来分发流量,限流等
  3. 网关:主要负责流控,风控,协议转换等
  4. 站点层:主要负责调用会员,促销等基本服务来装配 json 等数据并返回给客户端
  5. 基础 service:其实与站点层都属于微服务,是平级关系,只不过基础 service 属于基础设施,能被上层的各个业务层 server 调用而已
  6. 存储层:也就是 DB,如 MySQL,Oracle 等,一般由基础 service 调用返回给站点层
  7. 中间件:ZK,ES,Redis,MQ 等,主要起到加速访问数据等功能,在下文
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值