类似于gg的游戏修改器推荐_除了gg修改器还有什么游戏修改器?

作者：佚名来源：网友分享日期：2024-04-19 14:16:32

大家好，今天小编为大家分享关于类似于gg的游戏修改器推荐_除了gg修改器还有什么游戏修改器?的内容，赶快来一起来看看吧。

因部分 IO 操作存在同步调用，如 dns，文件读写等，所以 libuv 使用 IO 线程将同步操作转换成异步操作；
Node.js 的 V8 默认配置为多线程 GC、Background Compilation/Optimization 的方式；

Node.js 的单进程多线程模型可以由下图表示：

Aworker 的设计是采用单进程单线程的模型，也就是将上述模型中的 worker thread 单独抽出放到一独立进程中。Worker 因此可支持 fork，从而避免从 main() 开始的启动消耗，达到快速启动的目的。

为了支持单线程，Aworker 还做了如下修改：

使用了 Linux AIO 特性替掉了 libuv 中同步的文件系统操作（不是 POSIX AIO，两者有区别。Posix AIO 类似于 libuv 现有的实现）；
使用 V8 的 SingleThread 模式，这是一个给低端设备（Low-end devices）实现的能力，不过非常符合 Serverless 资源模型；

而为了管理、隔离这些工作进程，我们需要一个轻量的业务进程容器管理组件 Turf ，该组件用于能通过 Warmfork 方式创建新的 Aworker 服务进程，并能提供一定的资源、环境的隔离能力，同时兼容 OCI。区别于传统 runc, rund 的容器，turf 旨在承载如 Aworker 这类轻 JS Runtime，它无需镜像运行，开销更低，可以支持更高的部署密度。

Alinode Warmfork 具体的对比：

提供 “被复制” 的进程，称为 “种子进程”，其他服务进程都是该进程的克隆。譬如 Aworker 作为种子进程，它需要确定自己一个 “可被克隆” 的时间点，将自己的所在状态（内存）作为克隆进程的初始状态。

Warmfork 的系统时序如下：

亮点特性二：Startup Snapshot

Warmfork 能解决了单机上服务进程的快速启动，对于冷机启动需要采用 Startup Snapshot 方案。Startup Snapshot 和 CodeCache 的区别在于 Startup Snapshot 能够保存用户代码逻辑执行状态，而 CodeCache 只保存代码解析结果、仍然需要重新执行用户代码逻辑。

设计上，Startup Snapshot 可提供携带用户代码逻辑的快速恢复，但是也有局限性：

Startup Snapshot 对内存开销敏感，如果应用启动阶段用了大量内存，可能造成负优化；
用户代码启动需要没有歧义的状态，比如 IP 地址、日期、连接状态、服务发现结果等，针对这些歧义内容用户代码需要在进程恢复时有修正能力；

V8 的 Startup Snapshot Serializer 就是一个类似于 GC 的对象遍历器。这个遍历器通过遍历加入到 Snapshot 中的 Root 对象，遍历它所对应的对象图并按照对象关系生成一系列的反序列化指令。

Startup Snapshot 相当于从 V8 Context 对象与它的 globalThis 开始，遍历堆中所有的对象并将对象关系与引用序列化成特有的字节码，形成一个线性的可存储状态。并在恢复时，解释执行这些字节码，恢复堆中的对象内容与他们之间的引用关系。

上述的两类和被调度性能相关的特性被统一归类为状态拷贝 API，具体使用可以参考官网文档中的《状态拷贝 API》章节[1]，详细介绍了命令行参数和程序内的 Events。https://noslate.midwayjs.org/docs/noslate_workers/aworker/serialize-api/

Noslated

Noslate Container Deamon，作为 Noslate Workers 解决方案的核心管控程序，提供了实例调度、弹性扩缩容、配置管理、流量管理等能力。

基于健壮性考虑，它由两个角色组成：控制面（Control Plane）、数据面（Data Plane）

Noslated 对于实例的管控主要有三个模式：

基础模式 – 基于流量的扩缩容
即抛模式 – 运行完即销毁
预留模式 – 面向历史场景兼容，在此不额外展开，详情可以查阅官网【预留策略】。

1、基础模式

当流量进入 Data Plane 后，如果没有能够处理请求的 Worker 实例，会通过 requestQueueing 事件通知 Control Plane，它会根据当前水位决定扩容数量，如果当前已无法创建 Worker 实例，会返回资源上限报错。新的 Worker 实例启动后，会自动连接到 Data Plane，Data Plane 发现新的 Worker 实例连接后会主动触发初始化请求，初始化成功后开始消费请求队列里堆积的请求。

当 Worker 实例闲置一段时间后，Control Plane 会主动发起 GC 操作，告知 Data Plane 关闭流量，流量关闭后，Control Plane 会通知 Turf 关闭 Worker 实例，清理资源残留。

