- 工程实践 -《分布式系统可用性保证方法和实践》

2024-04-13 22:04

本文主要是介绍- 工程实践 -《分布式系统可用性保证方法和实践》,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

        本文属于专栏《构建工业级QPS百万级服务》系列简介-CSDN博客


目录

1、什么是可用性

2、保障可用性的方法

2.1、可用性保障的前置手段

2.1.1、灰度验证

2.1.2、小流量验证

2.1.3、上线流程

2.1.4、前置手段总结      

2.2、可用性保障的后置手段

2.2.1、问题发现

2.2.1.1、监控

2.2.1.2、告警

2.2.2、运维手段

2.2.3、产品手段

2.2.4、后置手段总结


1、什么是可用性

        可用性是指一个系统在用户需要时能够正常提供服务的能力。需要注意,从用户的角度来看,可用性针对的功能,而不是某个系统。另外用户群体不一样,则可用性则一样。如GPT的聊天功能,“可用”意味着能秒级响应人类的输入,而对银行的大额转账功能,“可用”意味者秒级接受用户请求,小时级甚至天级完成实际转账。

2、保障可用性的方法

        首先可用性的量化指标是,可用时间/总时间,如功能在最近10小时内,有持续1小时的不可使用,则系统可用性是90%。在无限的时间中,系统不可能做到100%可用,我们保障可用性,本质是提高可用的概率

        功能是系统的一部分,从软件的角度,保障功能的稳定性,本质是保障系统的稳定性。要说明系统稳定性的保障,首先要理解系统是如果构建的。如下图,是现代软件开发的基本流程,“需求收集”、“方案设计”、“开发&自测”是由于业务不同,所以差异大,目前业界没有统一的抽象出来的与可用性相关的方法。而灰度验证、小流量验证、以及上线后的预案,是提高系统可用概率的关键。

        我们将可用性保障手段分为前置手段和后置手段。而我们的前置手段,做的都是增加可用性的概率,后置手段,做的都是快速将可用性恢复到一个高水位。        

2.1、可用性保障的前置手段

2.1.1、灰度验证

        由于开发过程中的自测,甚至QA介入的功能测试,是局部的。如果直接上线,会导致一些问题暴露到线上,如从未出现过的异常请求、不易mock的多用户并发请求。而灰度验证的核心思路,是尽可能的保障和数据链路、资源类别等与线上一致,在相同输入的情况下,验证输出的一致率。如下图,灰度环境想暴露的是“请求处理系统”从版本1升级到版本2的,可能带来的问题。有几个点,在实践中需要注意

  • 引流:在海量数据处理系统,网络成本是不可忽视的。在部分业务中,引流并不需要全量,如搜索系统中,可以引入各个区域的随机5%的流量。而对一些统计相关系统,用户之间相互影响,那流量之间不是用户独立,可能是组织独立,那就引入部分组织的流量。
  • 一致率验证系统:虽然数据、数据链路都完全一致,但是处理时间是有随机性的,所以返回数据不可避免的出现不一致的问题。我们可以做的是,让一致率保持在高水平。这里所谓的高水平和业务相关。在实践中,一个好用的方法是,让灰度版本和线上保持一致,然后观察一致率系统的diff分布作为基线,然后在灰度时,观察各场景diff分布是否符合预期+抽部分case分析
  • diff调查系统:该系统的功能是帮助快速分析diff case。本质就是根据结果,反查前置链路日志,找到问题根源。如果系统链路长,日志展示效率低,配合日志,开发一个可视化,易操作的问题分析工具或者网页,也是常态

2.1.2、小流量验证

        如下图,小流量验证,指的是线上环境,部分用户用版本1的处理系统,部分用户用版本2的处理系统。为什么有了灰度环境,还需要小流量验证,本质还是因为,在系统开发的历史经验中,我们总结出,通过灰度验证的系统,依然在可用性的概率上不够高。这里我们不再验证一致率,因为输入已经不一致,我们观察的是用户反馈,如果用户没意见,那自然系统是可用的。

