微服务“大门”如何选择？

使用微服务网关作为微服务面向客户端的单一入口，是目前普遍采用的微服务架构模式。企业组织通过良好定义的 API 将内部系统向内部和外部用户公开，通常都会采用 API （微服务）网关来处理横向的关注点，包括访问控制、速率限制、负载均衡等等，来实现安全可控的 API 开放。广泛实践的微服务架构中，似乎有很多产品具有这些能力，那如何更好的根据我们的业务场景选择最合适自己的“大门”呢？

性能选择-Nginx

---

Nginx 应该是 Web 应用的标配组件，使用场景包括负载均衡、反向代理、代理缓存等。Nginx 的内核的设计非常微小和简洁，实现的功能也相对简单，仅仅通过查找配置文件与请求进行 URL 匹配，用于启动不同的模块去完成相应的工作。
Nginx 在启动后，会有一个 Master 进程和多个 Worker 进程，Master 进程和 Worker 进程之间是通过进程间通信进行交互的。Worker 工作进程的阻塞点是在像 select()、epoll_wait() 等这样的 I/O 多路复用函数调用处，以等待发生数据可读 / 写事件。Nginx 采用了异步非阻塞的方式来处理请求，是可以同时处理成千上万个请求的。

服务亲和-Zuul & Sping Cloud Gateway

---

Zuul 是 Netflix 开源的微服务网关组件，其可以配合 Eureka、Nacos 等开源产品实现不错的服务发现能力，同时集成Ribbon、Hystrix 或 Sentinel 等组件实现对整个链路的流控。
Zuul 的核心是一系列的过滤器，这些过滤器许多功能，例如：
• 鉴权与访问控制： 识别每次请求的合法性，并拒绝那些没有在授权列表中的来源请求。
• 审计与监控：记录每次请求/响应的内容，以及 RT/错误率等，从而分析出 API 的动态质量、安全情况。
• 动态路由负载：动态地将请求路由分流到不同的服务、应用或者集群。
• 统一上下文：在请求转发前根据业务需求设置公共的上下文信息向后传递。
• Mock 响应：针对简单请求可以组合配置中心，直接在网关层直接响应，从而避免其转发到内部。
上面提及的这些特性是 Nginx 所没有的，Netflix 公司研发 Zuul 是为了解决微服务场景的诸多问题，而不仅仅是做一个类似于 nginx 的反向代理。
Spring Cloud Gateway 是 Spring Cloud 的一个全新项目，该项目是基于 Spring 5.0，Spring Boot 2.0 和 Project Reactor 等技术开发的网关，它旨在为微服务架构提供一种简单有效的统一的 API 路由管理方式。
Spring Cloud Gateway 作为 Spring Cloud 生态系统中的网关，目标是替代 Zuul，在Spring Cloud 2.0 以上版本中，没有对新版本的 Zuul 2.0 以上最新高性能版本进行集成，仍然还是使用的 Zuul 2.0 之前的非 Reactor 模式的老版本。而为了提升网关的性能，SpringCloud Gateway 是基于 WebFlux 框架实现的，而 WebFlux 框架底层则使用了高性能的 Reactor 模式通信框架 Netty。
Spring Cloud Gateway 的目标，不仅提供统一的路由方式，并且基于 Filter 链的方式提供了网关基本的功能，例如：安全，监控/指标，和限流。

两者兼得-Kong

---

Kong 是一款基于 Nginx_Lua 模块写的高可用服务网关，由于 Kong 是基于 Nginx 的，所以可以水平扩展多个 Kong 服务器。通过前置的负载均衡配置把请求均匀地分发到各个 Server，来应对大批量的网络请求。
Kong 主要有三个组件：
• Kong Server：基于 nginx 的服务器，用来接收 API 请求。
• Apache Cassandra/PostgreSQL：用来存储操作数据。
• Kong dashboard：官方推荐 UI 管理工具，当然，也可以使用 restfull 方式管理 admin api。
Kong 采用插件机制进行功能定制，插件集（可以是 0 或 N 个）在 API 请求响应循环的生命周期中被执行。插件使用 Lua 编写，基础功能包括：HTTP 基本认证、密钥认证、CORS（Cross-Origin Resource Sharing，跨域资源共享）、TCP、UDP、文件日志、API 请求限流、请求转发以及 Nginx 监控等。
Kong 网关具有以下的特性：
• 可扩展性：通过简单地添加更多的服务器，可以轻松地进行横向扩展，这相较于 nginx 能让你省心不少，但可能相对于 Zuul 稍稍弱些；
• 模块化：可以通过添加新的插件进行扩展，这些插件可以通过 RESTful Admin API 轻松配置；
• 在任何基础架构上运行：Kong 网关可以在任何地方都能运行，可以在云或内部网络环境中部署 Kong。

自建 OR 云产品

---

但是！有过使用经验的同学应该会发现，真正用起来我们还需要更多的服务发现能力、更全面的监控可观测能力、更高的稳定性保障，那么到底是自己手工打造还是购买成本更合适呢？我们先来看下自建和云产品的比较：

自建 VS 托管云产品

能力	自建	托管
弹性扩缩容	需要自建维护K8s	产品控制台直接操作
多种开发语言	Kong 使用 Lua 来扩展（可能还需要掌握 nginx ），Zuul 用 Java 实现	全都要，不用关注
服务发现	Kong 不支持，Zuul 支持部分需要开发	支持 Eureka、Nacos 等
监控大盘	需要一个团队支持，且要二次开发	控制台一键创建
协议转换	需要服务框架团队开发	支持 Http、Dubbo 等
微服务治理	需要中间件团队支持	集成 MSE 支持无损上下线、金丝雀发布、标签路由、离群实例摘除等

对比可以看到，这些能力使用托管的 MSE 微服务网关就相当于省去了一个运维团队、一个中间件团队、一个多语言开发能力的研发团队。现在，您只要结合自己的业务场景选择合适的引擎即可：

• 接入层场景选择 Kong，性能高 SSL 安全能力匹配；

• 业务分支选择 Zuul，自定义扩展方便还有很强的服务发现能力；

• 或者如果你是 Spring Cloud 技术体系，那么赶紧把 Spring Cloud Gateway 加入你的全家桶吧。
  

云产品的各引擎对比

更多内容了解： https://www.aliyun.com/product/aliware/mse

总结

---

微服务网关作为微服务流量的“大门”，它的稳定性、安全性、功能完备性上的要求是要远远高于我们业务自身的，我们往往需要投入非常大的人力和时间在他的运维和开发上，并还未必能保证有非常好的效果；BaaS 化的服务型（全托管）云产品，帮助我们的用户坚持开源技术栈这一大方向不变的基础上，更稳定、更便捷、更专注的为我们业务保驾护航。