• 首页 首页 icon
  • 工具库 工具库 icon
    • IP查询 IP查询 icon
  • 内容库 内容库 icon
    • 快讯库 快讯库 icon
    • 精品库 精品库 icon
    • 问答库 问答库 icon
  • 更多 更多 icon
    • 服务条款 服务条款 icon

程序高可用架构的设计

武飞扬头像
juejin
帮助78

概述

高可用(High Availability),简称HA,是衡量IT系统服务质量的一个极其重要的参考,高可用一直是IT系统设计中需要重点关注的点。本文总结高可用架构中的一些关键设计思想。

衡量指标SLA
SLA是衡量网站服务可用性的一个关键指标,现在互联网公司一般以X个9来表示在系统1年时间的使用过程中,系统可正常使用时间与总时间(1年)之比,9越多代表全年服务可用时间越长、服务更可靠、停机时间越短,反之亦然。

一般而言,如果系统达到4个9就非常优秀了,需要在设计上做足功夫。

冗余

冗余是构建高可用的重要手段。其核心思想是对分布式系统中的节点进行备份。备份会分为冷备和热备。

  • 冷备,一般会有主数据中心和备数据中心,正常情况下是主数据中心提供业务服务,备份中心不会有提供业务服务,而是会定期从主数据中心进行备份(非实时备份),也就是说如果主数据中心出现故障,业务也就中断了,需要人工进行干预,将流量从主数据中心切换到备数据中心。

  • 热备,主要是对主数据中心进行实时性的备份,以保证在主数据中心出现故障后可以及时的切换,让用户不受影响的继续使用。 关于主数据中心到备数据中心的复制方式,分为同步和异步两种分式。

    • 同步方式,当主节点处理完请求后,会同步向多个备节点实时备份数据,只有所有节点数据同步完成,主节点才会向客户端返回成功。这种方式对可用性有较大损耗,一般不推荐使用,
    • 异步方式,当主节点处理请求后,会向客户端返回成功,同时会异步触发向多个备节点实时备份数据。该情况下,主备节点的数据会存在数据不一致或者延时,业务上需要能容忍一定程度的数据延迟。互联网系统一般会采用这种方式。

从备节点的工作方式划分,又可以分为双机互备和双机热备。

  • 双机热备,从狭义上讲是使用互为备份的两台服务器共同执行同一服务,在正常情况下,工作机为应用系统提供服务,备份机监视工作机的运行情况,出故障时备机可迅速接管服务。
  • 双机互备,是指主机和备机互为备份,备机上运行与主机不同的应用,例如两台server安装相同的系统、应用软件,主机备机同时工作,主机跑ORACLE,备机跑IIS,任意一台服务器故障时,所有服务会自动切换到正常的服务器上。

集群

集群是相对单机而言的,集群部署是分布式系统的典型特征。集群的作用其实就是分流,这里面不得不提核心的分流技术。

负载均衡

分为硬件负载和软件负载。

  • 硬件负载:通过硬件来进行分流,常见的硬件有比较昂贵的F5和Array等商用的负载均衡器,它的优点就是有专业的维护团队来对这些服务进行维护、缺点就是花销太大,一般在互联网系统较少使用,主要用于金融行业的核心服务;
  • 软件负载:通过软件实现分流,如Nginx/LVS/HAProxy的基于Linux的开源免费的负载均衡软件,这些都是通过软件级别来实现,费用非常低廉。

按所处OSI模型的工作层级,可分为7层负载和4层负载。

  • 7层负载,是指工作在网络7层,基于URL等应用层信息的负载均衡,主要代表有Nginx。
  • 4层负载,就是基于IP 端口的负载均衡,主要代表有LVS。

DNS

Domain Name System,“域名系统”的英文缩写,是一种组织成域层次结构的计算机和网络服务命名系统,它所提供的服务是用来将主机名和域名转换为IP地址的工作。一般大型网站的域名,背后会绑定多个vipServer的地址,DNS可以通过智能域名解析系统,返回离用户最近的vipServer 的ip。

容错

容错能力也是影响IT系统可用性的一个关键要素。

  1. 狭义的容错,一般会在设计上体现在以下方面:
  • 对用户的输入进行尽早的校验,不信任外部的输入。
  • 程序中尽可能的考虑边界及异常的情况。
  1. 广义的容错应该是两个具有明确边界的事物(如服务间,系统间)交互时候针对可能发生的一切主客观异常情况的防御性手段。常见的容错机制有failsafe、failback、failover、failfast。