2.1.3、上线流程

        通过灰度验证和小流量验证,我们已经确定了系统大概率可用。那保障已经验证的版本上线,看似简单,但是稍不注意,也会影响线上系统可用性。

        第一,使用容器保障线上环境的一致性,否则我们将有大量的精力花费在“为什么只有这台机器有问题”的低级且无意义的问题中。

        第二,保障线上的操作记录持久化,以方便每次查看上次上线的流程,以及区别。甚至,无论哪个行业、环节。减少非标准化操作,都是提升效率,保障可用性的通用方法。

        第三,对正在使用的系统,升级版本,正如对正在跑的汽车,换轮子一样。要让换轮子的操作,对司机无感,就像车型和道路有差别,那对不同业务系统的升级方式,也同样有差别。这里我举两个最常见系统的例子。分别是无状态查询系统、有状态的流式计算系统。如果对这两类系统不熟悉的,可以翻阅我之前写的《构建工业级QPS百万级服务》中的无状态服务和有状态服务的架构设计相关知识。

        对于无状态的查询系统,如下图,核心是先注销机器,再升级,再重连。这里值得注意的是,即使负载均衡不再发送请求,机器1中依然可能有正在处理的请求。所以我们不是在没有新请求进入机器1之后,就升级版本,而是机器1处理完所有请求之后。

        对于有状态的流式计算服务。我们考虑两种情况,一种状态存储在数据库中,这是为了状态持久化,以及简化业务系统;另一种是状态存储在本地,这是为了减少网络I/O,加快计算速度。对于状态存储在数据库中,升级流程如下图,值得注意的几个点是:

  • 如果2.1先执行,会有一部分数据在机器1中未得到处理,这种适用于业务可以丢失部分用户请求,如统计一个地区的雨水量,是10w升,还是(10w-1)升,并不影响后续规划。这种情况可以通过请求在此时间段重复发送,更常见的是请求转发的具体实现是消息队列,而下游采用pull的方式,那向前一段时间pull就行,不过这也只是降低了丢失数据的可能性,不能100%解决。
  • 如果2.2先执行,保证了数据至少被处理一次(不考虑机器崩溃的情况,这个我会在本文后面讲到)。但是机器1的备用机,处理的请求如果被机器1快,那可能出现,结果顺序不一致的问题,所以对于即需要请求不丢失,也需要处理顺序一致的系统,需要增加后置验证和数据修复系统。
  • 数据权限的抢占和去除,需要依赖,线性一致性系统,如zookeeper

        对于状态在本地的系统。核心思想是,通过流量复制,让不同机器状态一致之后,对系统进行升级。如下图,可以看出,使用升级还是前的数据由下游控制,对于重复流量或者数据丢失的取舍,也更容易解决。但是这样我们就长期需要双份机器,相比方案1,我们实践做出的抉择,本质上是对比的,(外部状态存储成本 + 数据I/O成本)和(双份机器成本)。这个需要结合具体的业务分析。

        

2.1.4、前置手段总结      

        总的来说,前置手段,无论哪种方式,一定是两个目的之一提前暴露可能的问题、通过抽象标准流程减少操作问题。而实践中,我们更多的精力是,结合业务,在可用性概率和成本之间做取舍。

2.2、可用性保障的后置手段

        后置手段是,指的发现问题之后,通过人为介入,让用户看到功能正确性恢复。那么即使发现问题,和发现问题后的介入手段则是快速恢复可用的关键。

2.2.1、问题发现

        业界最常用的问题发现手段是两类,服务侧的监控以及告警,用户侧的反馈。

2.2.1.1、监控

        首先服务侧的监控,一律是通过日志得到的。对CPU、内存、网络资源、磁盘等监控,是通过内核日志监控的,对业务软件的指标监控,同理也是通过对业务日志统计监控的。

        以一个《构建工业级QPS百万级服务》中,所说的查询两个日期中间的节假日数量的系统为例。大概会有如下可视化监控

  • 系统资源层面
    • 单机/集群的 CPU百分比、CPU load、内存、网络流量、磁盘。
  • 业务层面
    • nginx层的处理请求数量、延迟
    • 每个接口的请求总量,单个请求的平均大小,请求失败的数量、请求失败的原因、请求处理的延迟,请求的用户画像分布(如地区,时间)
    • 请求数据库的次数,请求延迟,请求失败的数量、请求失败的原因
    • 请求的首尾时间分布、请求在服务中每个处理流程的耗时、以及处理漏斗
    • 软件异常(如c++ 的core dump)
  • 产品层面
    • 用户的好评、差评,甚至电话至客服。这些反馈都很重要,但是尽量把问题扼杀在这个之前,否则将会有大面积用户受损

        这些监控,也要从均值、top99、max等角度拆分。另外监控不是越多越好,监控的目的只有一个,帮助发现问题,而不是展现系统逻辑。

        另外,实践中,我们要将监控分等级,如软件异常的监控的优先级,明显比请求的用户画像分布重要。为了更高效地发现问题,把重要的监控合并到一个页面是有意义的。

