【AICon】探索RAG 技术在实际应用中遇到的挑战及应对策略!AICon精华内容已上线73%>>> 了解详情
写点什么

服务部署如何做到高可用?这份“三级跳”秘籍送给你

  • 2019-03-19
  • 本文字数:2996 字

    阅读完需:约 10 分钟

服务部署如何做到高可用?这份“三级跳”秘籍送给你

一个高可用的服务需要从部署、变更、预案、监控、安全等多方面考虑。如何做到 99.99%服务高可用的要求,需要各个角色的工程师共同努力。从部署的角度,本文介绍了高可用服务所需具备的规范,案例部分通过对 Yum 源服务架构的演变让读者更好的理解高可用服务部署,希望对大家有所帮助。enjoy:

高可用部署要求


图 1 高可用部署


(*注:随着服务满足高可用要求的增多,服务的高可用能力就越强)

一致性

这里的一致性指的是模块依赖的方方面面,包括但不限于硬件规格和配置、操作系统、基础软件、系统参数,还包括模块自身的相关信息,如配置文件、版本、上下游依赖组件等的一致性。可以通过配置管理工具(如 Puppet)进行管理和周期性维护,确保配置始终如一。列举一些不一致的问题,如 CPU 是否开启超线程、内存是否关闭 SWAP、操作系统版本、JDK 版本、内核各种参数、文件系统类型以及模块的配置等等,这些均可能对服务可用性造成严重影响,并带来极大的问题定位成本。

消除单点

单点有两种场景:一种是某个模块仅部署了一个实例;第二种是某个模块虽然部署了多个实例,但任意实例故障都会导致服务整体或者大面积不可用。如何识别系统单点?通过排查模块的实例数量和进行破坏性测试来发现系统中是否存在单点。对于已知的单点,则应该尽量做好预案,减少故障时长。

置放群组

要理解置放群组首先要理解故障域(Fault Domain)的概念。故障域指单个机房内由交换机或电源设备所造成故障的最大影响范围,通常为一个或一组机架。同一模块需要尽可能的分散部署在不同的故障域中,避免由单一故障域异常而导致模块整体不可用。公有云下的置放群组就是为了提高业务的高可用性,在创建时将实例以某种策略强制打散,以降低底层硬件/软件故障给业务带来的影响。举例来说,一个模块的所有实例绝不应该部署在同一个接入交换机下,因为一旦这个接入交换机故障,就会导致该模块整体故障,而一个机房内,有大量的接入交换机,是完全可以避免这种悲剧的。

流量隔离

流量隔离是搭建多套同质集群根据流量的属性进行分而治之的管理。常见的隔离策略主要基于流量的来源、重要性和资源消耗进行隔离。举例来说:


  • 基于地域分为华北、华中、华南区域的用户

  • 基于硬件类型分为 PC、APP 等

  • 基于重要性分为 VIP 用户和普通用户

  • 基于资源消耗分为报表请求和用户请求

弹性伸缩

弹性伸缩是根据业务需求和策略,针对无状态的服务,通过定时、阈值设定等方式,自动调整集群规模,在各类云厂商中,如果不是过大的系统镜像,一般都可以在 10min 内完成弹性伸缩,对于大促,机房故障等灾难场景,能够很好的提升可用性。伸缩伸缩,有伸也有缩,缩的特性,可能让集群维持在一个合理的规模上,从而避免造成不必要的成本浪费。因此,弹性伸缩也是常态下系统保持可用性的重要手段。

同城双活

同城双活即多 AZ 部署。同城机房之间延迟很低,一般 ping 延迟在 5ms 以内。同城的 AZ 间,基于网络,供电等的物理隔离,因此能够避免单个机房故障导致的服务中断。同城双活是建立在“系统消除单点”的前提下。多 AZ 间,服务请求应该尽量在一个 AZ 中处理完毕。

单元化

在同城双活建设完毕后,很多时候都会面临跨机房混连的问题。这是因为,同城双活的建设,主要以对另外一个 AZ 进行扩容为主,因此建设完毕后,或多或少都会存在一个跨机房混连的问题。而跨机房混连在单 AZ 故障后,每个模块都会出现超时和重试,会出现很多不可预期的情况。


将业务按照 AZ 的维度拆分成独立的单元,每个单元内包含完整的基础设施,包括应用程序、数据库、消息队列等,单元内是封闭的,每个单元内部的应用访问和数据库读写均在同一个单元内部完成。对于数据库读写在同一个单元内完成,很多业务是有困难的,因此可以进行折中,对于读操作在同一个单元内完成,写操作可以跨单元进行,这也是很多互联网公司的做法。即使数据库主所在的 AZ 故障,业务依然可以降级运行在只读状态,同时,数据库在分钟级别进行主从切换,进而恢复业务。

