gorouter调研
最近在公司调研docker集群方案，涉及到 router这一层，有两个可选方案，源于cloudfoundry的 gorouter & 源于dotcloud的 hipache , 因为对golang实现的gorouter比较有好感，就主要调研了下。
gorouter介绍
项目地址： https://github.com/cloudfoundry/gorouter/
Gorouter来源于CloudFoundry，后文简称为router。它是整个平台的流量入口，负责分发所有的http请求到对应的 instance。它在内存中维护了一张路由表，记录了域名与实例的对应关系，所谓的实例自动迁移，靠得就是这张路由表，某实例宕掉了，就从路由表中剔 除，新实例创建了，就加入路由表。
Gorouter依赖
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 } -
gorouter自带两个http终端：
/varz: 自身状态监控
/routes: 目前承载的proxy rules list
具体说明&config说明见官方说明： https://github.com/cloudfoundry/gorouter