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

第二个方面就是配置节点的可用性的优化，配置节点存放配置信息，配置信息虽然很小的，但也可以做一些简单的优化，最简单就是独立部署 MySQL 或者是 Redis，把配置信息放到这些地方去，然后自己去保证mysql/redis的可用性。

第三个还可以用 MySQL 或者更轻量级的 sqlite 去存放这个配置的信息，由管理端自己去保证它的可用性，管理端每次添加新的 API 的时候，同时去写入到这三个配置节点里面去，然后同时写入到 API 网关的共享内存里面去，这样输入粗暴，但是简单省事，对我们快速上线的东西来说还是可以用的。

最后一个方法就是用ETCD ，把配置信息存放到ETCD里面，利用ETCD去中心化的协议去做保证它的可用性，以及一致性。这个方案相对会比较完美一点，但是它有一个问题就是我们要去 API 网关里面编写新的代码监听 ETCD等操作，我们也在逐步地向这个方案过渡。

性能优化

第三个就是性能优化，一开始我们对orange 的性能做了一个初步的测试，发现Orange性能随着它的规则数量增加，QPS 下降还是比较明显的，然后我们就去做火焰图的分析，分析之后发现 60% 的操作都会消耗在 json 操作和正则表达式的匹配操作中去，并且 json 操作占了大头。

对我们来说第一反应就是 json 操作花了这么多时间，我们是不是可以去用一个更加高性能的 json 的处理库去替换 orange 里面的 Cjson呢，对于腾讯的同学来说，都比较熟悉的是RapidJSON，因为这是腾讯第一个开源的项目，很快就把 RapidJSON 替换掉 orange 里面的cJSON，发现效果还非常明显，一下子就提升了 10%+ 的性能。

接下来是不是这样就 OK 了呢?我们继续问一下为什么要做这件事情，简单阅读了下代码，原因是还是非常简单，就是orange 自己每一次 http 请求的时候，每一个 worker 收到请求的时候都会到共享内存里面去拉取配置信息，然后去做一个json反系列化操作，变成每个 worker 的数据结构，不管这个配置信息有没有更新，都去做这件事情，作者可能是为了自己的考虑，有配置更新的时候，这样实时能知道。

我们接下来再去问自己第二个问题，就是能否不做这件事情，对我们来说，牺牲一点实时性，一个配置更新过半分钟或者隔几秒钟得到这个配置最新信息，我们是可以接受的。所以我们很简单就可以去掉上面频繁的系列化操作，就是直接起一个 Timer 去过一段时间 check 一下这个共享内存里面有没有配置信息的更新标志即可，非常简单的这样一个优化就直接把这部分的 JSON 操作直接去掉了。

所以这里有一个体会是最大的优化是不做或者是柔性的平衡，这种柔性平衡可能会包括很多方面，牺牲一些其他的资源来得到性能，牺牲内存得到性能，或者牺牲一些实时性得到性能，还包括牺牲一些产品的体验得到性能，这些都是柔性的平衡，可能需要我们花更多时间去思考。

接下来我们就去做进一步的优化，因此我们做一个完整的性能测试，一个完整的性能测试主要会包括这么七个环节，前面的三个环节都是为了第四个环节的压力测试做准备的，包括环境准备、配置调优、静态检查等等。

这里面环节当然也有自己要去注意的事情，环境准备虽然很简单，但也要考虑一些问题，就是测试机的性能和压测工具的性能往往也会有问题里面。还有测试机和被测试机的时延等等，都需要考虑，否则会影响我们测试出来的真实性。

其他的话配置调优和静态检查这两块参考一些通用总结的经验就可以去做了。

下面就开始做压力测试，压力测试需要注意的是要尽量去模拟现网的真实环境和现网的处理流程去做，如果我们只是简单做一个echo测试的话，虽然这个性能数据很高，但不一定很真实，有参考价值。所以我们在腾讯内部的一个C1的机型上面，模拟真实现网流量和配置，大概测试出来的数据在18000 QPS。这个数据比之前采用了 PHP 的同步阻塞的传统的 CGI 的方式肯定是要高一个数量级的，但不一定就没有优化的空间了。

所以接下来我们继续去做瓶颈分析、性能分析。性能分析就用到了我们性能分析神器：火焰图，OpenResty社区的同学都非常熟悉火焰图

我们把 CPU 消耗前10的操作做一个归纳，归纳出来有这么几类操作，第一个是 JSON 的操作占了9.18%。第二是 L5 的操作占了4.74%(L5是腾讯内部的一个负载均衡服务的组件)，另外一个就是正则表达式匹配占了 10.36%。其他的就是nginx的操作以及系统调用等。

接下来我们就对这三个方面的操作，看看是不是有优化的空间。首先我们看一下 L5 的这个操作有没有优化的空间，刚刚说 L5 是腾讯内部的一个负载均衡的组件，我们就把它也集成到 API 网关里面来了，他们的工作原理会跟本机的 L5agent 进行通讯，所以我们在做压力测试的时候要去看一下，在压力测试这么大流量的情况下，L5agent 是不是有 CPU 消耗，或者它有没有出错，接下来再看一下它的日志和出错情况是否正常的，然后再把这个用 FFI 的方式替换我们之前的Lua C/API的方式，看看有没有性能的提升。我们又再进一步去分析 L5 这个操作，发现它是用了阻塞的 UDP 的调用，所以这里是有风险的，它会影响到其他的协程的执行的，所以我们需要尽量地把它的超时时间设得更短一点，也尝试看看能否用 cosocket 的方式去实现 L5 的API，但发现协议没有开源等等，经过这一些列的尝试，最后放弃了这部分的优化。

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!