« February 2021 | Main

March 25, 2021

服务的创建和退出问题

TL;DR 系统中每个和系统活得一样久的单元(服务),都应该提供一个关闭接口,而不是释放接口。关闭只做必要操作,不必释放资源,不必和其它单元协调。整个系统退出时,只需要命令所有单元关闭,然后让世界戛然而止。


最近在和同事一起完善 ltask 。这个项目可以看成是对 skynet 的一个回顾。我们打算把它用在客户端引擎中。

在 ltask 中,原来在 skynet 里用 C 实现的 timer network 等线程都被移到了 lua 中实现。它们被成为 exclusive service ,会独占一个操作系统线程,但之外的部分和普通服务并没有太大区别。

因为这样一些基础服务也挪到了 lua 中实现,以前在 skynet 中天然而成的层级被模糊了。在 skynet 中,这些独占线程都是先于其它服务启动,而晚于大多数服务退出。它们的启动和退出流程都在 C 代码中固定下来。

当我们这次在 ltask 中试图像普通服务那样去对待这些独占线程时,处理整个进程退出的过程遇到了很多麻烦。

缘由是,这些计时器、网络、日志这些服务提供的是一些基础设施。基础设施如果实现不当,会让使用这些基础的服务在退出流程中功能缺失。设施之间还有很强的依赖关系,例如,在(手机)客户端,日志服务就依赖网络服务的功能,同时也依赖计时器。而所有服务都有可能在退出环节写日志。

在整理进程退出的代码时,修了好几个退出卡住的 bug 后,我好好的反思了设计。

当一个服务可以用名字(而不仅仅是 id )查找时,它应该区别于匿名服务。这类具名服务应该是被认为是和进程共存亡的。即,只要进程不退出,它们就不应该退出。如果是需要运行时自我更新(热更新),那么需要的是重启,而不是退出再重新创建。也就是从业务层看,如果需要从名字去找到一个特定的服务,它完全可以 cache 这个服务的 id ,且认为该服务的生命期不会短于自己。若没有错误实现,不用处理服务(退出)消失的情况。

这可以大大简化服务的实现。而剩下的难点只剩下整个进程如何优雅的退出。

进程的退出势必涉及那些在业务层面看起来永不退出的服务相继关闭。退出流程是一个充满繁杂依赖关系的复杂过程,一不小心就会死锁。我在 skynet 的应用实践中就反复意识到这点。所以 skynet 并没有在服务退出上做太多机制,而一贯主张:在服务退出前给一条消息,让它有机会去完成最少的必要操作,然后关闭整个虚拟机。

对于网络游戏服务器来说,必要操作可能只包括数据落地和关闭对外连接。这和 C++ 的 RAII 机制不同,不是所有的对象(服务)都一定要有一个构造流程和一个完全对应的析构流程;并非每个创建操作都应该严格对应一个逆向的释放操作。而仅需要考虑,当服务关闭,哪些事情是必须要做的,不要纠结其它的细节。

回头来看这次写的 ltask 。我设计成:一切具名服务都只需要响应一个可选的关闭请求。关闭只会发生一次,发生在进程退出的阶段。而关闭不等于退出,不必在关闭请求中做任何资源释放操作。关闭操作后,服务应保留相应新请求的能力,至于它是完成后续请求,还是给请求抛错,是实现者的选择,不做规范。

ltask 只要检测到 root 服务(第一个启动的服务)退出,就会认为进程需要退出。这点和 skynet 不同,skynet 的进程退出条件是所有服务均退出,现存服务数量为 0 。

这样,进程退出的权力唯一的赋予了 root 服务。root 服务可以在进程退出流程的第一阶段,向所有具名服务(无论是独占线程还是共享线程)都发送关闭请求。确认它们均关闭后,自己退出。而框架在检测到 root 退出后,会让整个世界所有服务戛然而止:没有完成的请求会立刻中断,运行了一半的 coroutine 永远不会运行下去。服务之间不会再互发任何消息,只剩下虚拟机的关闭过程。或许在关闭虚拟机的过程中,还会因为 gc 方法运行少量 lua 代码,但不会再触发调度器的任何行为。能做的事情就是释放资源。


至于具名服务的启动,就可以由名字查询服务来惰性启动。和 skynet 不同,服务的命名不再放在框架底层,而是用一个名字服务来管理。名字服务不光管理了具名服务的名字,还负责了启动它们的职责;同时也代理了关闭流程(由 root 管理)。

March 22, 2021

fbx 到 gltf 转换问题

我们的游戏引擎采用的资源格式是 gltf 2.0

