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