云上业务稳定性保障实践白皮书

CATALOG4.2.5数据记录上报225.2直播业务稳定性保障525.2.2直播业务监控最佳实践575.3.2全链路压测与容量评估675.3.3高可用架构建设745.3.4故障演练与紧急预案设计随着客户云上业务规模不断扩大，迭代速度不断加快，系统复杂度也升，如何保障云上业务稳定性这个话题也变的愈发重要。本书将从理论概念出发、围绕故障管理体系和变更管控体系展开，并根据各行业客户稳定性实践经验，对云上业定义，所以当一个业务系统接收到输入后，可以产生符合系统是稳定的，否则业务系统是不稳定的。一个产品/系统其实可以分为一个个循环MTTR)来度量。通常业界习惯用N个9来表征系统可用性，比如99.9%(3-9avail-可用性概念在各个业务上的落地实践即为业度量的重要指标之一，通过选取一个或者几个业务核心指标，程度和持续时长作为影响该业务可用率的定义。围绕业务场标设定、系统监控能力建设，及通过目标关联，最终达成联•电商全站交易可用率目标99.995%•可用性事件定义：因故障引发，全站交易创建、支付笔数99%3.65天99.9%99.99%99.999%ITIL中定义故障为IT服务意外中断或IT服务质量降低。且尚未对服务产生影响的以阿里巴巴经济体为例，其故障定义为除用户方环境或况外，其他无论什么原因导致的服务中断、服务品质下降或者用户服务体验下降的事无论理论还是实践，均证明故障只要有发生的可能，它总会发生。所以故障管理是很有必要的。故障管理是围绕故障全生命周期采取的一系列控制流程，包括故障等级定义、故障发现、故障响应、故障定位、故障恢复、故障复盘及持续改进(含故障演练)。故障管理的目标是预防可预知的问题，快速恢复不能预知的问题，以及确保已发生的问题不再重复发生。这也是保障、提升业务稳定性的有效手段，通过建立一个规范可遵循、全流程闭环的故障管理体系，配合技术手段的提升，来降低故障发生ECSVPCEIPElasticIPSLSPTS是一款具备分布式压测能力的SaaS压测平台ACK游戏CBAES•在最高故障等级P1确定的情况下，依次降低影响面，形成P2-P4的标准(大体量业务的主路径失败可以考虑P3起，不设置P4级别故障)，如30%-20%，45%-30%等影响面对应剩余等级。故障等级定义制定好以后，需要得到技术负责人的审批，以及后续面向技术团队故障分是阿里巴巴独特的故障衡量机制，通过算法赋予故障一个分值，解决了传统故障考核中的只看个数不看故障严重程度(持续时长，影响范围等)的弊端，同时有其中Pscore根据故障的等级及综合影响范围来确定，Trati来确定，Eratio根据故障引发的附加影响面(如重大舆情，重大资金损失)来确定。此同时各个技术团队可在财年之初设定一个总体的故障分Budget，基于历史故障分情况并结合新财年的目标共同确定一个故障分目标。并将各个团队的数据以报表的方式定期进行通晒。同时针对一些典型的故障，在更大范围内进行解读和分享，以达故障发现是基于监控报警能力，通过多角度、多场景覆盖的在故障出现的第一时间通知到相关处理的人员进行应急恢复。故障的监控发现率是衡量风险衡量风险防控能力的关键指标。为保证故障发现率，故障场景监控覆盖率建议业务监控：通过采集应用程序中的业务状态数据，如接口的请求次数、成功率和响应时长等，产出业务级别的监控指标，以数据反映业务健康状况，从而完成用户反馈监控：主要从舆情、客诉等反向收集用户对功能可用性的反馈，作为一监控有效覆盖后，随着业务复杂度的提升，告警会越来越多，如何将海量的监控进行有效整合和有效通知，就成为了另一个复杂的问题。做法是将监控项和前面的故障等级定义场景进行关联，将各类重要的监控能力都聚合到监控中台，由负责故障处理人员的7*24监控中心来对达到故障等级的告警进行故障通知和升级。最终目标是故障发生后，需要及时启动故障应急。故障应急是一个专业的协同工作。整个过程牵涉到多个角色以及需要各个角色高效有序地完成自己的工作。当系统发生问题时，应急的第一原则是，先止血恢复、再定位原因。要使用一切可能的手段让系统恢故障应急是需要7*24H的应急值班机制，保率无法达到100%，需要人工判断是否真实异常。另一方面各业务部门的故障标准存在差异，误发、漏发都会产生较大影响，故障需要人工确认发送。且故障处理过程需故障应急效果的度量标准可从通告及时率、准确率、快恢执行率来考量。提升故障应急效果首先需要明确人员职责。下面对故障应急过程中的重点角色和职责进行介故障处理人(技术支持、监控值班)：负责故障应急启动、确保应急有序、协调各方资源确保故障快速恢复；同时，在应急过程中，及时更新故障直播间内容，确保各应急处理人(研发、测试、稳定性接口人等)：根据应急指挥人明确的分工，负责故障定位、快速恢复，按照SLA的要求响应故障、兜底同步进展应急指挥人：根据故障等级由不同人员担任，如P1P2故障由业务部门稳定性负责人或值班长承担；P3P4由技术团队TL或团队指定稳定性接口人承担。在故障发生时，第一时间(5分钟内)指定应急处理人的分工(A负责排查原因、B负责快速恢复、C负责同步进展)，协调故障快速恢复，兜底同步故障进展。注意：在应急止血过程人员职责明确后，另一方面也需要相关平台产品支持来确保故障应急的高效、有故障应急协同群：当故障发生后，系统会自动拉起故障应急协同群，并根据故障•一键电话会议：当故障发生后，技术支持会在故障应急协同群发起钉钉电话会当故障发生时，有时无法第一时间定位根因，此法进行止损恢复，比如找到服务最近的相关变更，进行变更回滚；针对异常服务进行服务重启等。通用的故障恢复方法一般包括重启、回滚、扩容、切流、限流、降级等。快恢的执行效率很大程度取决于是否有完备的预案和定期演练。这里给出一个相2)参与故障处理的人员分成3类角色，第1类负责快恢，第2类负责排查，第3类负责信息同步，其中快恢人员要2人以上。这里重点关注快恢人员和信息同步人员的3)快恢人员上线后分3路执行止血操作，第1路是重启和扩容，第2路是回滚，第3-1)重启与扩容：如果流量远小于集群容量如果流量大于集群容量，或是遇到对流量敏感的故障，那么要先执行限流预案，再执3-2)回滚：快恢人员通过变更管控系统检查2小时以内是否有应用发布或配置3-3)上下游依赖：快恢人员检查上游来源、下游依赖、DB与Tair、网络与磁盘等，一旦发现是应用以外的问题，立即截图并群。截图信息要包含3要素，即时间、地点(应用与容器)、错误(堆栈信息、流量统计4)第3步中的3种措施中任意一种令业务指标恢复就是达到了目标，为其他人员5)负责信息同步的人员在整个恢复过程中，一方面需要向故障群、业务方、高层通报故障处理的进展，以及需要的支持；另一方面，在其他团队的人员加入排企业基本每天都会面临新服务或新系统的上线和迭代。线上故障和事件在当前的业务架构规模和发展速度上是不可避免的。当故障发生后，如果不及时、深刻地去对故障的根因和处理过程进行分析改进，很难保证下次类似的问题不会出现甚至扩大•过程回溯：可使用5-why方法提出多个问题对处理过程进行深挖。如本次故障为什么会发生？为什么没有提前发现？过程中各个团队是如何处理的？处理过程是否•问题剖析：回溯完成过程之后，需要深层次剖析：是否流程机制层面问题？是否质量检验层面问题？是否产品业务层面问题？是否系统设计层面问题？有没有更好•经验总结：剖析出来深层次原因之后，需要切实给出可落地的Action：包括给•定级定责：完成原因和改进方案后，针对本次故障做最终的等级认可和故障责复盘文档一般包含以下内容：故障简述(故障概述、影响面、处理人等)、故障背景(业务链路)、故障时间线(着重强调【故障引入】【故障发生】【故障发现】【业务响应】【恢复执行】【故障恢复】几个时间点)、故障原因分析(建议先一句话总结，再进行具体原因剖析)、故障过程分析(可从需求评估、代码发布、故障应急等环节进当完成复盘后，如无法有效的落地执行改进，将障复盘中就需要明确改进方案并限定完成时间。制定的action需要符合SMART原•Attainable：即改进项是否可以达到。避免出现一些假大空、无法落地的改•Relevant：即要与其他改进具有一定的相关性。即尽可能避免出现孤立的改•Time-bound：即预期解决时间。这个时间建议最长不要超过三个月，避免改一个完整的action建议记录以下内容：标题、计划完成时间、负责人(及其团队或协助处理人)、验收方式及验收人、跟踪人、改进措施的类别、具体改进内容描述在改进项完成后可有选择地进行验收，如评审验收、变更是指对线上系统的任何操作(如：发布、增加、修改或移除等)，或其他对生产业务可能有影响的任何操作。基于历史经验，有一半以上的重大故障皆为变更触发，因此，变更过程的风险防御显得尤为重要，会直接变更可分为阿里云侧的产品发布变更以及客户侧的运维类变更。阿里云对变更有一套完善严格的管控、通知体系，尽可能地降低相关风险。而针对公共云客户发起的运维类变更，我们也希望能通过标准的流程规范参考，来增强变更执行人员的风险意识和操作习惯；同时也希望通过阿里云TAM的技术服务能力，在变更过程中协助提前拦截风险，提供辅助客户安全变更的能力。同时客户可参考规范逐步建立标准化的变更计划阶段：该阶段主要包含变更申请，以及申请的准入审批。变更申请需要明确变更计划、窗口期、潜在影响以及回滚方案，具体见后文准入章节。生产环境云资源的运维变更建议客户至少提前一个工作日同步至TAM，以便有充分时间评估风险并协调资源进行护航保障。阿里云侧公共云变更都会由各产品侧发起对客户进行通知，根据影响程度会有不同的通知渠道和提前日期的要求。一般会提前7天进行第一次通知。通知渠道包括官网公告、短信、邮件、站内信、电话、企业钉群推送以及TAM执行阶段：首先对变更行为进行二次校验，如确定变更环境是否满足要求，业务流量已按预期停止等。变更过程建议先在测试环境验证后，再进入生产环境变更阶段，同时灰度、分批进行。每批次间设定一定间隔时间，并进行观察记录至少一项可更更潜在影响的有损变更对客户结合历史经验以及对变更触发的故障进行分析提炼，总结出变更过程中的五大关键变更管控动作，分别是：准入、灰度、观测、回滚和数据上报。下面结合公共云对准入是由一系列校验规则来判断这个变更是否被允许执行。根据具体场景一般可一种典型的灰度机制，是提供一套完整而独立的测试环境，用于正式生产变更前的提前验证。另一种较为典型的灰度机制，为在生产环境分批次变更，通过细化控制变更测试环境灰度的时间点位一定要在上线生产之前。可引流内网全部流量和线上这里列举三个常见的分批方式：簇内分批、簇间串行、簇间打散，每个层面中对图中的簇指的是可以继续拆分的逻辑组，包含但不限于单元、Region、机房、线上生产环境灰度变更建议包含以下要求：可分批、可控制分批间隔、可观测/•可分批：指灰度方式必须至少满足灰度分批方式中的一项：簇内分批、簇间串行、簇间打散。确定好灰度方式后，至少需要2批进行发布。如果确实不具备灰度能•可观测：指变更系统每批次发完后，需要观测并验证本批次发布无问题后才能进行下一批次的发布。观测和验证的手段包括但不限于以下方式：在变更系统里至少•可回滚：指灰度时需具备分批回滚、全量回滚的能力，回滚单要有变更记录并变更观测是指在变更执行过程中，任何因变更触发的且预期外的线上业务异常(含监控、报警、日志等)均能实时被变更执行人感知的能力。是变更人主动并及时发现问题，降低重大故障影响半径的有效方式之一。变更观测是变更执行•变更执行期间需有效观测：变更系统逐步实现强管控，所有变更从第1批执行•变更执行每批次灰度均需观测：变更执行时需全程进行变更观测，确保验证该•每批次变更需保证充分的观测间隔时长：各业务可结合自身经验，推行适合各变更回滚是指当服务、配置或数据出错时，能顺利恢复到最近一个正确版本的可逆操作，且回滚范围应同变更前的范围一致。任何线上变更需具备回滚方案，如果发生概率性风险事件或者未知风险导致的系统或业务异常，必须有相关的措施可以第一对回滚进行模型提炼和属性解构，根据变更对象恢复到变更前状态的方式，可以又称回退模式回滚，主要指将变更对象从当前状态回退到变更前状态的回滚执行变更前，线上服务处于A状态，变更执行使得线上服务处于B状态，此时进行变更回滚，则线上服务会恢复到变更前的A状态，用状态机表达式可以描述为：roll-back:A->B->A。态即为变更前状态值的回滚方式。执行变更前，线上服务处于A状态，变更执行使得线上服务处于B状态，此时进行变更前滚，则线上服务会前进至A'状态，但A'状态同A状态满足内容一致性，用状态机表达式可以描述为：roll-forward:A->B-A'。化回滚操作。为实现一次成功回滚，需具备如下五个基本要素：变更对象、回滚模为了能够在变更、故障原因定位、故障快速恢复等过程中及时获取相关变更信息、把控变更环节，变更系统应该具备将用户变更过数据上报应该覆盖整个变更生命周期中的主要信息，执行中的分批灰度、执行结束后的回滚都需要将完整的变更•变更准入类：包括变更系统、变更类型、变更对象、变更单号、变更时间、变•变更执行类：包括本次变更操作的总体信息，批次信息，变更系统，变更类游戏业务因为转化周期短、成本控制、合服滚服架构复杂度等因素，很少会有自身架构上的高可用设计，业务稳定性基本依赖云厂商，且对网络延迟、宕机率敏感，尤其在新游上线初期，部分客户对游戏服ECS的稳定性甚至有着0宕机的苛刻要求。因为尽管ECS宕机后可以在秒级完成迁移后启动，但受游戏进程重新拉起，客户解密加密磁盘等操作的耗时影响，宕机一般还是会造成游戏业务分钟级的不可用，以及内存数据未及时落盘导致的回档情况。且据调查结果显示、至少有60%-70%的玩家反馈如果在游戏发布当天无法进行游戏，他们是不愿意再碰这款游戏的。所以新游上线初期需的稳定性保障是一个巨大挑战。阿里云TAM团队经过多个游戏项目的沉淀打新游上线的过程一般分为开发阶段、部署测试阶段和内测(CB)/公测(OB)阶段。客户侧对接人一般会涉及为项目组和运维组，项目组主要对服务端/客户端的业务逻辑层面稳定性负责。运维组主要对业务部署、云产品选型、安全方案的制定以及压测质量负责，阿里侧主要负责云上的稳定性保障：例如ECS稳定性，云上架构优化、风险排除等。阿里云稳定性保障团队一般由架构师SA、技术服务经理TAM、售后技术专家AES、产研团队组成。本文只重点讲解稳定性保障相关工作，护航整体安排可参CB阶段服务端/客户根据CB测试风险评估ECS稳定性重保策略制定压测产品选型一般由架构师SA和产品架构师PDSA主要负责，合理的产品选型是业务稳定性的基础，需要针对游戏业务的对应特点选择合适的产品类型，常见的游戏选型单服高PCU，对计算性能高网络PPSDDos攻击在游戏行业较为普遍，会造成游戏体验卡顿、延迟和掉线，导致玩家流失，造成巨大的经济损失，所以安全防护是新游上线不可或缺的一环。客户出于成本考虑可能在正式OB(公测)前才会基于业务带宽情况正式确定并部署安全防护。一般方案都是在原生防护和高防IP中选择其一或组合使用。安全防护方案制定主要从网络延迟、防护带宽能力和性价比方面考虑。一般客户都会先进行POC测试，来确定增加安全防护后的网络延迟变化是否能满足业务需要，同时通过CB(内测)和业务侧ECS热迁移过程是将虚拟机在运行状态下从一个物理机切换到新的物理机。迁移过程主要通过内存和网络session的拷贝技术，实现迁移对用户业务无感或轻微感知。热迁移能力可以有效规避宕机风险，极大提升ECS稳定性。热迁移成功率主要受实例规格(内存大小)、业务负载及类型(内存读写密集，网络负载高)、库存资源情况影响。对于游戏场景，经常存在计算密集或内存读写密集的业务，这会直接影响热迁移的成功率，且各类业务对于热迁移影响的敏感度也不一样。为了保障业务稳定性，在上线前都需要进行多轮热迁移测试，覆盖全部机型、有条件最好有真人玩家，或通过机器人模拟实际业务负载水位。目的是确定客户业务对有损热迁移的接受程度，以便在热迁移成功率和业务降级之间找到平衡，制定出最佳•监控指标：主要关注迁移前后CPU、网络流量、网络连接数等是否有明显变化•业务感知：迁移过程中真人玩家是否有卡顿、掉基于测试结果，给出热迁移策略。如大规格内存实例上业务对热迁移敏感，可设置后端在检测到故障隐患后不进行自动运维，先进行内部告警，然后在TAM和客户沟通确认窗口期后再实施热迁移。如客户业务对热迁移不敏感，可打开宕机率优化和内部可通过嫦娥平台查看热迁移相关信息，如耗时、错4.ECS稳定性重保策略针对游戏场景对ECS稳定性敏感的特性，TAM通过多个项目的经验积累，沉淀出了一套前后端配合的全方位ECS稳定性重保服务策略。可以进一步提升ECS稳定侧侧户反馈。日报内存包括：今日概述;每日护航群问,将迁移结果同步给客户。侧游戏业务资源一般都涉及大量ECS计算资源实例、数据库实例和多款网络相关阿里云云产品。在重保项目启动后即可与客户对接监控需求、制定监控方案，通过与客户沟通对项目整体业务情况进一步了解后，针对客户提出的需求和项目的整体业务逻辑，以及需要重点关注的关键性监控指标，从全局到局部细节提供多种维度监控方案现场护航盯屏视角的监控需要在展示项目整体资源的同时，突出展示重点关注的关键性指标数据，具有综合性、全局性、针对性、关联性等特点。如ECS实例、CDN、EIP弹性公网IP、共享带宽包中关键性监控指标，从全局角度配置综合汇总的TOP&SUM监控数据，为客户提供新游上线玩家在线增长率趋势、TOPx游戏服用户负载和关键资源使用情况、内/外网网络带宽流量汇总、CDN域名命中率和回源带宽。通过建立ECS公网IP标签与EIP弹性公网IP标签关联，提供玩家在线请求流量和1.网络带宽：网络带宽水位过高或打满会直接导致玩家掉线或无时也可辅助发现网络攻击行为，因此网络带宽的实时监控是必须的。一般包宽包流入带宽总和、流出带宽总和，每个共享带宽的流入带宽和流出带宽等。如下2.CDN：重点关注CDN下行流量监控(边缘网络总带宽)、回,4xx，5xx等指标，如下：3.游戏服ECS：游戏服需关注总连接数，反映总体在线玩家数量情况。热门区服所在ECS的CPU内存负载监控，关注高负载时的性能波动，如下图：4.安全：包括对IP出入流量、连接数、QPS、状态码、黑洞事件、清洗事件的告演练目的是需要验证各模块的健壮性，以及在异常发生时，相关告警、异常影响,或者新的玩家请求能被转发到其他正常量小于x%,或者新的玩家请求能被转发到其他正常量小于x%,或者新的玩家请求能被转发到其他正常量小于x%,或者新的玩家请求能被转发到其他正常量小于x%于xx分钟影响的用户3、压测数据成功率大于xx%，xx%请求启服务支、程登录一后OB前需要组织前中后场配合的护航保障团队以应对为客户的直接对接人，在现场通过监控告警协助客户发现异常，并进行初步定界和技术判断，如判断为阿里云问题或疑难问题会协同中台团队中的产品垂直线专家AES一同进行分析，如确定为产品问题会引入研发进一步协同处理。如定位后需要对线上环•根据游戏类型的不同，其应用运维和部署方式也有所不同，尤其针对实时性要•根据游戏玩家的特性，游戏底层资源使用率波峰波谷现象普遍，如果没有弹性的能力和配置，波峰期会提前预留大量的资源，预定资源，如果达不到预期则会产生较大的浪费，但如果因为非预期内的超量玩家涌入，超过了最大的预留资源时，则需要利用弹性伸缩功能平台来进行扩容，这个扩容速度如果不能做到无感知，会对玩家•业务在申请特定节点资源和调度的时候，为了让业务在波峰的时候也能平稳运行，普遍都会超配资源。业务之间如无优先级的划分，当资源不足，如果没有合理的手段有效的避免业务竞争，那么也会对玩家操作体验产生明显影响。对应用资源分配•一般游戏都是以单元化模块进行部署的，比如游戏房间，对战区域等等，需要评估房间区域的资源容量，设置合适的资源请求。通过动态调度解决资源碎片的问题,提高装箱率。同时回收业务波谷时的冗余，通过弹性做到按需使用，但是不能中断以上特征和需求，都可以在容器服务以及容器架构找到,简称容器服务ACK)，支持企业级Kubernetes容器化应用的生命周期管理，可以轻ACK主要包含了专有版Kubernetes(DedicatedKubernetes)、托管版Kuberne-部署容器服务的worker节点时，需要选择对应的ECS实例类型，在阿里云控制台的购买页面上可以看到，实例规格族的选择上分成三大模块：架构、分类、具体信息。实例规格架构的类型，有三种架构类型，分别是通用的X86的架构、异构计算(第一种实例规格是通用型，顾名思义基本可以适配任何场景，所以这种型号的代第三种类型是内存型，提供更多的内存能力，所以它的CPU和内存的配比是1:8,也简称为r系列。第四种和第五种分别是大数据型和本地SSD型，这两种的CPU和内存的配比都是1:4，只是它们配的本地盘的类型是不一样的，导致它们的技能和适合的场景也是不在以上5个基础的实例规格上面，阿里云也会去做一些额外的能力提升，比如说在通用型、计算型和内存型这三种类型下，增加了一主频应该是2.5GHZ，但是有一些可以是做到3.1力就变成了高主频型，会在前面去加上一个hf这样的一个标识。针对有高计算性能的另外，随着技术的演进，阿里云神龙架构的神龙卡也是在不断地迭代和改善，搭载的神龙卡可以整体提升通用型、计算型和内存型这三种实例规格的性能，所以就会出现一个平衡增强型。对于大数据型的话，做了计算和存储的分离，形成了大数据存储型，简称为d2，而d2s是在大数据的基础上，做了一些网络能力的增强，就变成了除了特定的架构和分类，还有代系的差别，当前代表示的是最新的代越大代表它是更新的一个代系，它底层的物理硬件也会越新，它的性价比相对而言也在选择实例规格上面，需要对自己的业务特征做一些分析，包括对性能的要求，对网络的要求，形成一个基本的判断，或者可以提前做下压测对比，进而针对业务特征来选择对应的实例规格以及付费方式，只有选择最合适的规格和对应的付费方式，容器化应用会在同一个节点上部署多个业务，而每个业务都需要自己的网络空间。为避免与其他业务网络冲突，Pod需要有自己独立的网络空间，而Pod中应用需要和其他网络进行通信，就需要Pod能够跟不同的网络互相访问。进而产生了多种网络模型来实现上述容器网络的能力，阿里云容器服务平台主要包括Flannel和Terway网在Terway网络插件中，每个Pod都拥有自己网络栈和IP地址。同一台ECS内的Pod之间通信，直接通过机器内部的转发，跨ECS的Pod通信、报文通过VPC的弹性网卡直接转发。由于不需要使用VxLAN等的隧道技术封装报文，因此Terway模式网一旦集群创建完成后，不支持Flannel与Terway之间的变更切换，在实践过程Terway网络模式采用的是云原生的网络方案，直接基于阿里云的虚拟化网络中的弹性网卡资源来构建的容器网络。Pod会通过弹性网卡资源直接分配VPC中的IP地•NAT网关可以对容器做SNAT，无需节点上对容器网段做SNAT：容器访问VPC内资源，所带的源IP都是容器IP，便于审计；容器访问外部网络不依赖conntrack•Terway网络模式支持通过网络策略(NetworkPolicy)配置Pod间网络访问的规信规则的规范。NetworkPolicy资源使用标签选择Pod，并定义选定Pod所允许的通•调度层弹性，主要是负责修改负载的调度容量变化。例如，•资源层弹性，主要是集群的容量规划不能满足集群调度容量时，会通过弹出ECS或ECI等资源的方式进行调度容量的补充。两层的弹性组件与能力可以分开使务繁忙情况，在业务忙时，就要对workload扩容副本数；业务空闲时，缩容减少副容器垂直伸缩(VPA)，VPA会基于Pod的资源使用情况自动为集群设置资源占用的限制，从而让集群将Pod调度到有足够资源的最佳节点上。VPA也会保持最初容器定义中资源request和limit的占比。但是该机制的有些功能目前是处于试验阶段，需除了常规的ECS实例，容器服务还提供了虚拟节点(VirtualNode)功能，实现了Kubernetes与阿里云弹性容器实例ECI(ElasticContainerInstance)无缝连接，让Kubernetes集群轻松获得极大的弹性能力，而不必受限于集群的节点计算容量。可游戏服务随着玩家上线的多少，是存在波峰波谷的，如果设置固定的资源Request注定在波谷时会造成资源浪费，针对这样的场景，需要通过HPA基于默认的指标(CPU，内存的利用率)来自动扩容deployment和statefulset中的Pods副本数量，实现资源使用波峰或者流量突增的时候可以自动增加业务负载的副本数量，波谷或者流量较少的时候可以自动减少业务负载的副本数量，将有效提升资源整体利用整Pod的CPU和内存预留，用于提高集群资源利用率并释放CPU和内存供其它Pod使用。相较于水平自动伸缩功能HPA，其不需要调整pod副本数量，具有扩容速度更快，可以对有状态应用进行扩容(HPA不适合有状态的应用水平扩容)。自动伸缩特性使容器服务具有灵活的自适应能力。应对业务负载急剧飙升的情况，VPA能够在设定范围内快速扩大容器的Request。在业务负载变小的情况下，VPA可根据实际情况适波谷，提升资源利用率。但是其使用的范围是要求集群有空闲的资源，整个集群资源资源不足，那么就需要ClusterAutoscaler的组件能力来实现自动扩缩集群规模，在制化镜像。使用该镜像创建的ECS实例相比其它镜像创建的ECS实例，启动速度得到虚拟节点并不是节点，而是一种调度能力，可以将Kubernetes集群中的应用Pod调度到集群节点之外的资源中，而该资源不需要免客户维护的。阿里云容器服务ler默认被托管，提供免运维、强隔离、快速启动的容器运行环境。使用ECI无需购买和管理底层ECS服务器，可以关注在容器应用而非底层基础设施的维护工作，有效提个层次，通常会通过HPA、VPA等模型进行Pod的弹性伸缩，再通过cluster-auto-scaler或者virtual-kubelet进行资源层的弹性伸缩。两层之间通过Pod进行解耦，这样设计的好处是两层职责明确，坏处是解耦后相互结合的策略过于简单，无法实现更精细的调度策略，在Kubernetes中最小的生命周期管理单元是一个Pod，而传统的调度策略的。因此，如果想要控制一个负载在不同资源上的细粒度分配时，可以通过spec:•elasticUnit部分是一个数组，定义弹性单元的调度策略，如果有多个弹性单在上面的实例中，SourceTarget的副本上下限位2~4，表示当ElasticWorkload的replicas为2~4个副本时，会分配到sourceTarget，当超过4个副本时，会分配到弹性单元virtual-kubelet即ECI上，而在弹性单元virtual-kubelet中可以定义这个单弹性负载会监听原始负载，并根据弹性单元设定的调度策略，克隆并生成弹性单元的负载。根据弹性负载中副本的变化，动态的分配原始负载和弹性单元上面的副本ack-autoscaling-placeholder组件可以为集群的自动扩展提供了缓冲区，它适用于工作负载需要快速启动而无需考虑节点资源不足的使用场景。使用ack-auto-scaling-placeholder可以实现容器秒级伸缩，尽量提升扩容过程中的速度。它实现的原理就是使用优先级非常低(负数)的占位容器来超额配置，以保留其他Pod可以使用的资源。如果集群没有可用的资源，真正的工作负载也会将占位容器所占用的资源抢占，实现快速启动，然后结合同时使用Cluster-Autoscaler，迫使集群进行节点维该功能需要允许一定的资源可冗余，实现资源抢占时同时通过CA触发节点扩-name:ack-place-holderaffinity:{}理想情况下，业务应该根据实际情况，设置合理的ResourceRequest和的限制，表示容器至多可以获得的资源。这样的设置有利于容器的健康运行，资源的就会造成资源的不合理分配和浪费。建议使用资源配额(ResourceQuota)划分资若某个计算密集型任务，被调度到内存密集型的节点上，导致内存密集型的CPU被占满，但内存几乎没怎么用，会造成较大的资源浪费，同样，如果是一个内存占用型的任务，被调度到小内存的节点上，可能会频繁触发OOM。可以通过节点池设置一个Label标记，标记该类节点池是CPU密集型或者内存占用型，随后在创建Kubernetes的调度器会将这个负载调度到合适的节点上，这种寻找最合适的节原生的Kubernetes调度策略倾向于调度Pod到节点剩余资源较多的节点上，比如默认的LeastRequestedPriority策略。但是原生调度策略的资源分配是静态的Kubernetes调度器的可用资源与集群的实际闲置资源会有较大偏差。如果调度器可调度策略。调度过程中，通过参考节点负载的历史统计，将Pod优先调度到负载较低的节点，实现节点负载均衡的目标，避免出现因单个节点负载过高而导致的应用程序或节点故障。阿里云提供了ack-slo-manager组件来实现。可观测性指如何从外部输出推断及衡量系统内部状态。容器服务可观测性体系包含监控和日志两部分，监控可以帮助DevOps查看系统的运行状态，而日志可以协助容器服务ACK所依赖的底层资源的可观测场景：定位Pod与节点组成的资源池的调用链路，可视化拓扑关系，以及基础设施监控，例如宿主机节点、网络基础组件的相关实践-基础资源监控基于容器服务ACK构建系统的容器抽象层的可观测场景，包括集群的性能、事基于容器服务ACK构建系统的具体应用场景，包括应用指标性能(Metric)、系统调用链(Tracing)、日志监控(Logging)等，例如基于容器服务构建一个Java应用，相关实践-无侵入应用监控APM监控方案基于容器服务ACK构建的业务系统的具体业务场景，例如基于容器服务构建一套高可用可扩展的网站，网站的业务运营数据PV、UV等，例如应用的成本审计场景推荐使用阿里云日志服务SLS(LogService)作为自定义指标的观测方案。可通过自定义应用系统的内容、格式，并通过日志服务收集,观测自己的业务情况，或做系统审计。相关实践-通过日志服务采集Kubernetes容阿里云容器镜像服务ACR(AlibabaCloudContainerRegistry)是面向容器镜业版支持全球同步加速、大规模和大镜像分发加速、多代码源构建加速等全链路加速能力，与容器服务ACK无缝集成，帮助企业降低交付复杂度，打造云原生应用一站直播业务是近年来泛娱乐行业中最终用户有直观感受且最终用户受用成本最低的一种业务形式，直播从场景属性来分类有：电竞直播、通用直播、移动直播等，根据不同的直播属性在面向不同的技术服务场景中各有不同，且面向的监控指标与评价体系不同，在所面向的技术服务用户中，对于直播类泛娱乐的定义为，使用终端设备通互动(包含弹幕、礼物、小游戏等场景)、会员制、排名等，通过这种方式实现以平台为中心的各供应链资源、服务的整合并最终实现流量收益或者其他更明确的商业盈利提供PAAS层的接入，以SAAS层面的内容处理，这部分厂商不关心基础的IAAS资源，选择多云厂商备份的方式进行灾备冗余，平台方专心做好自己的调度策略，保但是也有部分客户基于成本、管理需求考虑，部分功能采用自建，比如转码模块自建在物理成本上能够降低，同时满足客户自身的灵活转码需求，部分客户相对于自建，采用云原生的直播方案好处在于大部分云厂商集成了稳定性的基本功能，同时也支持大量的简易开发模块，支持应对各种场合，而自建场景下，建议仅在特定有需求的模块选择自建这种模式，把持稳定性可控，否则开发成本将成倍数增本章将结合现网稳定性保障中关于直播业务的相关实践，基于电竞直播场景为读者展开直播业务稳定性保障大图，另外也将通过直播业务下的监控场景讲述如何通过近些年来随着网络直播日益发展，除传统体育赛事直播外，越来越多的大型游戏赛事引入互联网直播，电竞比赛直播日益流行，同时热门赛事直播不断得刷新着直播最高流量记录。大型赛事直播重要性高，不容出错，如何保障赛事直播稳定进行是一项值得深入研究的课题，阿里云TAM团队致力于探索护航大型赛事的最佳实践方式,沉淀赛事直播筹备经验。目前已成功保障世界杯、英雄联盟全球总决赛等大型活动重要性高、直播周期长、观众分布广、带宽量级大突增明显；以英雄联盟全球总决赛为例，每年赛事都是各大直播平台全年最重要、带宽量级最高的直播活动，比赛周期持续数月，观众分布在全球各地，热门赛事期间直播在线人数可达数亿热度，直为保障赛事直播的顺利平稳进行，赛事开始前制定稳健可靠的推拉流架构至关重在赛事场景中为提高可用性，需要具备两地中心推流架构，同时可通过阿里云内内部配置自动切换以及自动断流重连能力，客户侧推流平台需支持自动重连基于媒体类直播点播场景，通过对于当前主流客户质量监控体系模型进行提输出了客户端日志上报字段推荐、质量监控通用指标及报警方式建议。可帮助相关业务同学更清晰了解媒体类客户质量核心诉求，并为多媒体客户提供质量监控系统参在1996年，ITU国际组织就已经有了主观评要评测电话的通话质量。在2003年根据主观评价提出了一套MOS体系，MOS，ITU-TRecBT.500给出的操作范例保证了主观实验的信度和效度。将主观的视频感MOS质量评价的主要目的，是根据用户的主观体验来对音频或者是视频质量进54321视频质量：视频分辨率与屏幕尺寸的关系4分以上可以算是比较好的观看体验，视频服务时，如果用户对于视频的要求不是特别苛刻，通常情况来讲720P足够了；个别提供1080P，其实对观看体验并没有特别大的提升，仅从4.个过程不光对码率有要求，视频帧率、解码难度都会高出很多4.0分以上的观看体验的话，需要1080P的视频。高分辨率对应的解码代码也要求高，如果客户端达不到视频的解码带宽要求就会卡顿是直播经常遇到的现象。表现为用户体感界面不流畅。正常情况下人眼能否清晰的分辨出画面是否连贯是以25帧作为分界线，高于25帧到达60fps时，基本肉眼已经很难分别画面的清晰度上的差异，生活中的手机、电脑屏幕画面是按照一定频率来刷新的，但是实际上，这个只是针对普通的视频而言。对于一些强交互或者较为敏感的场景来说，比如游戏，起码需要60帧，30帧的游戏会让人感觉不适，大幅度动画30帧会有明显顿挫感；跟手动画如首屏秒开指的的是客户端拉流时播放器加载到第一帧画面被客户看到所记录的时间。首屏秒开通常被认为在100毫秒以内才算完美。公网环境下首屏秒开达到100毫秒的几乎没有，常规意义上，我们都会努力让首屏秒开做到1秒也就是1000毫秒左右观看体验包括两部分：花屏和卡顿。现在直播平台在又拍云等CDN服务商的努力一分钟内卡顿出现了多少次，每一次卡顿的时长有多少，最后得出来一个卡顿的时长直播点播可以通过一些第三方的监测评估工具进行质量监控。以公共监测工具基•缓冲前准备时间：从开始监测到第一次缓冲出现的时间，包含了DNS解析时•等待时间：等于连接时间＋首次缓冲时间+所有再缓冲时间；是一个重要的指标，系统用此值来表示流媒体文件监测的性能。缓冲次数越多，用户体验指数表现越•用户体验指数：反映用户实际播放体验的综合指标，等于等待时间(秒)+(缓冲对于应用而言，应用业务质量的数据源通常会有两个，一个是来自服务器server的日志，一个是来自客户端的日志。但是由于服务端server的日志只能记录服务端一侧的事件，对于请求发出但未抵达服务端的请求，客户端的环境信息等无法触达，如果仅依赖于服务端日志，将使得对于统计整体业务的运行情况以及对于部分异常场景客户端日志作为程序运行状态和路径的记录，是进行统计和追踪重现问题的重要•对于直播点播类应用来说，客户端日志和服务端日志的结合使用，能够更加准确地获取业务整体运行质量，并提高问题定位和解决效率。因此便要求客户端能够合•对于客户端日志，建议从业务质量指标字段和客户端信息字段两方面进行记录。其中业务质量指标字段对于直播和点播而言由于业务形态客户端信息字段则为通用字段。通常做法是客户端将日志推到SLS，然后基础SLS进1)在手机端埋点，收集由直播SDK回调的音视频帧率、码率、时间戳、以及直播3)服务单的存储可以采用Elasticsearch等存储服务，将接收的QoS数据转存到6)实现以上功能，需要端上SDK研发以及大数据团队经过长周期的测试与数据验证后才能完成监控平台建设。或者借助第三方的云平台去实现绝大部分质量监控功能,如阿里云直播SDK所集成的日志模块，结合服务端的SLS+SPARK+DATAV的形式云监控是一项针对阿里云资源和互联网应用进行监控的服务，云监控自动获取您当前阿里云账号下各云产品的资源，您可以查看目标云产品中指定资源的运行状态和各个指标的使用情况，并对监控项设置报警规则。当符合报警规则时，云监控自动发1)登录视频直播控制台。询推流超限报警信息。单击域名管理选择要设置的主播流域名，单击域名配置>基本配置>推流信息中查询可推流上限。记录推流上行并发2)登录云监控控制台。创建报警规则。单击云产品监控>视频直播>创建报警规则3)配置创建报警规则。在创建报警规则窗口，在产品列表中选择视频直播，资源范围列表中选择域名，域名列表中选择需要配置的域名，规则描述列表中选择推流上前文已简单介绍了端上日志的采集，这里不再赘述。收集主播端和观看端的设备信息、网络环境。设备信息主要是指设备机型、用户IP，以及视频流的分辨率、码率,包括播放过程中的CPU使用率、GDP使用率、内存使用率。网络环境，主要指连接方式。还有一些需要探测才能得知的数据，比如：优先收集手机到本地路由器的网络情况，然后收集手机到公网出口的环境，以及手机到CDN节点的网络情况。第三收集完之后，放到大数据中心做数据过滤、综合分析；把用户卡顿流分门别类的主要是运维人员及CDN厂商关注。告警通常会直接触达公司的运维人员。但直播服务，基本上都会用到CDN厂商的云加速服务。如果发现用户卡顿，一般最终会平台网站业务作为业务的基础建设、公司的门面，其稳定性保障也是至关重要平台网站业务一般会存在业务高峰和低谷，但是从用户体验角度来讲对外提供服务的时间段必须是24小时正常提供服务，那么一套完整的监控预警体系就非常有必从目的性出发，监控需要帮助及时发现业务出现了什么问题，所以至少需要从三•运维底层资源监控，比如CPU，内存，RT，磁盘，流量等，需要底层资源一旦出现瓶颈就能及时的报警出来，快速的判断业务请求是否合理，如果合理及时进行资源扩容，如果不合理需要针对异常请求，比如攻击进行封禁，对于问题请求进行优化•应用层面的监控，比如安全，高可用探测，数据一致性的监控，通过应用层面•业务层面监控，这块属于难度比较高的部分，但是对于业务发现问题又至关重最后的一类监控可能使用的并不是非常广泛，不过也还是比较重要的，平台网站为了确保不同地域，不同网络环境用户正常使用，还需要部署拨测监控报警机制，方便能够检测不同场景的访问异常，这种监控更多的依赖拨测点的能力建设，成本相对最常见的是直接依赖云上的agent采集获取对应的指标，通过云上已有的云监控能力可以按照业务需求获取需要的监控指标，依赖对应的云监控报警能力快速实现报jobs/exporters--采集数据的基础服务Pushgateway--数据上报的一个中转服务，上边举例里说的中转服务就是指它TSDB和PromQL--存储和查询难来到之前进行及时干预，另外一方面也能够让维护者调查起来有可以参考类似于大夫需要给病人做望闻问切和各种仪器检查来帮助病人确定病情一样，通过监控指标能够帮助快速的看到平台网站各个环节可能存在隐患，还有就是同样可以提供业务方一些指标参考评估业务运行模型，了解哪些因素会增加网站的访问量，对网站当具备完善的监控体系后，就能够对于平台网站台网站都会存在自身业务的高峰和低谷，从成本考虑业务肯定不能允许大量资源在低峰期的浪费，更不能接受业务高峰期平台扛不住压力被打垮影响用户体验，所以在这样的背景下平台网站的稳定性工作就离不开全链路压测与容量评估了，本章将重点讲明确压测目标是明确压测粒度、整理业务链路、设计压测模型、压条件。只有明确做事的目标，才能稳准快的对症下药。目前常见的压测目标可分为三描述：在系统资源濒临阈值（例如：CPU利用率濒临80%or内存溢出or硬盘使场景：一般用于评估业务系统可承受的QPS，从而判断当前系统架构是否可描述：在稳定的QPS下判断系统是否存在性能瓶颈，核心or全部业务链路是否可场景：大型运营活动前，基于预估QPS对系统进行压测，提前找出性能瓶颈证运营活动正常运行；业务链路核心功能发布前，需要对系统进行压测，避免新功能描述：压测需要知道平台系统是否能否满足业务的洪峰需求，为了应对业务大促压测模型是基于对压测目标、压测粒度、业务链路的理解，在压测实践前进行的压测功能体系化抽象，是压测实践的技术方案。由于不同的业务场景重要性不同，需要满足的可用性、稳定性不同，所以压测模型需要基于具体的业务链路进行具体分基于压测目标及业务链路的梳理确定压测场景。例如：同一个业务链路中无上下游依赖的功能接口，可在同一压测场景中通过QPS配比进行压测；同一业务链路中具有上下游依赖的功能接口，开发同学将该部分接口抽象为一个压测接口后，可与其他无依赖关系的业务接口在同一场景中通过QPS配比进行压测；不同的业务链之间无依赖，但多业务链并发访问对整体系统性能存在重要影响，该部分业务链对应的的功能性能测试PTS(PerformanceTestingService)是具备强大的分布式压测能力的SaaS压测平台，可模拟海量用户的真实业务场景，全方位验证业务站点的性能、容量和稳定性。PTS旨在简化性能压测本身的工作。PTS目标是将性能压测本身的工作持续简化，使您可以将更多的精力回归到关注业务和性能问题本身。在PTS平台上，您可以用较低的人力和资源成本，构造出最接近真实业务场景的复杂交互式流量，快速衡量系统的业务性能状况，为性能问题定位、容量配比、全链路压测的流量构造提用户可选择通过PTS控制台、PTS云端录制的方式进行可视化压测，也可以通过上传JMeter工具脚本进行性能测试，这里使用的是上传JMeter脚本实现的性能测客户通过JMeter工具将测试流程构建成剧本，本案例的场景涉及到登录、首页构建完剧本后进行本地测试，先将接口调通，接口调通后可以将剧本保存为jmx用户本地对接口域名做了hosts解析，所以在本地调试接口会请求到客户的阿里云测试环境，这块是没问题的，但如果脚本上传到PTS后，PTS的压测引擎并没有这可以在PTS控制台的高级设置中使用自定义DNS解析器，这样压测引擎就会将JMeter脚本中的接口域名解析为自定义DNS解析器中的解析配置，类似于客户本地2.上传JMeter脚本文件(这里客户只用到了JMeter环境并没有依赖，直接将jmx压力来源：这里根据客户压测场景来选择，如果是模拟用户访问，选择公网即可。如果是压测内网环境链路，本案例是模拟用户访问，所以这里选择公网，内网压测可以参考阿里云官方文档：/document_de-压力模式：PTS支持并发模式和RPS模式，用户这里主要是针对并发的压测，所流量模型：分为手动调整、均匀递增和阶梯递增，这里使用默认的匀速递增即本案例使用的默认配置，分别进行了一万和十万并发通过匀速递增的方式进行压测，当客户并发达到2万并发的时候已经触发了瓶颈，通过查看监控，核实是RDS数•TPS：每分钟处理的事务数这里主要关注成功率、平均RT、TPS几个参数：在保证成功率的情况下确认下RT响应时长，然后查看网络、集群资源、中间件、数据库等资源使用情况，测试出这样就能够实现在不同业务高峰低估业务容量的推算，在实现成本控制的同时实现平一般来讲，服务系统设计标准都是要求达到4个9或以上，也就是每年的不可用•减少单点-去单点首先要识别