gltf 在这几年发展很迅猛,我认为是 3d 文件格式中标准化做的最好的一个。可惜,游戏行业中,美术创作人员常用的 max maya 等工具对其支持还有瑕疵。Autodesk 在 2019 年作为 contributor 成员加入了 Khronos 组织,在 max maya 这些 Autodesk 工具中看到官方的 gltf 支持应该不会等太久。来自官方的消息 ,‎在 2020 的 3 月底,gltf 加入官方支持已经处于 Under Review 状态。希望今年内可以看到。

因为 Unity 的流行,fbx 是游戏行业目前的实施标准。但 fbx 是一个私有格式,并没有任何公开的标准文档。而且其格式设计有很多历史包袱,甚至连字段名都因为有 typo 而在解析的时候有多个错别字兼容备选。我们在一年多以前确定使用 gltf 格式时,已经做好了这两年过度状态的准备。工作重点就在 fbx 转换到 gltf 的工具。

fbx 到 gltf 的转换工具看似很多,但实际用起来却有各种问题。这里记录一下我们用过的方案。


一开始,我们引入了 assimp 这个工具。但有一次一个复杂的模型转换失败,我开始尝试修 assimp 的 bug ,顺便阅读了 assimp 的 fbx 导入模块。这个过程发现 assimp 比较臃肿,fbx 的 importer 部分质量也不高。fbx 文件格式本身并不复杂,assimp 用了一系列复杂的方法(可能源于它要解决的问题更麻烦)来解决这样一个不算复杂的问题。

同时,我还发现 assimp 整体的编译速度实在是太慢,超过了整个引擎项目;而且它在 mingw/gcc 上有更多构建问题。我给 assimp 提过的几个 pr 都是解决 mingw 的编译问题。

最后,我们放弃了 assimp 。记得当时还有一个遗留问题一直没有解决:在 Windows 上生成 DLL 版本时,会因为 C++ 导出符号太多,超过 64K 个而链接失败。最后不得 disable 几个不常用的文件格式来绕过该问题。


之后一个短暂的时间里,基于我阅读 assimp 中 fbx 编码器获得的知识,我尝试自己来写一个给 Lua 用的 fbx 解析模块。因为 gltf 是用 json 组织数据的,我认为只要我能把 fbx 的数据结构加载到 lua 表中,再做 gltf 的导入也不会太难。

没过多久我便放弃了这个工作。因为我发现,解析 fbx 本身不难,也不需要太大工作量。但数据结构的转换是一个非常繁杂的工作。一不小心就会有考虑不周的情况。这也是为什么世界上已经存在这么多开源转换工具的项目,临到用时都会碰见问题。以我一己之力,去维护这么一个新项目是脱离初衷的。毕竟我们是在做游戏引擎,而没有那么多人力去维护一个 3d 文件格式转换工具。


经过一番考察,我们选择了 Facebook 发布的 FBX2glTF。在当时看来,大厂出品质量有所保证。而且在 2019 年底看来,这个项目还是颇为活跃的。(最新的发布版 0.9.7 于 2019 年 9 月发布。)不幸的是,之后 Facebook 似乎放弃了维护。

我们在用这个项目的一年间,发现过一两个小 bug 。但是因为上游不再维护(合并 PR),我们改成自己维护一个私有 fork 。

直到最近,使用我们自研引擎的项目陆续开工,发现了更多的 bug 。最近在花了一段时间维护这个转换工具后,我决定再换一个解决方案。


目前的选择是使用 blender 做 fbx 到 gltf 的转换工作。blender 作为一个开源项目,对开发者非常友好。它可以方便的在命令行使用内置的 python 脚本,而不必启动其 GUI 。gltf 唯一官方的导入导出库就是给 blender 做的插件

同时 blender 对 fbx 的支持也非常好。fbx 最为详尽的非官方文档,就是由 blender 维护的。


最后:

我们的游戏项目已经开工,先招聘程序开发的小伙伴一名。工作地点在广州,属于阿里互娱的正式编制,职位大约是 P6 水平。工作内容是用我们的自研引擎开发一款手机游戏。

由于我们的引擎只提供 Lua 接口,所以开发工作基本上是基于 Lua 开发。熟悉并喜欢 Lua 语言便是基本要求。

由于引擎还不算成熟,会有一些底层的开发(优化?)工作。而且 Lua 作为嵌入式语言,通常也需要用 C/C++ 开发一些模块。这个职位需要有一些 C/C++ 开发能力。

另外,我们引擎使用了大量开源项目。日常开发会涉及编译构建这些开源项目。所以需要能独立解决编译构建中的偶发的问题。同时对 git 的使用会有一些要求。

如果有同学有兴趣,可以根据我 blog 上留下的 email 联系我。

或许我们的这个职位薪资待遇上没有什么特别的吸引力,但我相信阿里互娱可以提供一个不错的发展平台。另外,作为我带的团队,这两年我坚持的理念是:提高工作时间的效率,不用工作时长掩盖效率的低下。我们已经坚持了两年每周五天每天 8 小时工作时间零加班,应该还能坚持下去。