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

第一个就是可用性方面的优化，可用性这个事情，大公司里面会相对比较容易一点，因为大公司有自己更加可靠的设备或者是组件来保证底层、下面节点的可用性。而腾讯内部有这样一个接入层网关的组件叫做 TWG/STGW，它们一开始是为了把不同的运营商的流量汇集到腾讯自己的机房里面来，同时也来做负载均衡、容错等等一些可用性的保障。所以网关本身节点的可用性这个事情就很简单，直接把这个 API 网关节点挂到这个 TGW/STGW 上面来就可以了，最后三台网关机器跨机房部署，在容灾层面做了进一步的可用性的保证。

第二个方面就是配置节点的可用性的优化，配置节点存放配置信息，配置信息虽然很小的，但也可以做一些简单的优化，最简单就是独立部署 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 操作直接去掉了。

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

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

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

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

（编辑：西安站长网）

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