特性：
高性能
无需安装其他依赖，通过 Go 语言编写的单一可执行文件
支持 Restful API 接口
多种后台支持：Docker, Swarm, Kubernetes, Marathon, Mesos, Consul, Etcd
后台监控, 可以监听后台变化进而自动化应用新的配置文件设置
配置文件热更新 。（无需重启）
正常结束 http 连接
后端断路器
轮询，rebalancer 负载均衡
Rest Metrics
支持最小化官方 docker 镜像
后台支持 SSL
前台支持 SSL（包括 SNI）
清爽的 AngularJS 前端页面
支持 Websocket
支持 HTTP/2
网络错误重试
支持 Let’s Encrypt (自动更新 HTTPS 证书)
高可用集群模式
3.OpenResty
OpenResty 是一个基于 Nginx 与 Lua 的高性能 Web 平台，其内部集成了大量精良的 Lua 库、第三方模块以及大多数的依赖项 。用于方便地搭建能够处理超高并发、扩展性极高的动态 Web 应用、Web 服务和动态网关 。
OpenResty 通过汇聚各种设计精良的 Nginx 模块（主要由 OpenResty 团队自主开发），从而将 Nginx 有效地变成一个强大的通用 Web 应用平台 。这样，Web 开发人员和系统工程师可以使用 Lua 脚本语言调动 Nginx 支持的各种 C 以及 Lua 模块，快速构造出足以胜任 10K 乃至 1000K 以上单机并发连接的高性能 Web 应用系统 。
OpenResty 的目标是让你的 Web 服务直接跑在 Nginx 服务内部，充分利用 Nginx 的非阻塞 I/O 模型，不仅仅对 HTTP 客户端请求, 甚至于对远程后端诸如 MySQL、PostgreSQL、Memcached 以及 redis 等都进行一致的高性能响应 。
4.Kong
Kong 是一个在 Nginx 中运行的 Lua 应用程序，并且可以通过 lua-nginx 模块实现，Kong 不是用这个模块编译 Nginx，而是与 OpenResty 一起发布，OpenResty 已经包含了 lua-nginx-module，OpenResty 不是 Nginx 的分支，而是一组扩展功能的模块 。
是一个 Api Gateway，通过插件的形式提供负载均衡，日志记录，身份验证，速率限制，转换等功能 。可以很轻松扩展功能，模块化，可以运行在任何基础设施上 。
它的核心是实现数据库抽象，路由和插件管理，插件可以存在于单独的代码库中，并且可以在几行代码中注入到请求生命周期的任何位置 。很方便地为路由和服务提供各种插件，网关所需要的基本特性，Kong 都如数支持：
云原生：与平台无关，Kong 可以从裸机运行到 Kubernetes 。
动态路由：Kong 的背后是 OpenResty+Lua，所以从 OpenResty 继承了动态路由的特性 。
熔断
健康检查
日志：可以记录通过 Kong 的 HTTP，TCP，UDP 请求和响应 。
鉴权：权限控制，IP 黑白名单，同样是 OpenResty 的特性 。
SSL: 可以为基础服务或 API 设置特定的 SSL 证书 。
监控：Kong 提供了实时监控插件 。
认证：如数支持 Hmac, JWT, Basic, OAuth2.0 等常用协议 。
限流
REST API：通过 Rest API 进行配置管理，从繁琐的配置文件中解放 。
可用性: 天然支持分布式 。
高性能: 背靠非阻塞通信的 nginx，性能自不用说 。
插件机制: 提供众多开箱即用的插件，且有易于扩展的自定义插件接口，用户可以使用 Lua 自行开发插件 。
上面这些特性中，反复提及了 Kong 背后的 OpenResty，实际上，使用 Kong 之后，Nginx 可以完全摒弃，因为 Kong 的功能是 Nginx 的父集 。
5. 对比、总结
文章插图
综上对比，从开源社区活跃度和学习成本来看，无疑是 Zuul 和 Traefik 较好；从成熟度来看，较好的是 Kong、Traefik；从性能角度来看，Kong 要比其他几个领先一些，从架构优势的扩展性来看，Kong 丰富的插件，而 Zuul 是完全需要自研各类 Filter，但 Zuul 由于与 Spring Cloud 深度集成，使用度也很高 。
六、服务注册与发现
服务注册与发现，是一个古老的话题，当应用开始脱离单机运行和访问时，服务注册与发现就诞生了 。目前的网络架构是每个主机都有一个独立的 IP 地址，那么服务发现基本上都是通过某种方式获取到服务所部署的 IP 地址 。DNS 协议是最早将一个网络名称翻译为网络 IP 的协议，在最初的架构选型中，DNS+LVS+Nginx 基本可以满足所有的 RESTful 服务的发现，此时服务的 IP 列表通常配置在 Nginx 或者 LVS 。后来出现了 RPC 服务，服务的上下线更加频繁，人们开始寻求一种能够支持动态上下线并且推送 IP 列表变化的注册中心框架或组件 。
现如今，各类服务注册与发现的框架、组件很多 (Zookeeper、Eureka、Consul、etcd 等)，在选择上更是眼花缭乱 。在服务注册与发现的技术选型上，我觉得我们应该还是有一定遵循原则和关注要点的 。通常可从以下几个方面出发，进行重点关注、抉择 。
推荐阅读
- 在Netty服务被N次攻击之后，终于抓到现行了
- 白茶属于轻微发酵茶类,白茶属于什么茶系
- 中国礼品网服务特色简介
- |不寄哀愁寄春情
- 微商运营技巧，改变思路，玩转营销，私域流量“井喷”而出
- 微信公众号渠道二维码怎么做，微信渠道二维码添加步骤
- 如何提高企业微信权重？提升企业微信活跃度的方法有哪些？
- 成本高、获客难，餐饮企业如何在微信生态中乘风破浪？
- 全球13台根服务器，中国没有任何一台，一旦断网中国网络会瘫痪吗
- 白茶属于哪个茶类,白茶属于轻微发酵茶类