高可用架构的设计方法

标签: 架构 设计 方法 | 发表时间:2022-11-09 18:27 | 作者:飞书技术
出处:https://juejin.cn/backend

我们来自字节跳动飞书商业应用研发部(Lark Business Applications),目前我们在北京、深圳、上海、武汉、杭州、成都、广州、三亚都设立了办公区域。我们关注的产品领域主要在企业经验管理软件上,包括飞书 OKR、飞书绩效、飞书招聘、飞书人事等 HCM 领域系统,也包括飞书审批、OA、法务、财务、采购、差旅与报销等系统。欢迎各位加入我们。

本文作者:LBA 许家强

概述

高可用(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替代服务

加入我们

扫码发现职位&投递简历

官网投递: job.toutiao.com/s/FyL7DRg

欢迎大家关注 飞书技术,每周定期更新飞书技术团队技术干货内容,想看什么内容,欢迎大家评论区留言~

相关 [架构 设计 方法] 推荐:

高可用架构的设计方法

- - 掘金 后端
我们来自字节跳动飞书商业应用研发部(Lark Business Applications),目前我们在北京、深圳、上海、武汉、杭州、成都、广州、三亚都设立了办公区域. 我们关注的产品领域主要在企业经验管理软件上,包括飞书 OKR、飞书绩效、飞书招聘、飞书人事等 HCM 领域系统,也包括飞书审批、OA、法务、财务、采购、差旅与报销等系统.

iOS应用架构谈(一):架构设计的方法论

- - 博客园_知识库
  之前安居客iOS app的第二版架构大部分内容是我做的,期间有总结了一些经验. 在将近一年之后,前同事zzz在微信朋友圈上发了一个问题:假如问你一个iOS or Android app的架构,你会从哪些方面来说呢.   当时看到这个问题正好在乘公车回家的路上,闲来无聊就答了一把. 在zzz在微信朋友圈上追问了几个问题之后,我觉得有必要以文章形式专门来讲一些个人见解.

软件架构设计

- - 企业架构 - ITeye博客
软件架构设计尚没有万灵的方法论支持,还是个非常新兴的行业,给出个人理解的行业软件架构设计过程,受个人水平有限,仅供参考:. 1.业务分析:针对目标行业的业务战略、蓝图、业务功能及流程进行分析,提出其中部分功能可以使用信息化进行处理,通过分析可以得出信息化要解决的问题. 2.解决方案设计:根据业务战略,形成行业信息化解决方案.

架构设计-逻辑层

- - 人月神话的BLOG
知乎看到一个问题,也是当前在软件设计开发中普遍存在的一个问题,如下:. 现在要开发一个业务逻辑比较复杂的项目,但是在网上看了设计模式的思想后感觉自己以前写的东西扩展性都不好,接口定义也不合适,都是一个实体类一个接口,项目施工也感觉不合理,感觉项目施工中应该先集中定义好接口,并完成业务逻辑,然后在具体实现接口,不知道这样想是不是正确.

秒杀架构设计

- - IT瘾-dev
最近在部门内部分享了原来在电商业务做秒杀活动的整体思路,大家对这次分享反馈还不错,所以我就简单整理了一下,分享给大家参考参考. 通俗一点讲就是网络商家为促销等目的组织的网上限时抢购活动. 比如说京东秒杀,就是一种定时定量秒杀,在规定的时间内,无论商品是否秒杀完毕,该场次的秒杀活动都会结束. 这种秒杀,对时间不是特别严格,只要下手快点,秒中的概率还是比较大的.

架构设计和概要设计

- - 人月神话的BLOG
初步再来探讨下架构设计和概要设计的区别和边界问题. 架构设计包括了功能性架构和技术架构设计两个部分的内容,功能性架构解决业务流程和功能问题,而技术架构解决非功能性需求等问题. 两种架构都包括了动态和静态两个方面的内容,对于功能性架构中动态部分为业务流程驱动全局用例,用例驱动的用例实现等;对于技术架构中动态部分为架构运行机制,而静态部分为框架,分层等方面的内容.

Web API设计方法论

- - 博客园_知识库
  英文原文: A Web API Design Methodology.    为 Web 设计、实现和维护 API 不仅仅是一项挑战;对很多公司来说,这是一项势在必行的任务. 本系列 将带领读者走过一段旅程,从为 API 确定业务用例到设计方法论,解决实现难题,并从长远的角度看待在 Web 上维护公共 API.

社区讨论:Android的架构设计

- - InfoQ cn
最近,开发者在知乎社区中就Android的架构设计展开了 讨论. 有人问“Android 架构设计的思想与原则是什么. 最近工作中遇到了Android中的权限问题,发现Android确实是开源的,但并不开放,比如权限控管就相当严格,限制做很多事情,这一点得益于Linux内核. 这也勾起来对其架构研究的兴趣,不知到哪位能够深度剖析下Android架构设计的思想与原则.

分层架构设计原则

- - 博客园_首页
通常一个软件系统都包含不同部分互相交互耦合,我们希望设计能够将系统划分为有意义的各个部件,各个部件能够独立的开发、演进、部署. 这时整体性的设计已经无法满足这些挑战,这就需要我们对系统进行合理清晰的划分. 通常我们为待开发的系统定义多个层次,每一层完成独立的功能. 1:系统分为多层,每层完成独立的功能,层内部继续细分子模块,每层能够独立演进、部署.

CDN架构设计及注意事项

- - ITeye博客
内容传输网络或内容分发网络(CDN)是一个包含数据副本的缓存系统,存在于网络中不同的节点以便可以最大化的利用网络来传输数据至客户端. 一个客户端访问离它最近节点的数据副本,而不是所有的客户端访问相同的中心服务器,因此避免了服务器瓶颈问题. CDN所缓存的内容类型包括web对象、可下载的对象(媒体文件、软件、文档)、应用程序和实时媒体流.