failfast

快速失败,尽可能的发现系统中的错误,使系统能够按照事先设定好的错误的流程执行,避免资源耗尽或积压导致系统滚雪球式崩溃。我们通常讲的熔断就是这个思想。

failover

失效转移,它和前面提到的冗余备份关联很紧密。当主要组件异常时,其功能迅速转移到备份组件。MYSQL的双主模式、Zookeeper的自动选举、Redis的哨兵模式,都是基于这种思想,目的是尽量减少部分节点故障对用户服务的影响

failback

自动恢复,是相对failover而言的,簇网络系统(有两台或多台服务器互联的网络)中,由于要某台服务器故障进行维修,需要网络资源和服务暂时重定向到备用系统。在此之后将网络资源和服务器恢复为由原始主机提供的过程,称为自动恢复。一般依赖心跳探测技术来实现自动恢复,例如dubbo服务中的应用实例出现down机后,在服务恢复后会自动注册到config server,重新对外提供服务。

failsafe

失效安全,即在故障的情况下也不会造成伤害或者尽量减少伤害。并非所有的故障对用户都是致命的,当这类非关键的故障出现时可以忽略,因为这种故障不会造成损失或损失在可接受范围内。

多活

双活/多活架构,关键点是指不同地理位置上的系统都能够提供服务。“活”是指实时提供服务,与“活”对应的是字是“备”——备是备份,正常情况下对外是不提供服务或只提供部分服务(例如DB读写分离),如果需要提供服务,则需要大量的人工干预和操作,花费大量的时间才能让“备”变成“活。

实现多活有较高的成本,要考虑数据一致性、网络延时问题。

常见的多活方案有同城双活、两地三中心、三地五中心、异地多活等多种技术方案,不同多活方案技术要求、建设成本、运维成本都不一样。

同城双活

是在同城或相近区域内建立两个机房。同城双机房距离比较近,通信线路质量较好,比较容易实现数据的同步复制 ,保证高度的数据完整性和数据零丢失。同城两个机房各承担一部分流量,一般入口流量完全随机,内部RPC调用尽量通过就近路由闭环在同机房,相当于两个机房镜像部署了两个独立集群,数据仍然是单点写到主机房数据库,然后实时同步到另外一个机房。

该架构优点是方案简单、成本较低、网络延时小,缺点是由于双机房都在同城,所在城市出现网络故障或自然灾害时,服务可用性无法保障。

两地三中心

指 同城双中心 异地灾备中心。异地灾备中心是指在异地的城市建立一个备份的灾备中心,用于双中心的数据备份,数据和服务平时都是冷的,当双中心所在城市或者地区出现异常而都无法对外提供服务的时候,异地灾备中心可以用备份数据进行业务的恢复。

该架构的优点是相比同城双活,增加了异地灾备能力;缺点是异地的备份数据中心是冷的,出故障时异地机房是否能顺利接管流量是个大问题。

异地多活

异地的一个核心问题是物理距离带来的延时,因此要避免一次请求在异地的多个机房之间流转,因此异地多活的核心是单元化,要保证单次请求在一个固定机房内封闭。

单元化,在技术上的核心挑战在于流量路由和数据同步。这里还需注意,有些应用和数据是没法单元化的,因此还会衍生出中心机房和单元机房的概念,对于没法单元化的数据必须在中心机房。 阿里的淘宝是国内最早完整成功实施单元化的系统,其在全球化部署上也有较多成功的实践,在此就不展开了。

去中心化

在一个分布有众多节点的系统中,每个节点都具有高度自治的特征。节点之间彼此可以自由连接,形成新的连接单元。任何一个节点都可能成为阶段性的中心,但不具备强制性的中心控制功能。节点与节点之间的影响,会通过网络而形成非线性因果关系。去中心化架构的特征:

  • 去中心化,不是不要中心,而是由节点来自由选择中心、自由决定中心。
  • 任何中心都不是永久的,而是阶段性的
  • 任何中心对节点都不具有强制性

常见的中心化设计:

  • ESB
  • 单体系统
  • 网关

常见的去中心化设计:

  • DUBBO、MESH等
  • 用SDK替代服务

这篇好文章是转载于:学新通技术网

  • 版权申明: 本站部分内容来自互联网,仅供学习及演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系,请提供相关证据及您的身份证明,我们将在收到邮件后48小时内删除。
  • 本站站名: 学新通技术网
  • 本文地址: /boutique/detail/taneihj
系列文章
更多 icon
同类精品
更多 icon
继续加载