API网关选型：基于Traefik的微服务网关
常用API网关的比较与选择，以及我们自主研发的微服务网关的讲解，实用性十足！
前言
微服务近几年非常流行，围绕微服务出现了很多技术生态，比如微服务网关、Docker、Kubernetes等等。
2019年开始接触微服务网关，当时是跟公司同事一起开发的，由于技术能力有限，只负责网关后端，没有参与微服务网关后续的迭代，不过后来抽空看了看微服务网关前端的代码，对这个微服务网关的实现原理还是有一定了解的。
最近在写一篇技术栈的文章，正好写到微服务网关，所以就简单总结了一下之前学习到的知识，也整理了一下市面上常用的微服务网关。一方面方便后续的技术选型，另一方面也算是给自己一个交代。以下是文章目录：
基于Spring Boot+MyBatis Plus+Vue&Element实现的后端管理系统+用户小程序，支持RBAC动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能。
项目地址：
API 网关基础知识 什么是 API 网关
API网关是一个服务器，是系统的唯一入口点。从面向对象设计的角度看，它类似于门面模式。
API网关封装了系统的内部架构，为每个客户端提供定制化的API，还可能承担其他职责，比如鉴权、监控、负载均衡、缓存、协议转换、限流断路、静态响应处理等。
API 网关方式的关键点在于所有客户端和消费者都通过统一的网关访问微服务，所有非业务功能都在网关层处理。通常网关还提供 REST/HTTP 访问 API。
网关的主要功能
微服务网关作为微服务后端服务的统一入口，可以协调后端服务的管理，主要分为数据平面和控制平面：
本项目基于微服务的思想，构建在B2C电商场景，核心技术栈为Spring Boot + Dubbo，未来将重构为Spring Cloud Alibaba。
项目地址：
API网关选型 常见API网关
我们先来简单了解一下目前市面上常用的API网关：
Nginx
Nginx是一款高性能的HTTP及反向代理服务器，Nginx一方面可以作为反向代理，另一方面可以作为静态资源服务器，接口采用Lua动态语言完成灵活的定制功能。
Nginx 启动后会有一个 Master 进程和多个 Worker 进程，Master 进程和 Worker 进程通过进程间通信进行交互，如图所示。Worker 进程的阻塞点在 select()、epoll_wait() 等 I/O 多路复用函数调用处，等待数据读写事件发生。Nginx 采用异步非阻塞的方式处理请求，也就是说 Nginx 可以同时处理成千上万个请求。
祖尔
Zuul 是 Netflix 开源的 API 网关组件，可与 Eureka、Ribbon、Hystrix 等组件配合使用，拥有活跃的社区，并融入完整的 SpringCloud 生态，是构建微服务体系前端网关服务的最佳选择之一。
Zuul的核心是一系列的过滤器，可以实现以下功能：
Zuul目前有两个主要版本：Zuul1和Zuul2
Zuul1是基于Servlet框架构建的，如图所示，采用阻塞、多线程的方式，即一个线程处理一个连接请求。这种方式在内部延时严重、设备故障较多的情况下，会导致存活连接数和线程数增加。
Netflix 发布的 Zuul2 有重大更新，它运行在异步非阻塞框架上，每个 CPU 核心一个线程来处理所有请求和响应，请求和响应的生命周期通过事件和回调来处理，从而减少了线程数，因此开销更小。
Spring Cloud GetWay
Spring Cloud Gateway是Spring Cloud新的API网关项目，其目的是替代Zuul1，基于Spring5.0+SpringBoot2.0+WebFlux等技术开发（基于高性能Reactor模式响应式通信框架Netty，异步非阻塞模型），性能比Zuul更高，据官方测试Spring Cloud GateWay是Zuul的1.6倍，旨在为微服务架构提供一种简单、有效、统一的API路由管理方法。
Spring Cloud Gateway可以与Spring Cloud Discovery Client（如Eureka）、Ribbon、Hystrix等组件配合使用，实现路由转发、负载均衡、断路、认证、路径重写、日志监控等功能。Gateway还内置了限流过滤器，实现限流功能。
香港
Kong 是一个基于 OpenResty（Nginx + Lua 模块）编写、由 Mashape 开源的高可用、可扩展的 API 网关项目。Kong 构建于 NGINX 和 Apache Cassandra 或 PostgreSQL 之上，能够提供易于使用的 RESTful API 来操作和配置 API 管理系统，因此能够水平扩展多台 Kong 服务器，并通过前端的负载均衡配置将请求均匀分布到每台服务器上，以处理海量网络请求。
Kong 有三个主要组成部分：
Kong 采用插件机制进行功能定制，在 API 请求响应周期的生命周期内执行一组插件（可以是 0 个或 N 个）。插件采用 Lua 编写，目前有几个基本功能：HTTP 基本认证、密钥认证、CORS（跨源资源共享）、TCP、UDP、文件日志记录、API 请求限流、请求转发、Nginx 监控。
Kong网关具有以下特点：
特拉菲克
Træfɪk 是一款现代 HTTP 反向代理和负载平衡工具，旨在简化微服务的部署。它支持多个后端（Docker、Swarm、Kubernetes、Marathon、Mesos、Consul、Etcd、Zookeeper、BoltDB、Rest API、文件……）以自动动态地应用其配置文件设置。
主要特征：
关于Traefik的更多信息请访问官网：
API 网关比较
以上是网关对比的截图，为了偷懒，可以重点看下 Kong、Traefik 和 Zuul：
以下是其他网友的想法和结论，供参考：
基于Traefik的微服务网关技术栈选型
网关框架
整个网关框架分为3部分：
网关后端
它主要由3个模块组成：
一个应用只能绑定一个服务，但是可以绑定多个插件。通过后台完成网关配置后，这些配置信息会生成Config文件发布到ETCD。Config文件需要遵循严格的数据格式，比如Traefix的配置就需要遵循官方的文件配置格式才能被Traefik识别。
协议转换模块
hal-proxy模块是整个微服务网关中最为复杂，技术要求最高的模块，我来详细讲解一下。
问题介绍
在讨论该模块之前，我们先来看一下以下问题：
实现原理
我们先来看一下hal-proxy里面的模块，首先是Resolver模块，这个模块的作用是什么呢？这里我简单介绍一下，在公司内部通过服务获取机器列表的方式有很多种，比如MIS平台，服务树等，有的是通过平台配置，有的直接挂在服务树下面，不管哪种方式，我们都是使用服务名加上一定的方法来找到服务下所有的主机。
所以Resolver模块的作用其实就是通过服务名找到该服务下所有机器的IP和服务端口，然后持久化到内存中，并定期更新。
protocol模块支持不同的协议转换，每种协议类型的转换需要单独实现，这些协议转换无非就是通过机器IP和端口初始化Client，然后转换数据直接发送给下游机器。
最后就是连接池了，之前其实我们用的是go自带的池子，但是更新池子数据的时候需要加锁，性能不佳，后来改成循环队列，然后所有数据操作都通过原子操作，实现了无锁操作，并发性能大大提升。
实现逻辑
这是hal-proxy的逻辑实现图，我花了2天画的，包含了所有核心对象的交互方法，这里就不详细解释了，看你自己能理解掌握多少了。如果还有疑问（或者看不清楚图），可以关注我的公众号，加我微信交流。
宁可无书，不可盲信，由于个人能力有限，难免有疏漏和错误，如果大家发现bug或者有更好的建议，欢迎批评指正，我将不胜感激。