N+1 冗余

服务可以根据同城机房数量进行多 AZ 部署。N+1 中的“N”指的是处理请求所需要的资源容量,“1”指的是防止机房故障所做的资源冗余。因此,N+1 中的所有机房应该具备同等的请求处理能力,从而避免某机房故障后,其余机房无法处理所需请求。N+1 会导致一定的资源冗余,合理设置 N 的数量能够减少成本。举例来说,2 机房的冗余度就是 50%,而 5 机房的冗余度仅为 20%。

异地多活

异地多活是保证服务高可用的高阶方法。目前国内多应用在大型互联网公司,用以防御单地域整体故障。异地多活的主要问题在于跨地域带宽、成本问题以及跨地域延时较大。举例来讲,同城的延迟一般在 5ms 以内,而华北到华南的延迟可以达到 50ms 延迟,这还是使用专线的前提下。

案例 —“Yum 源服务”的高可用部署实践

Yum 源服务是一种提供 Centos 系统的 Yum 仓库的下载服务。案例以此服务为例,讨论如何搭建一个高可用的 Yum 源服务。Yum 源服务最简单的架构设计如下所示:



图 2 简单服务架构


此服务由一台云主机提供,数据存储在本地,由 Nginx 提供下载服务。


以上架构服务完全可以实现 Yum 源服务的功能。但是若此架构的服务要对外提供服务会面对如下几个问题:


  • 单机部署,服务器一旦宕机,服务就会故障;

  • 性能瓶颈,一台机器一次处理的请求数是有上限的,服务器 IO 也会成为性能瓶颈。


我们需要对架构进行调整以达到高可用的服务架构。

高可用服务 2.0v

高可用 2.0v 目的是解决上文中的问题。


首先识别服务中是否模块都支持多实例部署(消除单点):


  • 对于 Nginx 模块,Nginx 是无状态的,可以进行横向扩容;

  • 数据存储在本地磁盘也可以进行横向扩展,但是此时数据一致性将是主要问题。建议使用分布式文件系统解决数据存储一致性的问题。


服务要满足一定的并发量的要求,Nginx 具有高并发的能力,并且支持横向扩展。使用分布式文件系统以达到并发量和解决数据一致性的要求。


我们使用 Puppet 对服务器进行配置管理,保证服务器的配置一致(一致性)。每台服务器都要求不在同一个故障域中(置放群组)。高可用的服务架构如下:



图 3 高可用部署架构 2.0v

高可用服务 3.0v

3.0v 的高可用部署考虑同城双活的场景。我们选择华北两个 AZ 进行高可用服务的部署。架构图如下图所示。两个 AZ 部署同配置的服务,通过云解析将流量分配到两个 AZ 中,达到故障切换和负载均衡。



图 4 高可用部署架构 3.0v

高可用服务 4.0v

再考虑异地多活的架构,上文提到异地多活难点是数据同步。对于此服务来说,其对数据一致性并不是强依赖,短时间的数据不一致可以接受。基于地域对流量进行隔离,从而实现分而治之的目的(流量隔离)。我们选择在华南两个机房部署一套和华北机器配置一样的服务。


服务架构如下:



图 5 高可用部署 4.0V

总结

以上仅仅是高可用部署的一次简单实践。实际情况下,服务的模块几十到几百个都有,服务的复杂性与高可用是反比例关系。而且,随着服务的高可用部署特征越多,也会增加服务的复杂度,若做不好故障切换和预案建设,可能还会降低服务的可用性指标。另一方面,服务的高可用部署与成本也有密切关系,跨机房、跨地域服务部署无论在资源成本和技术能力都会产品带来挑战。所以说高可用部署需要做到的是与服务复杂度和成本之间的权衡,达到满足服务当前和未来一段时间内需求的目标。


参考文章


https://docs.microsoft.com/zh-cn/azure/architecture/reliability/


本文转载自公众号“京东云”:https://mp.weixin.qq.com/s/6uzmSl0y9eZ3HkTO49mFYQ


2019-03-19 14:5812266

评论 7 条评论

