gorouter调研

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

gorouter介绍

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

Gorouter依赖

1. Go
   Gorouter使用golang编写，因此环境需要预先安装go编译环境
   Golang Url： https://golang.org/dl/

2. 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
} 

• gorouter自带两个http终端：
  /varz: 自身状态监控
  /routes: 目前承载的proxy rules list
  具体说明&config说明见官方说明： https://github.com/cloudfoundry/gorouter