后羿射日般的精准 - 阿里云ECS调度是如何炼成的
弹性计算服务ECS(Elastic Compute Service)是阿里云营收的中流砥柱和流量担当。作为各行业客户新业务和技术创新的发动机和使能者,ECS不仅能在10分钟内交付出一个中等体量互联网公司所需的全部计算力,更能承载阿里集团双十一极大的峰值弹性需求以及互联网巨头客户业务高峰所需的计算力,帮助所有用户打破计算力边界的限制。
弹性计算服务ECS(Elastic Compute Service)是阿里云营收的中流砥柱和流量担当。作为各行业客户新业务和技术创新的发动机和使能者,ECS不仅能在10分钟内交付出一个中等体量互联网公司所需的全部计算力,更能承载阿里集团双十一极大的峰值弹性需求以及互联网巨头客户业务高峰所需的计算力,帮助所有用户打破计算力边界的限制。
这篇文章记录了 soluna/ltask 在移植到 wasm 和非 Windows 平台过程中遇到的一个典型工程难题:如何在主线程事件循环中执行特定任务,同时仍保留原有多线程调度模型。
问题的核心来自图形 API 和平台约束。sokol 并非线程安全,OpenGL 又依赖当前线程状态,而 wasm 环境下主线程、worker、pthread API 的边界进一步放大了调度复杂度。
作者的解决思路不是重写整个调度器,而是在 ltask 中“打洞”:让某些必须在主线程回调中执行的 Lua 任务,临时从调度表中移出,由主线程接管执行,完成后再归还给调度器。
文章最有价值的地方,是把 coroutine、Lua 虚拟机、C 栈、主线程事件循环和图形 API 约束放在同一个工程场景中分析。它不适合泛泛阅读,但对做游戏引擎、wasm 移植或复杂运行时调度的开发者很有参考价值。
这两天遇到一个任务调度算法引起的性能问题,花了颇多精力排查和解决。问题出在我写的 ltask 这个 lua 多任务库上。ltask 最初是对 skynet 的一些反思中开始的,最初只是想换一种思路实现 skynet :做一个库而不是框架、更少的锁竞争、避免服务因为消息队列堆积而过载……
数据工程的任务调度应该以“日志驱动”作为解决方案。而日志驱动的重要部分“日志解耦”正是提高系统健壮性的利器。
我们很难避免在 ECS 系统中相互引用 Entity 。而我对 ECS 模式的使用是鼓励去引用的。为此,我对许多常见依赖引用的模式给了对应的解决方案。
最近的一个 luaecs 开发版本中,提供了一种 Lua 层面的引用方案 :在创建 Entity 时,可以指定一个 table 作为该对象的引用。系统会更新它,让它保持为一个有效的(形如 select 过程中的)迭代器。这样,业务层就可以随时通过它 sync entity 中的数据。
我一直不是太喜欢这个方案,所以一直再考虑不同的解决方法。念念不忘 必有回响。昨天,我尝试了一个新的、更满意一点的方案。
目前,我们用 ECS 管理游戏引擎中的对象。当游戏场景大到一定程度,就需要有一个机制来快速筛选出需要渲染的对象子集。换句话说,如果你创建了 100K 个 Entity ,但是只有 1K 个 Entity 需要同时渲染,虽然遍历所有可渲染对象的成本最小是 O(n) ,但这个 n 是 100K 这个数量级,还是 1K 这个数量级,区别还是很大的。
我们的 ECS 系统已经支持了 tag 这个特性,可以利用 visible tag 做主 key 快速筛选可见对象。但当镜头移动时,需要重置这些 tag 又可能有性能问题。重置这些 visible tags 怎样才能避免在 100K 这个数量级的 O(n) 复杂度下工作?
ECS 模式下最难处理的是同类 Component 之间有相互联系的情况。
最方便 ECS 处理的数据是相互独立的,每个数据单元都不和其它数据单元产生联系;如果多个数据单元会有故有的联系时,当可以把它们看作是同一个实体(Entity)下的不同组件(Component)时,那么就可以借用 Entity 的概念来处理它们。我们依旧可以按固定的次序去迭代这些数据。
但是,在复杂系统中,无可避免的,同类数据相互之间也可以产生联系。例如:场景管理中,节点之间有父子关系,计算节点的空间状态的过程对数据的遍历次序有要求。且计算过程还需要访问父节点的状态。解决这类需求是 ECS 框架的一大挑战。
先来先服务(FCFS-First Come First Serve)算法,是一种随即服务算法,它不仅仅没有对寻找楼层进行优化,也没有实时性的特征,它是一种最简单的电梯调度算法。
本次分享由阿里云弹性计算架构负责人李钟(谢顿)为大家介绍阿里云region化部署和跨可用区容灾的实践经验,说明多Region部署场景中使用阿里云弹性计算的最佳实践,并结合弹性计算的实践经验探讨如何基于阿里云多可用区实现跨地域容灾。
本次内容由阿里云智能技术专家王帝(丞浩)为大家介绍如何正确使用安全组、最佳实践以及新特性;详细了解安全组为何是云端的虚拟防火墙,以及为何是重要的网络隔离手段。
首先来看第一部分 - Kubernetes 的调度过程。如下图所示,画了一个很简单的 Kubernetes 集群架构,它包括了一个 kube-ApiServer,一组 Web-hook Controllers,以及一个默认的调度器 kube-Scheduler,还有两台物理机节点 Node1 和 Node2,分别在上面部署了两个 kubelet。