发布
用户头像
同城双活、或者同城多活,不仅仅是服务,也涉及到各类组件。例如 KAFKA/ES/HDFS 等等,大家走做到同城多活才算真正的同城多活,不仅仅是服务了。
2024-01-08 16:59 · 北京
回复
用户头像
https://mp.weixin.qq.com/s?__biz=MzIzNjUxMzk2NQ%3D%3D&chksm=e8d486a1dfa30fb71d286cf5187b21423e447c88bbaf53feabac43229b666805c41577ddcb79&idx=1&mid=2247530851&scene=27&sn=97ccc5c3d52c9ed9f13ff477b6eac324&utm_campaign=geek_search&utm_content=geek_search&utm_medium=geek_search&utm_source=geek_search&utm_term=geek_search#wechat_redirect

展开
2024-01-08 16:56 · 北京
回复
用户头像
还有一个点,应该是测试环境。对于核心业务来讲,测试环境也是必不可少的部分,也应该进行比较好的管理和维护,因此需要放在部署话题里面。
2020-04-07 10:53
回复
用户头像
参考文章:
全球 6 大数据中心,日均 10 亿日志场景下的高可用实践
https://www.infoq.cn/article/freewheel-how-to-achieve-HA
2019-11-21 10:08
回复
用户头像
还需要补充下“负载均衡”
2019-10-12 15:23
回复
用户头像
需要将具体的时间的文章,在这个地方挂上链接地址
2019-09-19 09:38
回复
用户头像
流量隔离应该扩展为隔离角度进行分析,流量隔离还是太有限了,例如读写隔离,也应该搞起来。
2019-09-18 15:39
回复
没有更多了
发现更多内容

影响音视频延迟的关键因素(一):流媒体系统

ZEGO即构

TCP udp RTC HLS RTMP

ARTS week 4

锈蠢刀

CRM往事丨三件事,所有SaaS的缩影

人称T客

搭载十代酷睿i7处理器,这台ROG冰刃4新锐拥有媲美台式游戏电脑的性能

最新动态

写代码爬取了某 Hub 资源,只为撸这个鉴黄平台!

程序员生活志

教程 Hub 资源

系统不可用总结

不在调上

学习的深度 & 深度的学习

北风

学习

我的敏捷历程 —— 兼评《敏捷整洁之道 - 回归本源》

FollowFlow

敏捷开发 Agile 极限编程 XP

大厂面试必读,JAVA进阶神书《深入理解Java虚拟机》第三版更新内容全曝光!

华章IT

JVM 虚拟机 周志明 Java虚拟机 jvm调优

nginx报错worker_connections are not enough

Java联盟

nginx

"工科生"的浪漫 百度大脑语言与知识技术峰会在七夕向你发出参会邀请

百度大脑

一个虚拟世界里栽树的公司及其启示

郭华

技术 商业模式 电影

nginx 报错 accept4 () failed (24:Too many open files)

Java联盟

nginx

云上安全工作乱如麻,等保2.0来一下

华为云开发者联盟

安全 华为云 等保 云平台 多云服务

错误的存储方案正吞噬你的成本

jinjin

SpringCloud服务注册中心双节点集群(Eureka集群)

xcbeyond

Java 架构 微服务 Eureka 集群

为啥PHP in_array(0,['a', 'b', 'c']) 返回为true?

架构精进之路

php 弱类型语言

SpreadJS 纯前端表格控件应用案例:集成 Odoo提升企业ERP表格功能

葡萄城技术团队

开源 SpreadJS Odoo

丐帮,少林,明教,武当!看看你数据分析的技能属于哪一派?

程序员生活志

Spring 为啥默认把bean设计成单例的?这篇讲的明明白白的

程序员生活志

spring Cloud Eureka Rest接口重写

xcbeyond

Java SpringCloud Eureka

“庆俞年”大战,真正受损的不是李国庆

北柯

创业 合伙人 创业者 互联网人 当当网

为什么一旦自己创业了,很难再回到公司去坐班?

北柯

创业 互联网 创业心态 上班 上班族

高效程序员的45个习惯:敏捷开发修炼之道(3)

石云升

读书笔记 敏捷开发 无限游戏

草脸识别,AI泡沫还是皇冠明珠?

郭华

人工智能 AI 商业 解决方案

程序范式的意义

soolaugust

架构 程序设计

一个数据库管理员的自我救赎之路

华为云开发者联盟

数据库 华为云 数据库迁移 企业上云 DRS

ST在keil下开发时候文件options配置的一些小技巧

良知犹存

嵌入式

Python3 for ... else ...陷阱

王坤祥

Python Python PEP

跨域问题(CORS / Access-Control-Allow-Origin)

xcbeyond

Java CORS 跨域

云原生架构的基石

soolaugust

Docker 架构 Kubernetes 容器 云原生

服务部署如何做到高可用?这份“三级跳”秘籍送给你
_文化 & 方法_勿忘我_InfoQ精选文章