首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

devops treafik 试用记录

背景

公司现在逐步用起 mock 了,但目前用的 mock 技术都是整个服务端 mock 掉,而业务中经常遇到的是少数几个接口需要用 mock 绕过/模拟异常,并非全部都 mock 。因此需要有一个类似 anyproxy 可以通过路由控制,做到只有部分接口 mock 的工具。

至于为何不直接选用 anyproxy ,主要原因是它的工作方式是代理,而服务端间的通讯,大部分情况下是没有代理这个配置项的(开发代码里就没有这种设计)。同时 anyproxy 的规则配置是以文件形式配置在运行主机上,调整起来不如 web 平台方便。

为了方便大家查看,先说下结论:treafik 是一个很不错的反向代理工具,可惜做不到接口级别的路由控制,也没有可以直接改路由规则的 web 界面。

第一步,了解这个框架是干什么的

Træfɪk 是一个为了让部署微服务更加便捷而诞生的现代HTTP反向代理、负载均衡工具。 它支持多种后台 (Docker, Swarm, Kubernetes, Marathon, Mesos, Consul, Etcd, Zookeeper, BoltDB, Rest API, file…) 来自动化、动态的应用它的配置文件设置。

关键词:

反向代理

负载均衡

代理:

很久以前,老王去饭店吃饭,需要先到饭店,七荤八素点好菜,坐等饭菜上桌,然后大快朵颐,不亦乐乎。

有了第三方订餐外卖平台(代理),老王懒得动身前往饭店,老王打个电话或用APP,先选好某个饭店,再点好菜,外卖小哥会送上门来。

反向代理及负载均衡:

由于某个品牌的饭店口碑特别好,食客络绎不绝涌入,第三方订餐电话也不绝于耳,但是限于饭店接待能力有限,无法提供及时服务,很多食客等得不耐烦了,纷纷铩羽而归,饭店老总看着煮熟的鸭子飞走了,心疼不已。

痛定思痛,老总又成立了几个连锁饭店,形成一个集群,对外提供统一标准的菜品服务,电话订餐电话400-xxx-7777,当食客涌入饭店总台(负载均衡),总台将食客用大巴运到各个连锁店,这样食客既不需要排队,各连锁店都能高速运转起来,一举两得,老总乐开了花,并为此种运作模式起名为“反向代理”(Reverse Proxy)。

第二步,明确该框架能做什么

先看下框架特性:

它非常快

无需安装其他依赖,通过Go语言编写的单一可执行文件

支持 Rest API

多种后台支持:Docker, Swarm, Kubernetes, Marathon, Mesos, Consul, Etcd, 并且还会更多

后台监控, 可以监听后台变化进而自动化应用新的配置文件设置

配置文件热更新。无需重启进程

正常结束http连接

后端断路器

轮询,rebalancer 负载均衡

Rest Metrics

支持最小化 官方 docker 镜像

后台支持SSL

前台支持SSL(包括SNI)

清爽的AngularJS前端页面

支持Websocket

支持HTTP/2

网络错误重试

支持Let’s Encrypt (自动更新HTTPS证书)

高可用集群模式

提炼过后,在功能方面的特性有:

多种后台支持:Docker, Swarm, Kubernetes, Marathon, Mesos, Consul, Etcd, 并且还会更多

后台监控, 可以监听后台变化进而自动化应用新的配置文件设置

配置文件热更新。无需重启进程

轮询,rebalancer 负载均衡

支持 SSL、HTTP/2

支持网络错误重试

第三步,了解该框架的应用场景

这里主要通过搜索资料,查看应用场景。

百度此框架名称,首屏结果如下:

可以看到,主要的应用场景都是和 docker/kubernetes 结合,作为前端负载均衡器使用。且相比传统的 nginx ,它的优势在于可以自动感知后端变化,自动更新配置。

选择了一篇比较典型的文章,说明一下它的典型使用场景:初试 Kubernetes 集群中使用 Traefik 反向代理 。从文章中可以看出,其应用场景为作为反向代理,能自主快速地检测到 kubernetes 上服务的变化,从而快速地实现服务发现。

举个例子,平时 docker 部署的服务,对外暴露端口等都是手动设置,手动通知。每增加一个就得重复做一次这个步骤。用了 traefik 后,可以有一个类似于 spring cloud 中注册中心的 dashboard ,实时显示各个服务,并提供对外暴露的服务地址(默认为容器名称+traefik 使用的 url ):

第四步,清楚框架被发明的原因

我们都知道,nginx、apache 等 web 服务都能提供类似的反向代理、负载均衡功能,为何还需要 traefik 呢?

回头看下我们通过 nginx 配合 docker 启动 stf 的文章:STF 开发环境搭建与制作 docker 镜像过程,其中 nginx 部分摘抄如下:

可以看出,nginx 中,对应每个容器需要写数行配置项进行配置,方可进行反向代理。如果服务比较多,或者变化比较频繁,配置文件的维护成本也是非常高的。

而 traefik 能自动检测这方面的配置,生成对应的入口,且有任何变化均自动检测并更新,节省了很多配置文件的维护成本。同时图形化查看界面也便于大家了解这台服务器拥有的各项服务。

第五步,实战使用该框架,并反复总结

到了这里,其实已经确定这个框架和我原始需求贴合度不高,缺少了定制接口级别实际服务地址的能力。所以就简单用官方文档上的例子进行实战。

将这个 docker-compose.yml 文件放在名称叫做 traefik的目录下:

在名称叫做 traefik 的目录下运行:

现在, 创建一个名称为test 的目录,并在目录中使用以下内容创建一个 docker-compose.yml 文件:

然后, 在 test 目录下按顺序执行以下命令:

最后, 测试 test_whoami_1 和 test_whoami_2这两个服务之间的负载均衡:

同时通过查看 traefik 界面查看目前路由情况:

可以看到,另一个 docker 容器启动后,traefik 已经自动加上了反向代理和负载均衡。

总结

traefik 是一个不错的针对基于 docker 的微服务编排系统的反向代理/负载均衡工具。可惜不符合我的需要。。。

参考资料

  • 发表于:
  • 原文链接http://kuaibao.qq.com/s/20180111G02LZT00?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券