OpenResty在腾讯游戏营销技术中的应用和实践

大家上午好，我是来自腾讯的Shawn顾小平。先做一个简单的自我介绍。我在加入到腾讯之前一直在通讯行业里面从事通信软件的研发工作，包括在华为，还有UT斯达康。

2012年10月份我加入到腾讯，现在在腾讯互动娱乐事业群负责部分的营销技术相关的工作。我接触的技术工作比较多、也比较杂，所以我自称是全“沾”工程师，不敢自称是全栈工程师。从底层的单片机到嵌入式、协议栈开发，再到上层应用开发，也做过游戏的后台，现在在做营销相关的一些技术，所以各种技术都沾过，不一定很深入，但是都接触过一些。

我今天要分享的内容主要包括两大块：

• 第一块就是 OpenResty 在腾讯游戏营销 类API 网关中的应用
• 第二块是 OpenResty 在腾讯游戏广告投放系统中的应用

我的分享会偏重 OpenResty 的应用，不会涉及到太多 OpenResty 具体的技术细节方面，主要是想通过一些应用的案例来把一些优化的思想跟大家做一个分享，来抛砖引玉。

OpenResty 在腾讯游戏营销 API 网关中的一个应用

进入到第一个分享案例， OpenResty 在腾讯游戏营销 API 网关中的一个应用，下面有一个一个帽子，可能大家会比较奇怪，如果大家看过《海贼王》的同学可能就会比较熟悉，这个就是《海贼王》里面路飞的帽子，也是我们内部 API 网关的 logo，我们团队把所有做的公共性的组件、平台性的东西都以《海贼王》里面的名字进行命名，当然还有很多。

接下来就看一看我们为什么也要做 API 网关，做 API 网关的业务背景是怎么样的，因为我们是业务开发团队，一个新游戏上线之前，它是需要做大量的营销推广类活动，包括各种签到、运营、抽奖等活动。形态也各有不同，比如小游戏、小程序这种推广类的、H5l引导类的等等。

除此之外，每个游戏它都有一个自己的微社区，在每个游戏的 APP 的入口可以进到里面去，提供一些资讯、攻略、个人数据，还有一些积分，排名等等的功能，也包括赛事直播的一些内容在里面。

每个游戏都有这样大量的活动，并且这个游戏的数量还是非常大的。然后它访问的后台的流量也是非常大的，会远远超过这里面提到的数字。

面对这样一个比较复杂的业务，我们一开始的时候是怎么样做的呢?在功能的层面，我们就把它划分了很多这样相似的功能模块，大概有二三十个这样的功能模块，模块化之后是不是就没有问题呢?但其实问题依然存在，主要包括两个方面：

• 第一个方面：在开发阶段还是有大量重复性的、非功能性的模块的开发，比如：身份验证、登陆校验、流量控制、频次控制、安全等等这样的事情要做。
• 第二个方面：就是线上运行的时候也存在大量的防刷，异常用户行为，需要进行行为控制和分析，包括防刷、秒杀、抽奖类活动的一些流量控制等干预。

这样的问题都让我们去思考，怎么样去做到功能性的开发和非功能性保障的独立，以及怎么样去做统一的流量控制，那这个其实就是 API 网关要做的事情了，所以接下来我们对业界 API 网关的方案做了大量的考察和分析，大概会分为2大类：

第一类就是开源的方案，开源方案里面有我们比较熟悉的基于 OpenResty 的orange、KONG，还有其他语言的，比如 go 语言、Java 语言都有自己的 API 网关的方案。

第二个就是云的方案，各个主流的云厂商都有自己的 API 网关的解决方案，这些方案都有各自的优缺点，但是都有一个共同的问题，就是都不能满足我们业务个性化的需求，包括很多定制化的需求。另外还有一个问题，它不能和我们现有的，特别是大公司里面，现有的组件、平台要去做对接，要去做一个融合，这个很难做得到，因为它不是开源的。

所以我们基于此选择一个最简单的、最简化版的开源方案，就是 orange 的方案去做一个完全的定制化。

在定制化之前，我们看一下 orange 这个方案会有哪些问题或者不能满足需求的方面，我们从五个方面去看，这五个方面也是我们做任何技术方案选型或者考察评估的时候，可以去分析的点：

我们具体来看一下，orange 在这五个方面的不足吧：

• 易用性：orange 还是没有面向我们业务同学比较熟悉的基于应用、服务、API的配置和管理的操作界面
• 可用性： orange 把网关本身的可用性和配置节点的可用性都交给我们自己来保证。
• 性能：随着规则数增加，性能下降是非常明显的。
• 安全性：仅有一些黑白名单和一些通用的认证规则、认证的插件，用不太上。
• 可维护性：也是有一些缺失，在错误日志和染色日志，还有调用跟踪定位等等方面还是有缺失的。

接下来我们就从五个方面来说一下，我们是怎么样做优化和思考的：

易用性方面优化

第一个是在易用性方面优化，这里面有两张图，左边这张图是 orange管理端的截图，我们看得出来里有提供了很丰富的技术型的插件，有URL的重定向、重写，还有各种认证，还有限速，还有安全等等。那么它存的问题是什么呢?举个简单例子，就是我们要添加一个新的 API，那我要到所有的插件里面配置这个API 的 URL，插件下面还有选择器，以及规则都要去操作一遍，非常的重复和麻烦。

第二个问题就是对业务开发人员来说，他的思维和操作习惯，会更加关注业务，比如更加关注我的某个个应用，某个应用下面的某个服务，某个服务于下面的某个API的使用情况(认证、校验、安全、流控、统计等等方面的运行情况或者执行情况)。

所以这里有一句话就是在做易用方面的设计的时候要更加多的去考虑面向业务，而不是面向技术，我看好像KONG的配置界面也有做service的概念，越是有这个方面的考虑。

可用性方面的优化

（编辑：ASP站长网）