2. 负载均衡
我们主要用到了balance_by_lua_，一个请求过来，通过upstream的C模块，然后把这个请求往这里发，下图这个配置文件，刚刚也有一个类似的，就是在这里写了地址。通过balance_by_lua_指令，我们会把它拦到这个文件里，就可以在这个lua文件里头用lua代码选一个，这就是自身的一个checkups的选择的过程。
大概的流程见下图，可以先看下边部分，一开始的时候，checkups.select_peer是我们的模块，然后根据这个host再到当前的peer，就跳出去了，这样就实现了用lua控制。上面部分是要知道它是成功还是失败的，如果它失败了，我要对这个状态进行反馈。
3. 动态lua加载
这个主要是用到lua的三个函数，分别是loadfile、loadstring和setfenv。loadfile是加载本地的lua代码，loadstring是从consul或HTTP请求body加载代码，setfenv设置代码的执行环境，通过这三个函数就可以加载，具体的实践细节我就不再介绍。
这是我们做的轮子，主要用到checkups的模块和balance_by_lua_，它有这些优势：
首先， 纯lua实现，不依赖第三方C模块， 二次开发非常高效，减少维护负担。
第二是 可以用nginx原生的proxy， 因为我们只在请求的选peer的那个阶段做，peer选完之后，发数据的那个阶段是直接走nginx自己的指令的，所以它可以用到nginx原生的proxy指令。
最后，它 适用于几乎任何的ngx_lua项目。
在微服务架构里，slardar能做什么?
我们目前也在把之前的一些服务改造成微服务模式。微服务其实就是源于一个比较大的服务，把它拆分成一些小的服务，它的扩容跟迁移也不一样，微服务的扩容可以只扩容其中一部分，如果需要比较多的一些功能，就扩得多一点，需要少的，就扩得少一点。
我们现在正在尝试的一个方案，这个方案背景是这样子，我们有做图的一些需求，做图这个功能有很多，比如说美化，各种需求，如果说要对这个做图的服务进行优化是非常困难的，因为它功能太多了，如果我们把它拆成微服务就不一样了，比如说这个虚线上面的是我们现在的服务，这个是微服务的一个网关，下面是一些小的服务。
比如说美化，它的运算比较复杂，耗CPU比较多，我们肯定选择一些CPU比较好的机器;用GPU来做缩略图，这个性能可能提高几十倍;最后是一个中规中矩的做图，那就普通的一些就够了。
还有一些比较偏门的，比如说梯度，可能只要保证下服务可以用就行了，通过这个微服务的路由，我们根据后面的区分把之前的一个服务，以及它的参数拆成三个小的服务，这样通过三个步骤可以完成一个做图的服务。
当然我们在尝试这个方案其实也有很多的问题，比如一个服务原来用一个程序就可以做了，现在变成了三个，势必内网的带宽要增加了，中间的图片要被导来导去，这个怎么办呢?我们现在想到的办法就是做一些本地优先的调度策略，就是说你做完之后，本地有一些水印的，那就优先用本地的。
套用大师的一句话：Talk is cheap，Show me the code。开源!
好的，谢谢大家!