一、关于ECI
自2018年ECI的正式亮相以来，历经四年的磨砺与沉淀，它已成长为阿里云serverless容器领域的核心基石，为众多公有云客户与云产品提供了坚实的支撑，每日承载着数以百万计的弹性容器创建任务。然而，尽管肩负着重大的使命，ECI却迟迟未能参与到集团的双十一大促之中。
双十一，对于阿里技术人来说，无疑是一场盛大的阅兵。其流量洪峰能否被平稳承接，成为了衡量一个产品是否稳定可靠的关键指标。今年，ASI与ECI的携手合作，为ECI赋予了新的使命——承担双十一大促的30万核算力弹性需求。我们深知，双十一大促对于整个阿里集团的意义非凡，因此，我们全身心地投入到对接、压测、护航的每一项工作中。
历经两个多月的紧张备战，我们完成了业务适配、压测等一系列工作，最终成功实现了双十一大促弹性容器的圆满交付。这背后，是ASI、ECI以及每一位参与其中的同学共同努力的结果。他们脚踏实地、用心钻研，为双十一大促的顺利进行保驾护航。
首次作为集团大促弹性基础设施的ECI，在双十一期间共使用了约400万核弹性资源。从资源的瞬时弹性、保有规模到系统稳定性，这次大促对云原生系统来说是一次前所未有的挑战。作为底层的计算单元，ECI成功地经受住了双十一弹性流量洪峰的考验，展现了serverless、容器等技术的强大威力。
然而，挑战与机遇并存。全新的系统架构稳定性也面临着不小的考验。如今，回首ECI的首次双十一之旅，我们有必要进行全面的总结。我们需要梳理在集团弹性保障方面所做的工作，提炼出可复用的经验，为其他团队提供借鉴。同时，我们也要反思在哪些方面还有改进的空间，为下一次大促做好更充分的准备。
在接下来的篇章中，我们将详细介绍ECI在稳定性方面所做的努力，以及它是如何为集团双十一保驾护航的。希望这些经验和教训，能为未来的技术发展和大促活动提供有益的参考。
二、遇到的挑战
大规模并发，作为技术领域的巨大挑战，其首要难题便在于容器保有量的剧增。随着容器数量的不断攀升，云管控系统面临的压力也日益增大。特别是在弹性场景中，我们需要在极短的时间内完成实例的生成、镜像的大规模拉取，以确保容器的顺利启动。这一连串的复杂操作，无疑对系统的处理能力和稳定性提出了严苛的要求。
面对这样的挑战，如何确保实例的大规模成功生产成为了重中之重。我们需要预先发现潜在问题，并在问题出现时迅速止血、恢复故障，这对于双十一期间业务的稳定运行至关重要。同时，在公有云环境中，我们还需要特别关注对其他客户的影响，确保业务的稳定性和客户的满意度。
为了实现这一目标，我们建立了一套完整的稳定性保障体系以及故障应对方案。其中，实例生产系统的稳定性是关键。ECI和ECS共用一套资源调度系统，但相对于ECS分钟级别的应用容忍度，ECI实例频繁的创建和删除对调度系统的要求更为严格。这不仅对系统容量提出了更高的要求，更要求我们在稳定性保障方面做出更多的努力。
此外，服务可用性的保障同样不容忽视。当ECI安全沙箱因OOM、物理机宕机或kernel panic等原因出现异常时，如果不及时从k8s的endpoint上摘除不健康的ECI Pod，可能导致请求依然被路由到这些不健康的ECI上，从而严重影响业务请求的成功率。因此，我们必须确保在任何情况下，都能迅速识别并隔离不健康的实例，以保障服务的可用性。
大规模并发带来的稳定性挑战是多方面的，但只要我们拥有一套完善的保障体系和应对方案，就能够确保业务在双十一期间乃至任何时候都能稳定运行，为客户提供优质的服务体验。
三、ECI稳定性技术建设
稳定性保障工作，始于需求收集与准备阶段，尤其对于双十一大促这样长达两个月的盛事，ECI的稳定性保障任务更是繁重而关键。为了确保大促的顺利进行，我们从大促前就开始慎重对待系统变更，减少人为因素的干扰，并秉持敬畏之心进行发布操作。我们进行了多次压测，并制定了详尽的预案，以提升系统的抵抗力稳定性和恢复力稳定性。
大促期间，我们围绕稳定性这一核心，开展了多方面的工作。我们严格控制风险，梳理关键业务依赖，提供技术保障，制定压测预案，确保运行时的稳定性，提升故障运维能力，并在大促结束后进行复盘优化。这些工作不仅是为了保障当前大促的顺利进行，更是为了沉淀出稳定性治理的经验，为今后的大促工作提供指导。
在这次大促中，我们特别关注实例生产的保障工作。由于ECI实例的高频创建与删除对管控系统提出了极高的要求，我们采用了VM复用技术来优化这一过程。VM复用技术能够延迟VM的回收，并复用容器实例的网卡、镜像和计算资源，从而减轻对管控系统的压力。从双十一的实战效果来看，VM复用技术取得了显著成效，管控系统容量保持在正常水位，为集团的双十一活动提供了稳定的弹性能力。
此次大促的成功，不仅是对我们技术实力的检验，更是对我们稳定性保障工作的肯定。我们将继续总结经验，不断优化技术方案，为未来的大促活动提供更加稳定、高效的支撑。
重调度机制在应对库存不足或远程服务调用超时等挑战时，对于保障ECI实例生产的最终一致性至关重要。我们为ECI实例生产设计了灵活的故障处理策略，包括：
fail-back（失败自动恢复）：当Pod创建失败时，系统会自动尝试重新创建，确保实例的可用性。
fail-over（失败转移）：类似于fail-back，确保在失败情况下有备选方案可用。
fail-fast（快速失败）：对于某些场景，当Pod创建失败时，系统直接报错，以便上层业务快速响应和处理。
这些故障处理策略本质上都是重调度的实现方式。在ECI管控系统中，创建请求首先进入一个队列，然后通过异步定时任务捞起并进行实际资源生产和容器启动。尽管我们已经通过多可用区和多规格的优化来提升成功率，但资源争抢、内网IP不足等问题仍可能导致生产失败。此时，我们的重调度机制会将失败的任务重新放回队列，等待下一次调度尝试。
为确保重调度的效率和稳定性，我们采取了以下措施：
退避策略：对于失败的任务，我们会计算执行周期，并根据重试次数逐渐增加执行间隔，以避免频繁重试给系统带来过大压力。
优先级策略：结合用户级别、任务类型和历史失败原因等因素，为任务分配不同的优先级。优先级高的任务将优先被调度执行，确保关键业务的稳定运行。
事件通知：每次调度失败的原因都会以标准事件的形式通知到k8s集群，以便上层业务及时获取失败信息并进行相应处理。
此外，服务容错降级也是我们在故障场景中采取的重要措施。当调用链路中的某个资源依赖出现异常时，我们会根据预设的降级策略进行限流或降级操作，避免故障扩散并保护系统的稳定性。我们实现了基于历史日志自学习的无损降级、本地cache降级和流控降级等多级降级机制，并根据每个接口的特性和调用情况选择合适的降级策略和阈值。
对于某些全局参数服务或接口，由于其特殊性，我们采用了dubbo异常直接降级的策略。当满足降级或熔断条件时，系统会自动进行降级操作，减轻对下层服务的调用压力，并为系统恢复争取时间。
通过重调度机制和服务容错降级策略的结合应用，我们能够有效地应对各种故障场景，保障ECI实例生产的最终一致性，并提升系统的稳定性和可用性。
在构建复杂的服务体系时，服务依赖的稳定性和容错能力显得尤为重要。特别是对于那些几乎不会频繁变化的依赖服务，我们采取了本地moc的策略，通过每日对SLS（日志服务）的分析，将关键数据以kv形式存储。当主服务出现故障时，我们可以迅速切换到这些备用数据，从而实现服务的无缝降级，确保降级影响面最小化。
对于其他服务降级机制，我们根据服务特性进行了精细化设计。对于大分页流控的cache创建类API，我们主要对依赖的dubbo或http服务进行降级；而对于异步补偿操作类的API，我们更侧重于对整个链路的降级，以减少故障传播的风险。此外，数据库层面的降级也是我们考虑的重点，例如通过ro库流量降级隔离，确保即使数据库出现问题，也能保持部分服务的可用性。
在保障服务稳定性的同时，我们还注重用户体验的维护。通过用户级别和API级别的流量切分，我们可以将灰度流量导向特定环境，确保新功能的上线不会对现有用户造成影响。同时，我们利用apicontext实现详细的日志debug和调用全链路跟踪能力，为核心API建立debug日志体系，支持按用户开启debug日志打印，确保在出现问题时能够迅速定位并解决问题。
在Serverless场景下，ECI管控通过异步检测机制及时发现并处理不健康的ECI实例。当检测到ECI实例不健康时，我们会修改其状态为不可用，并通知用户。随后，通过主动运维手段尝试治愈这些不健康的ECI，一旦恢复健康，控制面会将其状态更新为Ready，确保服务的高可用性。
除了技术层面的保障，我们还非常重视故障注入、应急预案和压测演练在稳定性建设中的作用。在双十一这样的关键时期，我们会进行多轮压测演练，模拟各种故障场景，并制定相应的应急预案。通过压测摸高，我们不仅可以评估系统的容量上限，还能验证降级方案的有效性，为系统的稳定运行提供有力保障。
最后，预警和监控是保障系统运行时稳定性的重要手段。我们通过构建完善的监控体系，实时关注系统的各项指标，一旦发现异常，立即触发预警机制，确保问题能够得到及时处理。
综上所述，我们通过一系列的技术手段和管理措施，确保了在面对各种挑战时，服务能够保持稳定运行，为用户提供可靠、高效的服务体验。
四、系统的健壮性
构建一个健壮的系统，关键在于不仅要降低故障的发生率，更要具备故障的快速发现和恢复能力。除了依赖预警和监控机制，运维能力的建设同样至关重要。
一个系统的健壮性往往体现在其承载能力、容错能力，以及各依赖资源的SLA（服务等级协议）保障上。特别是在云上这样复杂多变的资源环境下，任何一项资源的短板都可能成为导致整个系统崩溃的“木桶效应”中的那块短板。因此，随着系统的不断演进和完善，我们需要通过实施混沌工程等方法，主动寻找并暴露出系统的潜在弱点，进而对其进行针对性的优化，从而提升整个系统的健壮性。
同时，系统的故障恢复和降级能力也至关重要。历史上，ECS/ECI管控系统曾多次因单用户问题或系统某个环节的性能下降，导致整个服务链路的雪崩效应，进而引发严重的P1、P2级故障。作为阿里云最为复杂的管控系统之一，ECS/ECI面临着复杂的业务逻辑、众多的内部系统依赖以及潜在的多个故障点。任何一个环节出现问题，都可能引发整个链路的故障，甚至导致全局不可用。
因此，在故障已经发生时，依赖降级能力能够迅速而有效地保护我们的系统，避免故障扩散和恶化。这也是我们在稳定性建设中需要重点投入和关注的方向。通过构建完善的降级策略和机制，我们可以在故障发生时迅速切换到备用方案，确保关键业务的连续性，同时减轻对系统整体的影响。
综上所述，构建一个健壮的系统需要我们在减少故障发生的同时，不断提升系统的故障发现和恢复能力。通过加强运维能力建设、实施混沌工程以及优化降级策略等手段，我们可以确保系统在面临各种挑战时能够保持稳定运行，为用户提供可靠、高效的服务体验。