背景
公司现在逐步用起 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 的微服务编排系统的反向代理/负载均衡工具。可惜不符合我的需要。。。
参考资料
领取专属 10元无门槛券
私享最新 技术干货