最后一个，是luasocket，千万不能在nginx在处理请求的时候用。
简单介绍一下lua_resty_checkups这个模板，它有几个功能：
第一个是 动态upstream管理， 基于共享内存实现worker间同步;
然后是 被动健康检查， 这个是nginx自身的一个特性;
第三是 主动健康检查 ，这个模块会主动给你的后端发心跳包，可以定时，15秒发一次，你后端的服务是不是存活。我们还可以有一些个性化的检查，然后heratbeat定时给上游发送心跳包检测服务是否存活。
最后是 负载均衡算法， 本地优先可节约内网流量等等。
以Host区分服务：比如说这两个curl往同一个地址去发，这两者之间是不一样的。
这个图简单讲一下，它是一个请求的流程，可以分为三个部分，最上面是接收请求，我们会加载一个worker代码，在worker代码执行完之后，会根据这个host找对应的列表，然后把这个请求代理给服务端。
这个跟dyups的C模块一样，也是通过HTTP接口动态更新upstream列表，加完之后，可以在管理页面看一下，就可以看到刚刚加进去的两个服务，这里面有server地址，一些健康检查的消息，还有它的状态变更的时间，以及它失败的次数，这是主动健康检查的一个记录。那为什么会有主动健康检查呢?我稍微介绍一下，大家平时用的就是一些被动的健康检查，就是说我这个请求发出去之后失败了才知道失败了，主动的就是我发心跳包，在请求之前，我就可以知道你这个服务是不是出问题了。
动态lua加载，这个在做游戏的时候会经常用到，在一开始的时候，我们的程序里面跑了一些lua的代码，给后端的程序做参数转化和做兼容用，比如有一个小调整不乐意去改，就拿前面的路由去做，首先我可以对请求做改写，因为我可以拿到整个的请求的，它的请求体可以做任意的事情，这样的话，我可以跟一些权限控制结合起来，还有一个就是可以做一些简单的参数检查。据我们的统计，我们大概有至少10%是重复的请求，那这些重复请求如果都去做的话就是无谓的消耗，我们会返一个304，表示结果跟之前的一样，用之前的结果就好了。在返304的时候，如果说我们是需要后端的服务去判断，势必会把整个请求给收下来，然后再往后面发，相当于是内网带宽要增加一些，这样其实就已经节省了带宽，可以不往后面发了，主要是这几个原因。
这是一个动态负载加载的例子，我如果把这段代码推到Slardar里面的话，它会执行，如果你进行一个删除操作，它会返403，也就是说可以立即通过这个代码禁掉这个操作，那还有什么功能呢?你可以想象到的功能都可以做，而且这个过程是动态的，如果代码加载，也可以从状态页里看到它的信息。
刚刚讲的都是这个项目的特性，接下来想简单介绍一下实现过程，有一些可能比较深入，我尽量把一些深入的地方带过去，动态upstream管理，分三个部分，三个步骤。
1. 动态upstream管理
启动时从consul加载配置文件，如果你没有任何理由的挂了，挂了之后你刚起来时，你怎么知道你刚刚怎么了呢?所以得有一个地方去固化这些东西，而我们选的就是consul，所以它启动的时候必须从consul加载，启动之后一个就是监听管理的端口，还有一个就是要启动一个定时器，这个定时器做worker间同步的，定时从共享内存看一下有没有更新，有更新的话可以同步在自己的worker里头。
这是一个简单的流程图，最开始的时候从consul加载，在完成fork之后，就到了worker进程，也就是刚刚你初始化加载的那些每个worker都有了，另外一部分启动定时器，一旦有更新就会进入到这个里面。