五种微服务网关，该选哪个？( 三 ) _微服务

文章插图
Kong网关具有以下的特性：

可扩展性: 通过简单地添加更多的服务器，可以轻松地进行横向扩展，这意味着您的平台可以在一个较低负载的情况下处理任何请求；
模块化: 可以通过添加新的插件进行扩展，这些插件可以通过RESTful Admin API轻松配置；
在任何基础架构上运行: Kong网关可以在任何地方都能运行。您可以在云或内部网络环境中部署Kong，包括单个或多个数据中心设置，以及public，private 或invite-only APIs 。

TraefikTræ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/

2.2 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，在我心里再无诟病，我就喜欢无脑操作。
高可用：对于网关高可用基本都是统一的策略都是采用多机器部署的方式，前面挂一个负载，对于而外需要用的一些组件大家注意一下。

3 基于Traefik自研的微服务网关这个是我司自研的微服务网关，基于Traefik进行开发，下面从技术选型、网关框架、网关后台、协议转换进行讲解，绝对干货！
3.1 技术栈选型