2.2.1.2、告警

        监控,是人发起的主动查看。但是没有人可以1天24小时,盯着监控,即使三班倒,也难免遗漏。所以我们需要主动推送的机制。而告警的基本依据是,当前数据量级和之前有一定的差距,说明系统大概率出现的不符合预期的问题

        一般的告警依据的是,当前分钟和上一分钟的指标差距,比如当前分钟请求数量比上一分钟低20%,或者当前分钟的请求延迟比上一分钟高30%。或者比昨天同一分钟去比。无论怎么比结合的都是业务流量已有的规律。而这些规律是根据历史经验总结出来的,一般来说,报警数量是大于问题数量的,这样才能减少问题出现了,但是没有告警的情况。

        告警通知,同样也按照紧急程度分为,邮件/消息/短信/电话。毕竟人的精力是有限的,太多的噪声,也是在消耗成本。

2.2.2、运维手段

        那么我们在有科学的监控之后,且监控已经帮助我们及时地发现问题了,我们怎么处理呢。

        对于系统资源相关的问题,核心思路是在保证大部分用户可用。这里的关键方法是:限流、切流 、扩容。

  • 限流的本质是损失一小部分用户的请求。比如系统内存使用达到90%时,再到达的用户直接返回失败,如果不这样做,可能会导致系统崩溃,从而所有用户都不能正常请求。
  •  切流的本质是让一部分用户请求准确性受损。比如有一个灾备机房,这个机房的软件版本降低了计算精度,减少了计算需要的资源。
  • 对于无状态的服务,如果成本在计划范围内,扩容是最好的选择。但是如果成本紧张,或者状态恢复慢,则需要在限流或者切流之后做。

        对于正确性问题,导致不可用。一般出现在新版本上线后不久,或者一个新的用户场景触发了老版本的bug。这里的关键方法是:回滚、限流、bugfix

  • 一般逻辑bug,都是出现在上线后不久。回滚到上一个没问题的版本是最好的办法
  • 但是回滚不是万能的,比如新版本上线后,多个上下游链路是配合升级的,那单模块回滚会有困难,这个时候我们只能通过上游限制流量,甚至关停服务解决。不给返回,永远比给错误的返回好
  • bugfix,一般来说不是立刻解决问题的办法。因为它也需要灰度、小流量验证。如果一个bugfix不经过验证上线,那它将可能带来更长时间,以及更严重的不可用。如果不经过验证就上线,那也只能把希望寄托给运气了

2.2.3、产品手段

        虽然我不是产品/营销/公关,这也不是我的专长。但是这几年产品崩溃的时候,我也会常常关注一个产品出现bug时,大家怎么解决的。举例前我们要明白,可用性不是产品的最终指标,最终指标是让用户满意,给用户带来价值。

  • 用户补偿:如谷歌云/阿里云/腾讯云等产品,有一段时间不可用,会再之后给用户补偿钱或产品时间
  • 舆论引导:如鹿晗时间,微博系统崩了,微博当时把中断结婚的程序员举例。获取大家的理解。以及小红书也出现过需要重新下载客户端才能使用的情况,通过道歉解决。不过这些都属于没有给用户造成显著的资产损失

        一般需要产品手段来解决,那问题就已经很大了。希望大家永远都不需要使用。

2.2.4、后置手段总结

        总的来说,后置手段,无论哪种方式,都是两个目的之一:快速恢复,降低用户影响。而实践中,快速恢复之外的方法,均已是无奈的下下策了。

这篇关于- 工程实践 -《分布式系统可用性保证方法和实践》的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/901333

相关文章

Ilya-AI分享的他在OpenAI学习到的15个提示工程技巧

Ilya(不是本人,claude AI)在社交媒体上分享了他在OpenAI学习到的15个Prompt撰写技巧。 以下是详细的内容: 提示精确化:在编写提示时,力求表达清晰准确。清楚地阐述任务需求和概念定义至关重要。例:不用"分析文本",而用"判断这段话的情感倾向:积极、消极还是中性"。 快速迭代:善于快速连续调整提示。熟练的提示工程师能够灵活地进行多轮优化。例:从"总结文章"到"用

基于MySQL Binlog的Elasticsearch数据同步实践

一、为什么要做 随着马蜂窝的逐渐发展,我们的业务数据越来越多,单纯使用 MySQL 已经不能满足我们的数据查询需求,例如对于商品、订单等数据的多维度检索。 使用 Elasticsearch 存储业务数据可以很好的解决我们业务中的搜索需求。而数据进行异构存储后,随之而来的就是数据同步的问题。 二、现有方法及问题 对于数据同步,我们目前的解决方案是建立数据中间表。把需要检索的业务数据,统一放到一张M

