Nginx动态路由的新姿式：使用Go取代lua

导语： 在Nitro 中， 咱们须要一款专业的负载均衡器。 通过一番研究以后，Mihai Todor和我使用Go构建了基于Nginx、Redis 协议的路由器解决方案，其中nginx负责全部繁重工做，路由器自己并不承载流量。 这个解决方案过去一年在生产环境中运行顺畅。 如下是咱们所作的工做以及咱们为何那样作。 

 

 

为何

 

咱们正在构建的新服务将位于负载均衡池以后，负责执行代价很高的计算任务，正因如此，咱们须要作本地缓存。 为了缓存优化， 咱们想尝试将相同资源的请求发送到同一主机上（若是这台主机是可用的)。

    

解决这个问题有不少现有方案，如下是一个不彻底的清单列表：

• 利用cookie维护黏性session

• 利用Header 

• 基于源IP的黏性 

• HTTP重定向到正确实例

 

这个服务在每一个页面加载时将会被触发屡次， 所以出于性能的考虑， HTTP重定向方式并不可行。 若是全部的入站请求都经过一样的负载均衡器，那么剩下的几种解决方案均可以正常工做。 另外一方面， 若是你的前端是一个负载均衡器池， 你须要可以在它们之间共享状态或实现复杂的路由逻辑。 咱们对当前须要在负载均衡器之间共享状态变动的设计并无兴趣，所以咱们为这个服务选择了更复杂的路由逻辑。 

 

咱们的架构

 

了解一下咱们的设计架构也许可以帮你更好的理解咱们的意图。 

 

咱们拥有一组前端负载均衡器，这些服务的实例被部署在Mesos, 以便根据服务规模和资源可用性进行进出控制。 将主机和端口号列表放入负载均衡器中不是问题，这已经成为咱们平台的核心。 

 

由于一切都在Mesos上运行， 而且咱们拥一种简单的方式定义和部署服务，因此添加任何新服务都很简单。 

 

在Mesos之上， 咱们在每处都运行着基于gossip的Sidecar来管理服务发现。 咱们的前端负载均衡器是由Lyft的Envoy组成 , 它背后由Sidecar的Envoy集成支持。 这能知足大部分服务的需求。 Envoy主机运行在专用实例上， 但全部的服务都根据须要， 在主机之间迁移，由Mesos和Sigualarity调度器执行。 

 

仍在考虑中的Mesos服务节点将拥有基于磁盘的本地缓存。 

 

设计

 

看着这个问题咱们下了决定，咱们着实想要一种一致性哈稀环。 咱们可让节点根据须要控制进出，只有那些节点所服务的请求才会被从新路由。 剩下的全部节点将继续服务于任何公开的会话。 咱们能够很简单地经过Sidecar数据来支持一致性哈稀环 (你能够用Mesos 或k8s代替) 。 Sidecar健康检查节点， 咱们能够靠这些健康检查节点判断它们在Sidecar中是否工做正常。

 

而后，咱们须要某种一致性哈稀方法将流量导入到正确的节点中。它须要接收每个请求， 识别问题资源， 而后将请求传递给其余已经准备处理该资源的服务实例。 

 

固然， 资源识别能够简单的经过URL处理，而且任何负载均衡器可以将他们分开来处理简单的路由。 因此咱们只须要将他们与一致性哈稀关联起来，对此咱们已经有一种解决方案。 

 

你能够在nginx用lua那样作， 也可在HAproxy中用lua 。 在Nitro里， 咱们没有一我的是Lua 专家，而且显然没有库可以实现咱们的须要。 理想状况下， 路由逻辑将在Go中实现， Go在咱们的技术栈中是一门关键语言而且获得了很好的支持。 

 

Nginx有着丰富的生态环境， 跳脱常规的思路还引起了一些颇有趣的nginx插件。 这些插件中首选插件Valery Kholodko的nginx-eval-module。 这个插件容许你从nginx到一个端点生成一个调用，而且将返回的结果评估为nginx的变量。 在其余可能的做用中， 这个插件的意义在于它容许您动态地决定哪一个端点应该接收代理传递。 这就是咱们想要作的。 你从Ngnix到某个地方生成一个调用， 获取一个结果后， 你能够根据返回的结果值生成路由决策。 你可使用HTTP服务实现该请求的接收方。 该服务仅返回目标服务器端点的主机名和端口号的字符串。 这个服务始终保持一致性哈希，而且告知Nginx 每一个请求流量路由的位置 ， 可是生成一个单独的HTTP请求，仍然有些笨重。 整个预期的回复内容将会是字符串10.10.10.5:23453。 经过HTTP，咱们会在两个方向传递头部信息，这将大大超出响应正文的大小。 

 

因而我开始研究Nginx支持的其余协议， 发现memcache协议和redis协议它都支持。其中，对Go服务最友好的支持是Redis协议。因此那就是咱们改进的方向。Nginx 中有两个Redis模块，有一个适合经过nginx-eval-module 使用。 实现Redis Go语言最好的库是Redeo。Rodeo实现了一个极其简单的处理机制，很是相似于go标准库中的http包。 任何redis协议命令将会包含一个handler函数，而且它的写法很是简单。 相比Nginx插件，它可以处理更新版本的redis协议。 因而， 我摒弃了个人C技能，并补充了Nginx插件以使用最新的Redis协议编码。

 

因而， 咱们最新的解决方案是： 

 

这个调用从公网进入， 触发一个Envoy 节点， 而后到一个Nginx节点.Nginx 节点(1) 询问路由器将请求送至何处。 而后Nginx节点（2）将请求送至指定的服务端点。

 

实现

 

咱们在Go中创建了一个库来管理由Sidecar或Hashicorp的Memberlist库支持的一致性哈希。咱们称之为Ringman库。而后，咱们将该库强制接入Redeo库支持的Redis协议请求的服务中。

 

这种方案只须要两个Redis命令：GET和SELECT。咱们选择实现一些用于调试的的命令，其中包括INFO，能够用您想要的任何服务器状态进行回复。在两个必需的命令中，咱们能够放心地忽略SELECT，这是用因为选择Redis DB以用于任何后续调用。咱们只接受它，什么也不作。GET让全部的工做都很容易实现。如下是经过Redis和Redeo为Ringman端点提供服务的完整功能。 Nginx会传递它接收到的URL，而后从哈希环中返回端点。

 

 

这是Nginx使用如下配置调用：

 

咱们调用Nginx和容器里的路由，让他们在一样的host上运行，这样咱们就能够在其中实现较低成本的调用。

 

如下是咱们创建的Nginx:

 

性能

 

咱们在自有环境中进行了细致的性能测试， 咱们看到，经过Redis协议从Nginx到Go路由器的平均响应时间大约为0.2-0.3ms。因为来自上游服务的响应时间的中值大约为70毫秒，因此这是能够忽略的延迟。

一个更复杂的Nginx配置大概可以作更复杂的错误处理。服务运行了一年多可靠性很是好，性能一直很稳定。

 

结束语

 

若是您有相似需求，则能够复用大部分组件。只需按照上面的连接到实际的源代码。若是您有兴趣直接向Ringman添加对K8或Mesos的支持，咱们会很是欢迎。

 

这个解决方案听起来有点黑客，不过它最终成为咱们基础设施的重要补充。但愿它能帮助别人解决相似的问题。

 

转自：https://mp.weixin.qq.com/s/q03tiPdMxU6t-p6KlitANw