以OpenResty搭建RTB竞价引擎接入层

Posted 2021-04-24 程序猿人

概念解析

OpenResty： OpenResty是一个基于nginx与 Lua 的高性能 Web 平台，其内部集成了大量精良的 Lua 库、第三方模块以及大多数的依赖项。用于方便地搭建能够处理超高并发、扩展性极高的动态 Web 应用、Web 服务和动态网关，以下或也称之为Nginx。

RTB竞价引擎： 互联网广告实时竞价系统，以下的tomcat为其单实例。   当我们的应用单实例不能支撑用户请求的时候，此时就需要扩容，一般称之“横向扩容”，即：从一台服务器扩容到两台、几十台不等。如下是我们的架构方式：

其中红框中的nginx群，我们称之为“接入层”。在广告引擎系统中，常常需要做一些A-B测试用于对一些投放策略的比较、新增或者更改的功能同样需要拿到线上做bug风险测试，而所有这些都需要以重启服务器来实现。投放系统流量大且实时性要求高，重启系统导致系统的波动不说，还会影响整个广告系统的收入，这就成了我们的痛点。

发现痛点，就解决它！如此，我们便有了以上的架构。对于开发同学来说，只需要关心到接入层就够了，Haproxy由运维同学维护。在接入层，我们搭建流量分发功能，以下称之为“灰度发布”。灰度发布，通过lua脚本实现了特定的流量发送到特定的Tomcat服务。这还不够，服务的启停，需要实时动态的流量切换，这就需要一个服务发现系统。而我们选择在接入层搭建这些功能，解决这个问题，无非是考虑到与业务逻辑解耦，同时看中了OpenResty的高并发、高吞吐以及丰富的模块设计。

如下，分两个部分介绍一下我们的实现方式：

服务发现

我们的服务发现功能是基于OpenResty+upsync+consul功能搭建，辅以nginx_upstream_check_module做健康检查。    upsync是由微博开源的一款nginx插件，可以从consul或其他服务发现框架同步上游服务器，动态修改后端服务器属性（weight，max_fails等），而无需重新加载nginx。对于大流量、高负载的RTB引擎来说，nginx reload会进一步增加系统负载并暂时降低性能。而且增加upsync模块，将我们的服务于调用者来说完全解耦，后端系统的升级重启，乃至限流扩容都透明化了。

upstream online { server 0.0.0.1:1234;  upsync 127.0.0.1:80/v1/kv/upstreams/springboottest upsync_timeout=6m upsync_interval=500ms upsync_type=consul strong_dependency=off; upsync_dump_path /usr/local/nginx/nginx/conf/servers/spring-boot-consul.conf; upsync_lb hash_ketama; hash $arg_uid consistent; check interval=1000 rise=2 fall=2 timeout=3000 type=http default_down=false; check_http_send "HEAD / HTTP/1.0\r\n\r\n"; check_http_expect_alive http_2xx http_3xx;}

其中代码行：

第2：为假数据，预防启动时nginx报错；第3：为拉取consul数据地址，此处使用kv形式； upsync_timeout ：拉取超时时间，不可小于5m； upsync_interval ：拉取时间间隔； upsync_type ：拉取形式，此处使用consul； strong_dependency：打开时，每次nginx启动或重新加载时，nginx都会从consul中提取服务器，此处关闭；第4: 为服务器列表落地本地地址；第5：结合第6行，设置一致性hash；第7：设置healthy check的检测方式：`syntax: *check interval=milliseconds [fall=count] [rise=count][timeout=milliseconds] [default_down=true|false] [type=tcp|http|ssl_hello|mysql|ajp|fastcgi]*` interval ：检测间隔，单位milliseconds； rise ：检查成功rise次后，服务器被标记为启动； fall ：检查失败fall次后，服务器被标记为关闭； timeout ：健康检测超时时间 type ：健康检测类型 default_down：设置后端服务器的初始状态，默认为关闭。

如配置所示，nginx会定时从consul拉取上游服务器列表，同时落地在本地（防止consul集群不可用）。由于相对传统的取模操作一致性hash对后端服务的缓存友好且拥有更好的容错性与可扩展性，所以我们这里使用了一致性hash。upsync对每个上游服务器增加了160*weight个虚拟节点，使其负载均衡。

对于consul而言，我们只选用了它的kv功能，更看重的是，consul提供了time_wait和修改版本号概念，如果consul发现该kv没有变化就会hang住这个请求5分钟，在这５分钟内如果有任何变化都会及时返回结果。通过比较版本号我们就知道是超时了还是kv的确被修改了。由此OpenResty可以及时地获取consul的kv store变化。而consul不支持多路注册，使用它的service功能的话，很可能导致注册结果不可控，这一直以来是consul为开发者所诟病的大坑。而且注册对于后端服务来说，它和其所注册的server是一一对应的，一旦consul某个server挂掉，后端服务也被认为不存在了，这是我说不能容忍的。所以取用其长，而避用其短，搭配nginx的nginx_upstream_check_module所提供的丰富的api和健康检查方式实现服务发现功能。

灰度发布

百度词条对灰度发布的定义是：又名金丝雀发布，是指在黑与白之间，能够平滑过渡的一种发布方式。我们的灰度发布功能则是在服务发现的基础之上，增加流量分发层，使进入接入层的流量可以根据我们的业务需求，如userId、广告位、Ip、Ip段、操作系统等制定相应的规则，指定到相应的上游服务器中，便于我们测试一些新进功能或者策略的优劣。流程图如下。

我们的规则是通过json的方式存储于redis中，但是json的方式是非常浪费性能的，所以我们均采用unix domain socket的方式连接本地redis从库，OpenResty的lua-resty-redis对此支持非常好；其次在其上层使用lua_shared_dict搭建缓存，把相关的分发加入缓存中，从而降低redis的压力。另外，采用加权平均的方式，可以将指定流量的一部分分发到指定的一台或者多台机器上去。  

这是我前两年发布在知乎上的文章，拿过来一起整理下。请多多批评

扫描二维码

获取更多精彩

程序猿人