本文将带大家一起探索，关于腾讯云弹性计算产品的技术相关的思考总结。
在各行各业都一定程度上适用这句话：Those who talk don’t know, and those who know don’t talk.
—— 我希望你成为那个懂得原理、能做成事还乐于分享的高手。
云计算底层离不开虚拟化技术，虚拟化让人们有安全感和幸福感，它解决了资源的安全隔离和高效利用两大问题。操作虚拟机，就像在泳道里游泳，因为有挡波阻浪的泳道线，我们无需关心旁边泳道里的人是何种泳姿翻腾出多大水花，而我们总是自由自在，仿佛拥有了整个泳池。
腾讯云弹性伸缩（AutoScaling）属于IaaS层的核心计算产品，并和周边相关产品通力协作，为用户高效管理云服务器集群的扩缩容活动。腾讯云基于KVM的虚拟化技术解决了单节点物理机上虚拟机的管理，而其上的VStation调度系统完美解决了大规模分布式的物理机集群的管理、虚拟机资源以及任务的调度、动态迁移等核心问题，并直接支持了云服务器产品（CVM）的实现，也是上层计算产品——弹性伸缩、轻量应用服务器（Lighthouse）、批量计算（Batch）等云上托管计算类产品的坚实基础。弹性伸缩整合了云服务器、负载均衡（CLB）、云监控等多项服务的核心能力，让用户方便地通过云API/控制台系统灵活地管理云服务器集群，共同为用户的业务动态扩所容保驾护航。同时，弹性伸缩还是腾讯云容器服务（TKE）的基础支持。各个周边服务关系，如下图所示。
VStation作为计算产品CVM的底层分布式调度系统，其在资源管理维度上的实际效果是大大胜出彼时的OpenStack的。其中有若干原因，最重要体现在其组件间的通信方式上。二者虽然都用了消息队列，但OpenStack将其视为RPC的实现方式，各个组件彼此通讯效率低，而且还涉及服务注册发现等复杂的管理，如右图所示。而VStation的组件通信如左图，消息队列作为消息总线，而各个微服务组件只需要关心同MQ通信，而无需关注彼此的存在。
与其说VStation是独辟蹊径的创新实践，倒不如说是VStation的作者对消息队列有着更加深刻的认知和理解，把握了消息队列的本质。腾讯云后续的产品等，也都在设计上不同程度借鉴了这种消息总线的模式。
弹性伸缩（AutoScaling），作为IaaS层的核心托管服务，其运转是否稳定高效，直接体现了云服务商的技术水平和专业性，并会直接反映为用户对云服务商的产品的信心。官网的AS简介可以概括为典型场景：“削峰填谷”——根据业务负载动态调整资源（云服务器集群）大小，在优化资源成本的同时不失业务的高可用性（High Availibilitiy）。但其实对于集群的日常管理，通过弹性伸缩也是可以极大提升效率的，所以那么什么时候用AS呢，答案是：
“如果你的业务需要1台以上的云服务器，你就该考虑用AS了。”
弹性伸缩（AutoScaling）主要解决了横向水平扩容场景下的问题（scale out），即通过增加云服务器实例数来增加系统服务能力。就像聚餐人数增加时，每类（热菜、甜点等）菜多上一份不同的，人再多时甚至加一个同样的整桌，而不是每个菜都来一个“大份的”，即通过实例副本和规模化来提升效率，降低综合成本。
在真实场景中，业务架构是伴随业务发展而不断演变的。
从第一阶段的单体服务最小化验证：
到多终端、多后台服务的动静拆分：
再到更复杂的微服务化：
腾讯云的云服务器（CVM）和弹性伸缩（AutoScaling）将陪伴用户业务发展的每一个阶段，一起见证用户的业务和架构的日新月异。
当然，弹性伸缩（AutoScaling）服务本身也是持续续高速增长的业务：
弹性伸缩（AutoScaling）作为IaaS层基础服务，其本身自诞生之初就一直高速增长，其典型重要客户如：超参数、小红书、VIPKid、作业帮、芒果TV、荔枝微课、Supercell、EpicGame等，覆盖各个行业。它的用户量和伸缩活动数至今仍保持持续增长，已支持着用户上百万核数的集群管理。
弹性伸缩（AutoScaling）到底为用户解决了什么问题呢？《The Art of Scalability》书中提到的扩展cube（业务、副本、数据分片维度）广为人知，不过书中的左图提到的常见方法论或设计模式其实更加有指导意义，在稳定（高可用性）、快速上线（Time-to-Market）和成本节省这三大追求中的权衡其实才是工程中真正的艺术，而设计上的横向扩展（Scale Out）是同时解决这三个问题的为数不多的方法之一（另两个是异步设计和自动化）。
Tips: 真实的客观世界没有所谓同步，只有异步；没有更新，只有打破后的重建。所谓“同步更新”那只不过是人们的幻想。系统设计时试着多拥抱事件驱动（event-driven）和不可变性（immutability）吧，生活会简单不少。
弹性 （Elasticity）—— As the extension, so the force. 弹性就是物体受到外力时变形，并且当该外力解除时恢复其初始形状的能力。固体物体受到外力时将变形。如果材料是弹性的，当这些力被移除时，物体将返回到其初始形状。按广义胡克定律，应力（stress）大小和应变（strain）成正比。
弹性伸缩（甚至整个云服务）解决的最关键问题是：让业务稳稳地活下去，持续产生社会价值。实现时两个核心思想贯彻始终：
第一，有备无患（Design for failure, and nothing will fail）.
第二，统一决策，灵活执行。顶层指令在各个执行层级间“行政发包”。重点在于广义的机制（machanism）策略（strategy）分离，strategy可以是决策/策略/设计/调度/算法，mechanism可以是机制/执行/计算/IO/任务实现/服务等。
接下来将具体说明。
伸缩活动——让业务恢复的“弹力”。弹性伸缩的伸缩活动包括扩容、缩容、不健康实例替换等等。弹性伸缩的核心就是伸缩活动的设计实现及其生命周期的管理。
伸缩活动的复杂度如何？可以认为每个伸缩活动是由若干个子步骤（Step）组成的，往往每个Step都涉及至少一次的外部微服务或API调用，可以简单地理解为一次异步IO任务，其中既有串行的，也有必须并行的，彼此的调用链路也由运行时的结果动态调整。
当然，真实的步骤已经是图中的若干倍，达到上百步，复杂度也更上了一个级别。步骤分为活动级别的步骤（下图蓝圈）和实例级别（下图绿圈）的步骤，如图所示。简单算下，如果100个伸缩活动，每个扩容100台云服务器的话，那么同一时刻（或极短时间内），按图中“最天真的”情况下，也要上万个IO请求，实际中的步骤数量其实还要大两个数量级。所以，伸缩活动，即弹性伸缩语境下的“执行任务”，其实现难度和复杂度是具备一定通用性的：即后台异步任务流程、多组件/微服务间彼此调用、业务相关的复杂分支逻辑判断、任务的多状态（异常/重试/取消）、相关涉及的元数据量大、用户任务间的上下文隔离，以及并发性能和稳定性都要求级高。
如果你做过后台的业务开发，上述情景和需求是否感觉亲切熟悉呢？
可以思考下：这类任务是计算密集型（Compute Bound）还是IO密集型（I/O Bound）呢？
实现统一的决策设计，通常需要任务流WorkFlow的步骤定义来完成。那么我们参考下图，观察下真正的Flow实际是什么样子：
我们不难发现：
1、现实的Flow不会逆流，永远向前，没有rollback（回滚）；
2、现实的Flow不是一条线，必有若干支流，而所谓的主流不过是最大（概率流经）的一支；
3、现实的Flow中的路径中的每一个点，都是独一无二的，有自己的上下文。不可能两次踏入同一条河流。
所以总结：用带Context的DAG（有向无环图）抽象Flow。不要用类似rollback/cleanup、retry、exception这些概念来实现底层框架，这些复杂的概念可以有，不过最好放在更上层抽象。
另外，要摒弃朴素耿直的线性思维，相比成功（Success）或失败（Failure），关注“下一步去哪”（Next）以及“干净地完 成”（Done）更加重要。因为前二者可能都有很多情况，比如失败的原因和结果一定有多种，任务的成功或失败都只是DAG里的一条Path而已，没有本质差异。非黑即白的二元决策往往是极不成熟且适用范围狭窄的。
当然，如果之前熟悉线性的回滚思维方式，通过简单的转换，可以将流程归约到DAG形式的描述，如图：S2是S1的回滚清理步骤，S4是S3的回滚清理步骤，左侧是线性回滚模式，右侧是归约后的同构DAG。
完成了统一的决策设计，再来看看灵活高效的执行。以下场景是人与人之间比较优雅的组织方式，管弦交响乐队的模式：
一个指挥，若干个乐器（弦乐、木管、铜管、打击）组，大家一起通力合作完成一次和谐的演奏流程。
对于整个乐团，指挥是大脑（CPU Bound），各个组的乐师是手脚（IO Bound）；对于指挥来说，他也有自己的大脑和挥舞指挥棒的双手。他们都是Actor，且互相有优雅的通讯方式。
指挥一个看起来是演奏得情绪节奏大脑，但他并没有直接下达命令到每个乐师，那么背后真正高效的组织力量又是什么呢？
下图是弹性伸缩（AutoScaling）的后台架构图简单示意：从API到任务调度器、定时任务触发器以及周边组件，都至关重要。对于伸缩活动的实际执行，其引擎组件在最后方，即图中红色的Activator服务组件，注意它同时也是一个MQ任务消费者，和你的业务中的通用消费者组件无太大差异。
放大上述的Activator，我们看到大致如下的类似交响乐队的内部实现。其中红色的就是策略核心：伸缩活动步骤定义，即WorkFlow的定义，也是全部活动的“乐谱”。Activator核心引擎负责伸缩活动的高效执行及生命周期的管理。可简单类比：
进程 = 程序 + 虚拟机 （解释器 + 运行时 + 库函数）
伸缩活动 = 步骤配置 + 执行框架（核心引擎 + 业务处理函数）
每个执行单元都是Reactor模型的异步事件处理器：上一层的“指挥”执行单元Actor查询工作流步骤表，并根据下一层的执行返回结果计算下一步的任务并分发给下层；下一层中的Actor通过总线和上层“指挥”执行单元沟通。这里面有一个分形（Fractal）的设计考量，类似递归的感觉，这种分形树状结构是最自然也最高效的组织方式，尽管理论上可以无限层次的扩展，实践应用中一般四层以内足够了。实践上，可以考虑从协程/线程/进程/节点到微服务各级别来分别递进实现。上图只是单线程内的二层分型执行引擎的设计示例。
系统设计实践先介绍到这里。关于性能，再补充两个让其质变的实现细节。
细节1：最小的执行单元（原子Actor）通过eventfd来进行彼此的消息通知，高效利用内核接口/资源，保证高性能。eventfd-with-epoll 可以保证单节点百万级的事件并发，极其适合这类高事件吞吐率的场景。
细节2：事务消息Copy-on-Write实现，通过Immutability节省空间同时保证通讯安全。注意，这里我们推荐用消息传递（Massage Passing）来实现内存共享（Memory Sharing），而不是相反。
重点无疑是策略机制分离（Separation mechanism from policy），它是处理统一策略和灵活执行之间的矛盾的最大前提和行之有效的方法。也是操作系统里最重要的概念之一，相信你还有印象。对于业务型后台计算逻辑，核心问题往往一般属于两大类：
1、资源管理：特点在于大规模，静态，可以化为后者解决
2、任务管理：难点在于执行调度、生命周期复杂状态、高并发、且动态决策
对于决策统一的诉求，在于可灵活设计组合、可靠可控，我们通过策略层采用DAG任务流张量编排来实现；
对于执行灵活的诉求，在于高性能和定制化，我们通过执行层采用分形Reactor逐层建模实现。
系统设计上，可以沿着这个思路进行优化：将需求问题转换为计算问题，再转换为IO问题，再转换为组合设计问题，最终化为策略问题，我们的系统将因满足人的需求而愈发增值。
本文所述的技术设计思想和相关方法论已在腾讯云弹性伸缩（AutoScaling）、轻量应用服务器（Lighthouse）等多个产品中实践应用，不仅有效地支持了这些核心业务的快速迭代、改善了开发效率，更重要的是大家日常的代码撸得更开心了。如果你也有兴趣，欢迎一起来讨论吧~
本文内容源于第十三届中国系统架构师大会SACC2021的直播分享《 腾讯云弹性伸缩工程优化探秘技术》
关于作者：溪歪歪 2015年加入腾讯，专注云服务产品相关领域的技术探索。负责云服务器、弹性伸缩、轻量应用服务器、GPU等产品的研发及运营工作。 长期关注高性能集群管理、分布式任务调度系统、Web全栈开发相关方向。
未完待续，敬请期待...
背景 我们知道 如果在Kubernetes中支持GPU设备调度 需要做如下的工作 节点上安装...
TIOBE 公布了 2021 年 3 月的编程语言排行榜。 本月 TIOBE 指数没有什么有趣的变...
溢价 域名 的续费价格如何？通常来说，因为溢价域名的价值高于普通域名，所以溢...
本文转载自微信公众号「bugstack虫洞栈」，作者小傅哥 。转载本文请联系bugstack...
本文转载自公众号读芯术(ID：AI_Discovery)。 这一刻你正在应对什么挑战?这位前...
想了解更多内容，请访问： 51CTO和华为官方战略合作共建的鸿蒙技术社区 https://...
前言 统计科学家使用交互式的统计工具(比如R)来回答数据中的问题，获得全景的认...
近几年，互联网行业蓬勃发展，在互联网浪潮的冲击下，互联网创业已成为一种比较...
基本介绍 给定 n 个权值作为 n 个叶子节点，构造一颗二叉树，若该树的带权路径长...
在Python开发过程中，我们难免会遇到多重条件判断的情况的情况，此时除了用很多...