2、即抛模式

针对特定的灵活场景，一次性的轻量用户脚本执行（比如特别高密度的混部执行二方任务如 SSR），为了隔离不同请求间的上下文，可以针对每个请求创建一个实例，并在执行后销毁。

比如普通的 Node.js 实例带上业务逻辑启动一般都不会太快，如果直接用了响应用户流量会难以接受。得益于 Aworker 运行时并配合 Warmfork [2]以及 Startup Snapshot [3]能力，更快完成 Worker 实例启动。亦可把一部分业务自己的初始化逻辑放置到 Warmfrok 特性中，进而让新实例都是最少的初始化时间，这才让高密度混部二方任务成为可能。

3、预留模式

在此不额外展开，详情可以查阅官网【预留策略】[4]。

二、Noslate Debugger

Noslate Debugger 是针对 V8 应用的离线分析工具，它可以分析 Node.js 等应用程序产生的 Corefile (Core 文件)：

检查 Node.js/V8 应用程序的结构体、堆栈等内容
检查 V8 堆内的各种对象信息
从 Corefile 中导出 Heap Snapshot
业务无感获取 Corefile (通过 Arthur 工具)
已支持 Node.js / AWorker LTS 官方发行版

为了更好的解决问题而不是造轮子，在未来的几个月 Noslate Debugger 也会和国内社区 Node.js 稳定性领域优秀的开源软件 Easy Monitor 共建整合，在 Node.js/V8 的问题诊断领域形成合力，也是值得期待的事情。

优点一：基于 Corefile 的 “快照” 更适应 Serverless

Serverless 应用通常会使用大量生命周期短、规格小的任务实例，但在此类任务实例上获得调试诊断能力并不容易，这使得 Serverless 应用长期处于较为黑盒的窘境。比如，Inspector 需要稳定和长时的网络连接、运行时 Heap Snapshot 需要较多的计算和内存资源，都是和 Serverless 架构背道而驰的。

不管是 V8 的对象还是堆快照，它都是 “信息” 在内存中的存储，而 Inspector 功能就是可以在 “运行时” 能提取这些信息。Noslate Debugger 通过 Corefile 将这部分调试诊断能力转移到了离线时进行，让原有实时性要求高的在线诊断调试转化为只需简单文件上传即可集成使用。

在用户本地或云端服务上提供接近用户本地开发时的调试诊断体感：

Corefile (特指 GNU Corefile 格式) 主要记录的是 Node.js 进程的内存和寄存器转储(CoreDump: 内存到磁盘的过程)。所以它也是进程完整“信息”，被用于 Linux 系统应用 Crash(有损) 的调试载体，也可用于 GCore(无损) 产生进程快照用于离线分析。

优点二：更小的业务影响

对比原有线上 “堆快照” 对业务的影响长达数分钟，到只影响业务 RT 秒级（通过 GCore），甚至只有几十毫秒（通过 Arthur 工具）。Corefile 快照也不会有任何运行时的”添油加醋”，所以它也适合那些还未被GC的对象定位，譬如诊断已经结束了的业务处理等。

Arthur 是 Noslate Debugger 中用于低影响获取 core文件的工具，利用 fork 减少进程暂停时间，LZ4 压缩减少转储体积。带业务流量的线上环境抓取，业务影响 31.106 毫秒，Corefile 大小为 338 MB （进程原使用 1.44GB 物理内存）。

三、Node.js 发行版

我们还对 Node.js 的实例进行了定向弹性场景的优化，提高了用户代码的加载速度，从而降低了冷启动时间。主要包括 Require 关系加速、Bytecode Cache，优化效果提升可高达 100% ~ 200%。该发行版，同时包含来自阿里云基础软件团队在 ARM 架构的性能优化特性。

冷启动优化

PGO（Profile Guided Optimization），是一种根据运行时 Profiling Data 来进行编译优化的技术，这里我们借鉴了这一概念。主要是通过执行一遍之后收集启动阶段的热点数据生成缓存文件，后续通过内存映射直接加载高效的缓存文件，即可获得提升在 100% ~ 200% 的用户代码冷启动优化效果。

面向特定平台架构优化

Node.js 支持包括 x64、arm64 等在内的多种架构。但针对 ARM 芯片的快速发展，上游版本往往仅提供基础适配，缺少针对新指令集的优化，导致在 ARM 芯片上无法获得潜在的性能提升。当下主流云厂商大都提供了 ARM 架构、高性价比的运行环境。Noslate Node.js 发行版针对 ARM 等平台的优化可以让应用在这些架构上获得更高的性能和效率。目前 Noslate Node.js 发行版已经在进行针对阿里云 Ampere、阿里云倚天的定制优化，未来计划包括支持龙蜥社区中的其他架构。主要包括：zlib 特性优化、其他一些利用 SIMD 的性能提升都在 PR 合并和准别中。