转载

gorouter调研

最近在公司调研docker集群方案，涉及到 router这一层，有两个可选方案，源于cloudfoundry的 gorouter & 源于dotcloud的 hipache , 因为对golang实现的gorouter比较有好感，就主要调研了下。

gorouter介绍

项目地址： https://github.com/cloudfoundry/gorouter/

Gorouter来源于CloudFoundry，后文简称为router。它是整个平台的流量入口，负责分发所有的http请求到对应的instance。它在内存中维护了一张路由表，记录了域名与实例的对应关系，所谓的实例自动迁移，靠得就是这张路由表，某实例宕掉了，就从路由表中剔除，新实例创建了，就加入路由表。

Gorouter依赖

Go

Gorouter使用golang编写，因此环境需要预先安装go编译环境

Golang Url： https://golang.org/dl/
Gnatsd

来源cloudfoundry，是一个开源轻量高性能的消息系统，gorouter依赖它来作为消息系统，进行PUB/SUB操作。

官方地址： http://nats.io/

项目地址： https://github.com/apcera/gnatsd

Gorouter架构中所处的位置

无论是在cloudfoundry还是在我们设计的容器体系中，都是作为流量入口存在。

在CloudFoundry架构中的位置：
在设计的容器方案中的位置：

Gorouter性能

需要了解两个组件的性能，一个是gorouter本身，另一个是他依赖的Gnatsd，总体感觉性能不错。

Gorouter，官网没有它的proxy性能数据，只是说它的逻辑简单，性能很好，后期可以专门对它的转发性能做一下测试。

Gnatsd：性能数据来自其官方：

With gnatsd (Golang-based server), NATS can send up to 6 MILLION MESSAGES PER SECOND.

Here's a detailed Performance Comparison between NATS, Redis, NSQ, RabbitMQ, and more. The below chart compares throughput for 4k payloads:

Gorouter部署

一个比较典型的gorouter部署架构为：

其中，需要关注的是RouteFlush这一块，他的作用是将需要进行proxy的uri rule publish给gnatsd，从而使gorouter可以从gnatsd处sub到&生效，同时，以一定的频率对现有rule进行publish 刷新，因为gorouter只对rule保留时间T（在config中配置，默认120s）。

Routeflush需要自行实现。

Gorouter使用

Goroute监听router.register、router.unregister等几个频道。

Publish router.register&router.unregister的数据体格式为：

{ "host": "127.0.0.1", //后端映射的host "port": 4567, //后端映射的port "uris": [ "my_first_url.vcap.me", //对应的域名1 "my_second_url.vcap.me" //对应的域名2 ], "tags": { "another_key": "another_value", "some_key": "some_value" }, "app": "some_app_guid",//app id "private_instance_id": "some_app_instance_id" // instance id }