江娱互动「世界争霸」产品迁移至腾讯云云函数的实践

社交，是游戏玩家的一项基本需求，那么，在游戏中，成熟稳定的聊天系统担负着玩家交流的重要使命。

做为一家从不 996 的游戏创业公司，我们的两款产品《世界争霸》和《农场小镇》都在使用自研的聊天系统。随着在线人数逐渐增多，系统的稳定性和成本面临着更多的考验。于是，升级技术栈势在必行。

至此，核心目标已经出现，以保障性能为前提，同时做到省事和省钱。最终，腾讯云的云函数产品进入了我们的视线。

云函数，无需服务器，省去运维烦恼，只需要关注于业务逻辑代码，可谓省事。按量付费，用多少花多少，避免业务低谷期的资源浪费，可谓省钱。非常适合游戏聊天系统 API 这种复杂度低的中小型需求。

那么接下来我们关注的是，现有系统能不能无缝迁移过去，也就是云函数能不能满足目前所有的特定需求，我们一个一个来说。

第一个需求：少改代码

原来的 API 部分是采用 swoole 做为底层扩展，部署在腾讯云的 CVM 上，并使用腾讯云的负载均衡来接收外部请求。代码层面则是使用了 composer 进行包管理，一款开源的 easyswoole 框架做为 http 业务的架子。

换用云函数的方案的话，非代码层面就变成了腾讯云 API 网关加云函数来提供服务，而为了方便，依然需要继续使用 composer 进行包管理。原来基于 swoole 的 http 框架无法继续使用，改代码的重点就在这里。

首先就是逻辑入口。我们需要确保用一个云函数来处理所有请求，毕竟云函数个数是有限的，而业务需求是无限的。

那么入口其实就只是一个路由而已，而我们需要做的，就是定义一种简单的路由格式，并在云函数入口代码处得到需要的信息，并转给原有的类进行处理，并返回特定的内容。

以下是一个简单的 url 格式例子：https://url/controller/action?query

只需要解析云函数给出的 path，就能得到 controller 和 action，做一些判断后，调用相应类的方法，然后返回。基于这样的入口，原有的逻辑处理类就可以被调用到了。

其次，需要处理一下原来的逻辑处理类的父类，弃用框架后需要自己来做一个基本功能的父类，比如获取 querystring 内容、解析 body，返回统一格式的返回值等，这里就不细说。