人人上午好，我是来自腾讯的Shawn顾小平。非常愉快今天能有这个机会来到网易大厦来分享腾讯游戏..手艺和 OpenResty 一些应用案例。
先做一个简洁的毛遂自荐。我在到场到腾讯之前一向在通信行业里面从事通信软件的研发工作，包罗在华为，还有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的概念，越是有这个方面的考虑。
可用性方面的优化
第二个就是可用性方面的优化，可用性这个事情，大公司里面会相对对照轻易一点，因为大公司有本身加倍靠得住的设备或许是组件来包管底层、下面节点的可用性。而腾讯内部有如许一个接入层网关的组件叫做 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 把持直接去掉了。
所以这里有一个别会是最大的优化是不做或许是柔性的均衡，这种柔性均衡或者会包罗好多方面，牺牲一些其他的资源来获得机能，牺牲内存获得机能，或许牺牲一些实时性获得机能，还包罗牺牲一些产物的体验获得机能，这些都是柔性的均衡，或者需要我们花更多时间去思虑。
接下来我们就去做进一步的优化，是以我们做一个完整的机能测试，一个完整的机能测试首要会包罗这么七个环节，前面的三个环节都是为了第四个环节的压力测试做预备的，包罗情况预备、设置调优、静态搜检等等。
这里面环节当然也有本身要去注重的事情，情况预备固然很简洁，但也要考虑一些问题，就是测试机的机能和压测对象的机能往往也会有问题里面。还有测试机和被测试机的时延等等，都需要考虑，不然会影响我们测试出来的真实性。
其他的话设置调优和静态搜检这两块参考一些通用总结的经验就能够去做了。
下面就起头做压力测试，压力测试需要注重的是要尽量去模拟现网的真实情况和现网的处理流程去做，若是我们只是简洁做一个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，但发现和谈没有开源等等，经由这一些列的测验，最后抛却了这部门的优化。
接下来就是 JSON 把持的优化，有前面的经验之后，我们做机能优化的时候就会问本身两个问题。第一个问题为什么要做这件事情，剖析发现，是因为我们后端的办事把所有响应的数据都做了一个JSON encode，然后API网关会进行JSON decode然后去去提取里面的一个返回码，凭据后端返回的返回码的分歧，向前端返回是200OK照样其他的HTTP的分歧的响应码，仅仅做如许一件事情。那持续问第二个问题可否不做，很显然是能够的，就是我们能够直接让后端返回数据的时候把返回码字段自力出来， API 网关的直接拿到返回码做一个判断即可，然后把数据字段直接转发给前端就 OK 了。非常简洁的一个优化，直接就能够省掉了这部门的 JSON 把持。
此外 JSON 把持的确会消费我们好多 CPU 的机能，我们一些同窗也经常在 debug 里面去打印，想把这个 debug 日志里面去打印好多数据构造里面的内容（用json.encode来打印)，然后放到生成情况上去，固然这个 debug 把持是不会执行，然则这个函数，JSON encode把持是会执行的，如许的话会导致生产情况极大的机能损耗，等等如许雷同的情形照样非常多的，所以我们在实际过程傍边照样要去属意如许一些欠好的编码的习惯。
正则表达式成家的优化
第三个就是正则表达式成家的优化。人人知道正则表达式成家都是由正则表达式引擎来做的，常用的正则表达式引擎就是PCRE，于是我们就去考虑有没有加倍高机能的正则表达式成家的引擎呢？我们也去做了一些调研，正则表达式应用最多的范畴其实是在平安范畴里面，平安范畴里面有如许的的IPS、IDS 如许的一些平安检测和防御性的产物里面会大量地使用正则表达式成家的把持，它之前也是用 PCRE 来做正则表达式的成家。后来就是在这两年的时候，都统一切换到了英特尔开源的 Hyperscan 如许的正则表达式引擎来了。
为什么它会去做如许的改变呢？Hyperscan 正则表达式引擎比这个PCRE有哪些优势呢？剖析后发现它有这么几个方面的纷歧样或许说长处。
第一个就是它不光仅是支撑块模式，还支撑流模式。所谓的流模式就是跨分歧的收集包去做一个成家，这个对平安产物是非常有效的。
第二个就是它一次能够编译多个划定，人人知道正则表达式最后都邑编译成状况机到内部去做成家的把持。
第三个就是一个输入多个划定只成家1次，它能够并行成家多个划定，这个是很厉害的。它的机能或者会很高，所以我们接下来我们就去做了如许一个验证，就是把30万条http get 恳求（包罗 URL），写到一个文本里面去。然后每个参数都做一个正则表达式的成家，用 PCRE 的代码和 Hyperscan 的代码去读这个文件，一条条读，然后成家每一个划定。发现 Hyperscan 成家正则表达式所以破费的时间的确比PCRE所花的时间低好多，也许只有后者的30%摆布的模样。所以接下来我们就非常武断地把它引入到我们的 API 网关里面来，用火焰图持续验证， CPU 的消费，从之前的10%+降低到7%只有了。
所以接下来是不是还有能够优化的空间？当然有，就是开启它的并性成家度划定的把持，这个 Hyperscan 里面也是供应了回调，然后我们只需要把每个划定设置一个标记位，然后去成家完之后搜检这个标记位今后就OK了，就能够做获得了。
此外还有一件事情是什么呢？就是正则表达式划定编写难度的问题，我们不克要求买卖斥地同窗每次都要去编写正则表达式，这个对他们来说也纷歧定编写得准确，也有一些进修的成本在里面。所以我们就去看了一下大部门的参数照样对照雷同的，所以就把这些参数的正则表达式做一些概括，然后用一些文字性的描述，做了一个模板，买卖人员就能够直接去选择这些模板就OK了，也很好的解决了这个问题。
平安性方面的优化
第四个方面的优化就是平安性方面的优化。平安性方面的优化要做的一件事情就是，它需要把我们这个 API 网关的平安策略去和公司现有的一些平安的产物做连系。腾讯内部有如许的本身的平安产物，叫门神，所以我们在 http 恳求进来post read阶段就去和平安产物做一个交互，让它去过滤流量。它过滤的流量没有问题之后，再进入到我们的平安策略里面。当然这个平安策略也相对会对照简洁，包罗有 API 白名单，设置到 API 的流量才能够进到里面来。然后还有基于用户过滤的是非名单，还有登录校验，支撑腾讯的手Q、微信等的多种校验体式，也都把它集成进来了。
此外去做参数校验，参数校验则用前面提到的正则表达式做非常严厉的必选参数的校验。此外就是若是做了非常严厉的正则表达式成家的话，SQL 防注入等等如许的问题也不会有。这个就是平安性方面的优化。
可维护性方面的优化
最后就是可维护性方面的优化，我们也做了两点：
第一是添加了一些日志和统计的功能。例如，把 4xx/5xx 等一些错误日志自力出来，此外就是添加基于某个用户id后者恳求id的染色日志跟踪打印。
第二个方面的优化纷歧定属于今天讲的内容里面的，就是我们也做了挪用链跟踪系统。API 网关在这个挪用链跟踪系统里面是作为起点，它会去生成Trace id，以及建立挪用链的上下文，以及竣事挪用链，此外就是还能够掌握挪用链跟踪的采集的频率等。
那到这里就快速简洁介绍了一下第一个应用案例，在易用性、可用性、机能，还有平安性以及可维护性这五点，我们的一些思虑和优化的过程。
OpenResty 在腾讯游戏、告白投放系统中的应用案例
接下来进入到第二部门，就是 OpenResty 在腾讯游戏、告白投放系统中的应用案例。照样和之前的内容一般，我不会涉及到好多具体的 OpenResty 的手艺的细节，首要是想跟人人分享一下案例，以及在这个案例里面一些优化的思惟。
这个案例相对会对照勇敢一点，因为也许腾讯游戏有好几个亿的..费用都邑经由这个系统投放出去。告白投放的形式有好多种，有包段告白位的、包段时间段的、包段流量的，还有通俗竞价的，还有实时竞价的。今天我想跟人人分享的就是实时竞价的告白投放形式和我们 OpenResty 的一个连系，以及 OpenResty 在里面的优化。
什么是实时竞价告白？以及实时竞价告白的流程是怎么样的？这里面有一个图。我们从最右边往左看，最右边就是我们的用户打开手机看内容，好比看头条里面的内容或许刷新闻。过程中会看到有告白位的，当刷到有告白的谁人页面的时候，这个时候 APP 就会向 ADX （告白生意..）办事器发一个告白恳求。告白生意..办事器收到这个告白恳求之后，它会去把这个告白恳求分发给下面的告白主的 DSP 办事器，当然DSP 办事器或者会有好多家，一样来说只有大型的告白主才会有本身的 DSP 办事器。
腾讯游戏作为一个对照大型的告白主，它也有本身的 DSP 办事器。它收到的告白恳求之后会怎么做呢？它会把这个告白恳求里面的流量到它的DMP（数据治理..）数据库里面去做一个判断，怎么判断？就是这个用户是不是我需要的，若是是我需要的话，我应该给他评估一个如何的代价，就是说我甘愿出几多钱给来获得这个用户的这个告白曝光机会。
这里面会涉及到一些机械进修的算法去评估这个出价，最终确定了出价之后，他会把这个出价原路返回给 ADX 办事器。ADX 办事器收到这个出价之后，它会守候其他告白主的 DSP办事器的出价，放在一路对照来最终选择最凌驾价的告白主的告白，然后把此次告白曝光的机会给到这个告白主，展示这个告白主的告白素材，这个就是一个对照简化的实时竞价告白的流程。
里面需要做的一个事情就是，在这个 ADX 和 DSP 办事器之间的交互是经由 OpenRTB 和谈来做的，这里面有两个问题需要解决：
第一个是流量非常大，ADX所有的告白恳求都邑发给 DSP 办事器，有些大的媒体或者有好几万个QPS，若是好几家的话加起来很轻松会跨越十万QPS。
还有一个问题就是 ADX要求所有的DSP 必需在 100 毫秒返回出价响应，这个100ms包罗收集上的时间，若是 100 毫秒之内我没有收到你响应的话，我就视为你抛却了这个出价。
当然实时竞价告白手艺方面有好多挑战，首要有这么几块的挑战。
第一个就是在数据方面，包罗标签挖掘、人群扩散、画像剖析，还有一些实时剖析、透视剖析来辅助刷选投放方针人群，这个是在数据方面的手艺挑战。
第二个就是算法，算法会包罗两个对照焦点的算法。第一个就是 pCTR，第二个就是pCVR，pCTR 就是点击率预估算法，pCVR是转化率预估算法，这个转化或者会包罗多个，有下载、..、付费、活跃等等都属于转化。这两个算法会用到如今对照热的一些机械进修的算法在里面。
第三个方面的挑战就是在系统层面的挑战，适才提到了 ADX 和 DSP 办事器，它之间会有对照高的QPS，此外就是时延有要求，100毫秒的要求。今天我分享的内容首要是着重于在第三块，就是在系统层面怎么和 OpenResty 进行连系。
这个是实时竞价告白系统在系统侧的一个架构简图，最上面是流量层，各ADX的告白恳求流量会发到下面的接入层。接入层又包罗两部门，一个是静态的 CDN，一个是动态的 RTB 网关，CDN 存放告白的素材，RTB 网关会做一件事情，就是进行 OpenRTB 和谈的编解码，此外还会做一些平安和流量掌握等把持。
在逻辑层包罗竞价引擎，最下面的就是数据层包罗 DMP 数据治理..。这两个部门做的事情就是我们方才说的，一路来确定这个告白恳求是不是我们需要的用户，若是是我们需要的用户的话，我们怎么样给它估算一个代价。
这里面标了橙..字体的，就是我们用 OpenResty 进行过重构或许说优化过的处所，包罗接入层的 RTB 网关，还有逻辑层竞价引擎，以及 DMP 的数据治理..的一部门。
我们就一个个来看一下我们怎么样做重构和优化的
首先在接入层，我们直接用 OpenResty 定制了 RTB 网关，为什么用 OpenResty 定制 RTB 网关呢？方才提到了，它的流量非常大，这个能够充裕施展 OpenResty 的nginx+lua协程高机能的特征。
此外还有一个问题就是分歧的媒体有分歧的 OpenRTB和谈，固然有尺度划定，然则它们照样会有一些不同的，对接起来照样非常地麻烦，所以对每家媒体都行使插件化体式做了不同化的处理，来提高斥地联调时候的效率。
接下来就是在平安方面的一个优化，这里的平安策略跟前面讲的平安策略或者不太一般。这里面首要是基于 OpenRTB和谈自己的平安策略，包罗Request id的各个阶段校验，还有参数的非对称加密做防盗链，泄露用户信息等，此外就是一些防作弊，我们把这些平安性方面的优化都放到这个 RTB 网关里面来做。
此外，RTB 网关还做了一个对照大的优化，就是把方针流量筛选也直接放到了 RTB 网关里面来了。之前传统的做法都是怎么做的呢？都是让流量进入到 DMP 数据..里面来，经由竞价引擎、告白检索、标签查询办事来到 DMP 数据治理..里面去确定这个用户是不是我们需要的。因为DMP数据治理..里面存放了所有效户的加密ID信息以及一些标签属性、偏好等等，之前都是如许来判断的。
其实我们能够简化一点，直接把这部门加密数据放到 RTB 网关里面来，当然也会碰到一个问题就是用户的加密标识信息非常大，也许会有十几亿条，此外一个设备标识加密后至少是32个字符串，若是悉数存放到内存里面的话也许要十几个G，当然这还不包罗查找索引额外的开销。
那我们就去寻找一个哈希算法，能够把一个固定长度的字符串直接转化为一个整型，然后我们把这个整型直接经由Bitmap直接映射到 512 兆的内存中的一个bit中去。如许就能够直接经由 512 兆的内存存放40亿的加密设备号，当然也会有分歧的加密设备号映射到沟通的比特位里面去了，但这个没有关系，我们照样持续走之前本来的路径，让它在最后背 DMP 里面再做一次判断。
经由这么一个简洁的优化之后，我们在第一时间里面能够过滤掉也许80%以上的流量，所以对整个系统的机能也是有非常大的提拔。
接下来就在逻辑层的优化，逻辑层首要是竞价引擎，竞价引擎会涉及到大量的内部办事的接见，好比标签查询、告白检索，还有点击率预估查询、频次掌握查询、计费搜检等等如许一些内部办事接见，同时会涉及到大量的调DB、调缓存、调redis等把持，我们好多的买卖其实都是如许的，大量的I/O把持，非常典型的 IO 密集型的办事，所以我们也是非常武断地用 OpenResty 把它完全重构了，之前都是采用对照传统、非常老旧的C++的多线程同步框架。当然如今内部也有好多C++协程的方案，我们照样选择用 OpenResty 直接把它重构了。
此外一个方面就是行使 OpenResty 新建一些新的协程，去把之前一些串行化的把持做并行处理，来降低时延，或者一两个并行化把持就能够降低竞价出价的时延10%摆布，也是非常可观的收获。
最后就是在数据层这一块，我们看看 OpenResty 是否有它的用武之地呢？
数据层DMP 有三个功能，第一个是数据的采集，第二个是数据的较量，第三个就是数据的应用。在最原始数据采集这一块，因为我们后背也会把 DMP 做得更大，为我们..系统做办事的，所以这里面涉及到大量的数据采集的工作，包罗告白曝光、社区行为、公家号行为、各类..运动行为等等，当然和之前一般，经由加密处理后进行收集。
那在数据应用这一块，我们有大量的标签查询、账号转化，还有内部数据合作、实时查询等等把持，这些把持其实都是非常，也能够直接用这个 OpenResty来做，所以我们用了非常少的办事器，很轻松的就能够处理数十亿如许的一些数据收集和查询把持。
那到这里，我的2个应用案例就分享完了，最后用四个数字来总结一下我讲的内容，以及想表达的优化思惟，3527（不是9527）：
“3”是什么意思？就是适才提到的我们系统架构里面的三层，接入层、逻辑层和数据层，这里面三层都能够考虑用 OpenResty 去做优化，人人都对照熟悉在OpenResty首要是在接入层 CDN 和 API用的最多，其实在逻辑层也能够考虑用 OpenResty 去测验做一些工作，稀奇是I/O密集型的逻辑层。而且我们OpenResty 升级了支撑TCP/UDP办事器的stream-module，若是能加倍不乱的话，我们也会去测验用这个 module直接做我们逻辑层的办事，最后就是在数据层也能够去看看有没有如许非常简洁的数据收集和查询把持，若是有的话，量也对照大的话也能够考虑用 OpenResty 来轻松实现。
“5”是什么意思呢？我们方才说做任何方案选型、考查、评估、深入的时候都能够从这五个方面去做。第一个是易用性，第二个是可用性，第三个是机能，第四个是平安性，第五个是可维护性。我们手艺同窗往往考虑得对照多是机能，可用性、平安性这三块，但其实在第一点和第五点，易用性和可维护性这一块需要我们花更多的时间考虑。稀奇是对于我们做买卖斥地的同窗来说，80%以上的时间或者都是这两个方面，若是我们易用性和可维护性做得好的话会帮我们节约大量的时间。
第三个数字就是“2”，“2”就是说我们在做机能优化的时候都要去问本身两个问题。第一个问题就是为什么要做这件事情。第二个问题就是可否能够不做，可否能够牺牲掉一些其他的资源，好比说内存资源来提高机能。可否就是牺牲一些实时性来提高机能，或许说我们牺牲产物的体验来提高机能等等，我们需要做机能优化的时候，能够更多地去往上层做一些如许的考虑和衡量。
“7”是我们在测试机能优化的时候有7个环节。里面每个环节都需要有本身注重的事情，而且能够去做一些概括和总结。