【C++】_list常用方法解析及模拟实现

相信自己的力量,只要对自己始终保持信心,尽自己最大努力去完成任何事,就算事情最终结果是失败了,努力了也不留遗憾。💓💓💓 目录   ✨说在前面 🍋知识点一:什么是list? •🌰1.list的定义 •🌰2.list的基本特性 •🌰3.常用接口介绍 🍋知识点二:list常用接口 •🌰1.默认成员函数 🔥构造函数(⭐) 🔥析构函数 •🌰2.list对象

浅谈主机加固,六种有效的主机加固方法

在数字化时代,数据的价值不言而喻,但随之而来的安全威胁也日益严峻。从勒索病毒到内部泄露,企业的数据安全面临着前所未有的挑战。为了应对这些挑战,一种全新的主机加固解决方案应运而生。 MCK主机加固解决方案,采用先进的安全容器中间件技术,构建起一套内核级的纵深立体防护体系。这一体系突破了传统安全防护的局限,即使在管理员权限被恶意利用的情况下,也能确保服务器的安全稳定运行。 普适主机加固措施:

webm怎么转换成mp4?这几种方法超多人在用!

webm怎么转换成mp4?WebM作为一种新兴的视频编码格式,近年来逐渐进入大众视野,其背后承载着诸多优势,但同时也伴随着不容忽视的局限性,首要挑战在于其兼容性边界,尽管WebM已广泛适应于众多网站与软件平台,但在特定应用环境或老旧设备上,其兼容难题依旧凸显,为用户体验带来不便,再者,WebM格式的非普适性也体现在编辑流程上,由于它并非行业内的通用标准,编辑过程中可能会遭遇格式不兼容的障碍,导致操

透彻!驯服大型语言模型(LLMs)的五种方法,及具体方法选择思路

引言 随着时间的发展,大型语言模型不再停留在演示阶段而是逐步面向生产系统的应用,随着人们期望的不断增加,目标也发生了巨大的变化。在短短的几个月的时间里,人们对大模型的认识已经从对其zero-shot能力感到惊讶,转变为考虑改进模型质量、提高模型可用性。 「大语言模型(LLMs)其实就是利用高容量的模型架构(例如Transformer)对海量的、多种多样的数据分布进行建模得到,它包含了大量的先验

系统架构师考试学习笔记第三篇——架构设计高级知识(20)通信系统架构设计理论与实践

本章知识考点:         第20课时主要学习通信系统架构设计的理论和工作中的实践。根据新版考试大纲,本课时知识点会涉及案例分析题(25分),而在历年考试中,案例题对该部分内容的考查并不多,虽在综合知识选择题目中经常考查,但分值也不高。本课时内容侧重于对知识点的记忆和理解,按照以往的出题规律,通信系统架构设计基础知识点多来源于教材内的基础网络设备、网络架构和教材外最新时事热点技术。本课时知识

【北交大信息所AI-Max2】使用方法

BJTU信息所集群AI_MAX2使用方法 使用的前提是预约到相应的算力卡,拥有登录权限的账号密码,一般为导师组共用一个。 有浏览器、ssh工具就可以。 1.新建集群Terminal 浏览器登陆10.126.62.75 (如果是1集群把75改成66) 交互式开发 执行器选Terminal 密码随便设一个(需记住) 工作空间:私有数据、全部文件 加速器选GeForce_RTX_2080_Ti

【VUE】跨域问题的概念,以及解决方法。

目录 1.跨域概念 2.解决方法 2.1 配置网络请求代理 2.2 使用@CrossOrigin 注解 2.3 通过配置文件实现跨域 2.4 添加 CorsWebFilter 来解决跨域问题 1.跨域概念 跨域问题是由于浏览器实施了同源策略,该策略要求请求的域名、协议和端口必须与提供资源的服务相同。如果不相同,则需要服务器显式地允许这种跨域请求。一般在springbo

AI(文生语音)-TTS 技术线路探索学习:从拼接式参数化方法到Tacotron端到端输出

AI(文生语音)-TTS 技术线路探索学习:从拼接式参数化方法到Tacotron端到端输出 在数字化时代,文本到语音(Text-to-Speech, TTS)技术已成为人机交互的关键桥梁,无论是为视障人士提供辅助阅读,还是为智能助手注入声音的灵魂,TTS 技术都扮演着至关重要的角色。从最初的拼接式方法到参数化技术,再到现今的深度学习解决方案,TTS 技术经历了一段长足的进步。这篇文章将带您穿越时