Traefik
Træfɪk 是一个为了让部署微服务更加便捷而诞生的现代HTTP反向代理、负载均衡工具。它支持多种后台 (Docker, Swarm, Kubernetes, Marathon, Mesos, Consul, Etcd, Zookeeper, BoltDB, Rest API, file…) 来自动化、动态的应用它的配置文件设置。
重要特性：
- 它非常快，无需安装其他依赖，通过Go语言编写的单一可执行文件；
- 多种后台支持：Docker, Swarm, Kubernetes, Marathon, Mesos, Consul, Etcd；
- 支持支持Rest API、Websocket、HTTP/2、Docker镜像；
- 监听后台变化进而自动化应用新的配置文件设置；
- 配置文件热更新，无需重启进程；
- 后端断路器、负载均衡、容错机制；
- 清爽的前端页面，可监控服务指标。
关于Traefik的更多内容，可以查看官网：https://traefik.cn/
API网关对比
上面是网关对比截图，偷个懒，大家主要关注Kong、Traefik和Zuul即可：
- 从开源社区活跃度 来看，无疑是Kong和Traefik较好；
- 从成熟度 来看，较好的是Kong、Tyk、Traefik；
- 从性能 来看，Kong要比其他几个领先一些；
- 从架构优势 的扩展性来看，Kong、Tyk有丰富的插件，Ambassador也有插件但不多，而Zuul是完全需要自研，但Zuul由于与Spring Cloud深度集成，使用度也很高，近年来Istio服务网格的流行，Ambassador因为能够和Istio无缝集成也是相当大的优势。
下面是其它网友的思考结论，可供参考：
- 性能： Nginx+Lua形式必然是高于Java语言实现的网关的，Java技术栈里面Zuul1.0是基于Servlet实现的，剩下都是基于webflux实现，性能是高于基于Servlet实现的。在性能方面我觉得选择网关可能不算那么重要，多加几台机器就可以搞定。
- 可维护性和扩展性： Nginx+Lua这个组合掌握的人不算多，如果团队有大神，大佬们就随意了，当没看到这段话，对于一般团队来说的话，选择自己团队擅长的语言更重要。Java技术栈下的3种网关，对于Zuul和Spring Cloud Getway需要或多或少要搞一些集成和配置页面来维护，但是对于Soul我就无脑看看文章，需要哪个搬哪个好了，尤其是可以无脑对接Dubbo美滋滋，此外Soul2.0以后版本可以摆脱ZK，在我心里再无诟病，我就喜欢无脑操作。
- 高可用： 对于网关高可用基本都是统一的策略都是采用多机器部署的方式，前面挂一个负载，对于而外需要用的一些组件大家注意一下。
基于Traefik自研的微服务网关
技术栈选型
- Traefik： 一款开源的反向代理与负载均衡工具，它最大的优点是能够与常见的微服务系统直接整合，可以实现自动化动态配置。traefik较为轻量，非常易于使用和设置，性能比较好，已在全球范围内用于生产环境。
- Etcd： 一个Go言编写的分布式、高可用的一致性键值存储系统，用于提供可靠的分布式键值存储、配置共享和服务发现等功能。
- Go： 并发能力强，性能媲美C，处理能力是PHP的4倍，效率高，语法简单，易上手，开发效率接近PHP。
网关框架
整个网关框架分为3块：
- 网关后台（hal-fe和hal-admin）： 用于应用、服务和插件的配置，然后将配置信息发布到ETCD；
- Traefik： 读取ETCD配置，根据配置信息对请求进行路由分发，如果需要鉴权，会直接通过hal-agent模块进行统一鉴权。鉴权完毕后，如果是Http请求，直接打到下游服务，如果是Grpc和Thrift协议，会通过hal-proxy模块进行协议转换。
- 协议转换模块： 读取ETCD配置，对Traefik分发过来的请求，进行Grpc和Thrift协议转换，并通过服务发现机制，获取服务下游机器，并通过负载均衡，将转换后的数据打到下游服务机器。
网关后台
主要由3大模块组成：
- 应用： 主要包括应用名、域名、路径前缀、所属组、状态等，比如印度海外商城、印度社区；
- 服务： 主要包括服务名、注册方式、协议类型、所属组、状态等，比如评论服务、地址服务、搜索服务。
- 插件： 主要包括插件名称、插件类型、插件属性配置等，比如路径前缀替换插件、鉴权插件。
一个应用只能绑定一个服务，但是可以绑定多个插件。 通过后台完成网关配置后，将这些配置信息生成Config文件，发布到ETCD中，Config文件需要遵循严格的数据格式，比如Traefix配置需要遵循官方的文件配置格式，才能被Traefik识别。
协议转换模块
hal-proxy模块是整个微服务网关最复杂，也是技术含量最高的模块，所以给大家详细讲解一下。
问题引入
在讲这个模块前，我们先看下面几个问题：
- 当请求从上游的trafik过来时，需要知道访问下游的机器IP和端口，才能将请求发送给下游，这些机器如何获取呢？
- 有了机器后，我们需要和下游机器建立连接，如果连接用一次就直接释放，肯定对服务会造成很大的压力，这就需要引入Client缓存池，那这个Client缓存池我们又该如何实现呢？
- 最后就是需要对协议进行转换，因为不同的下游服务，支持的协议类型是不一样的，这个网关又是如何动态支持的呢？
实现原理
我们还是先看一下hal-proxy内部有哪些模块，首先是Resolver模块，这个模块的是什么作用呢？这里我简单介绍一下，目前公司内部通过服务获取到机器列表的方式有多种，比如MIS平台、服务树等，也就是有的是通过平台配置的，有的是直接挂在服务树下，无论哪种方式，我们都通过服务名，通过一定的方式，找到该服务下面所有的主机。
所以Resolver模块的作用，其实就是通过服务名，找到该服务下的所有机器的IP和服务端口，然后持久化到内存中，并定时更新。
协议模块就是支持不同的协议转换，每个协议类型的转换，都需要单独实现，这些协议转换，无非就是先通过机器IP和端口初始化Client，然后再将数据进行转换后，直接发送到下游的机器。
最后就是连接池，之前我们其实也用到go自带的pool来做，但是当对pool数据进行更新时，需要加锁，所以性能一直起不来，后来改成了环形队列，然后对数据的操作全部通过原子操作方式，就实现了无锁操作，大大提高的并发性能 。
实现逻辑
这个是hal-proxy的逻辑实现图，画了2天，包含所有核心对象的交互方式，这里就不去细讲，能掌握多少，靠大家自己领悟，如果有任何疑问(或者看不清图片)，可以关注我公众号，加我微信沟通。
尽信书则不如无书，因个人能力有限，难免有疏漏和错误之处，如发现bug或者有更好的建议，欢迎批评指正，不吝感激。
