微服务下的网关如何选择

前言

自从换了工做之后，将近5个月没有写博客了，这段时间经历一个身份的转变，从一个核心开发转变为了一个项目的Leader，这种感受说不上来的，虽然说是有些感悟，可是更多的是一些困惑，可是有一点是明确的，站的高度或者角度不一样，有些思考是不同的，有这种身份转换的，你们能够作一些交流，嘿嘿！开启咱们的正题，最近项目要从第三方外包的手中转成自有化的形式，咱们准备采用微服务的形式去作这件事。以前也想写这个系列的话题，整好趁着此次的改造来完成这个微服务序列的文章，首先咱们来介绍下网关这个组件。

为何出现网关

微服务的架构体系中，能够简单的看作是一个大应用拆分为多个小应用，小应用能够自成体系，能够拥有本身的数据库、框架甚至于语言等等，各个小应用通常经过Rest接口的形式被第三方、H5或者APP去调用。这个时候必然会存在一种状况，某些页面须要多个服务组合才能获得用户须要的信息。举个栗子:

在电商系统中，查看商品详情页，这个商品详情页包含商品的详情，价格，库存，评论等，这些数据对于后端来讲位于不一样的微服务系统之中，后台的系统是这样来拆分服务的：
商品服务:负责提供商品的标题，描述，规格等。
营销服务:负责对产品进行订价，价格策略计算，促销价等。
库存服务:负责产品库存。
评价服务:负责用户对商品的评论，回复等。

咱们不作任何处理的时候，调用的时候是这样:

该处的缺点就是前端须要调用屡次服务才能拿到咱们想要的数据，为了解决这个问题咱们能够作一层中间的聚合层，聚合层也就是咱们一般所说的BFF(Back-end for Front-end),BFF能够认为是一种适配服务，将后端的微服务进行适配（主要包括聚合裁剪和格式适配等逻辑），实现上没太大限制，能作请求转发和数据转化便可，升级之后框架是这样的，以前咱们系统处于这个阶段:
升级之后的框架解决了屡次调用的问题，可是这里地方会存在以下几个问题:
1.多个聚合层有不少跨横切面的代码是重复的，好比安全认证，日志监控，限流熔断等，随着时间的发展代码变得不可维护；
2.随着访问量、业务的增长，两个BFF层也知足不了咱们的业务，须要抽象更多的BFF和采用集群部署的方式；
接下来咱们再次升级咱们架构，以下图:

这里咱们引入的咱们本章的主角网关，因为网关的加入咱们能够将全部的跨横切面的代码统统抽象到网关层，这样咱们BFF层只须要关注服务适配的逻辑，另外也解决掉了以前业务单点、多节点的等问题，这个时候你可能又想，网关的部署也是单点了，这个时候你能够考虑在网关前挂一层NG或者F5，若是随着业务发展网关管理的服务愈来愈多，也能够将网关按照业务域进行总体的拆分。
到这里你必定了解到了为何须要网关，写到这里我忽然想到某个伟人说的一句话，没有什么是加一个中间层解决不了的，若是有，就加两个……，BFF也好、网关也好都是咱们的中间层。

网关选型

目前市面上根据技术栈实现的不一样大概有以下一些网关:

接下来咱们就简单了解下以上5个网关:
Nginx： Nginx由内核和模块组成，内核的设计很是微小和简洁，完成的工做也很是简单，仅仅经过查找配置文件与客户端请求进行 URL 匹配，用于启动不一样的模块去完成相应的工做。

Nginx 在启动后，会有一个 Master 进程和多个 Worker 进程，Master 进程和 Worker 进程之间是经过进程间通讯进行交互的，如图所示。Worker 工做进程的阻塞点是在像 select()、epoll_wait() 等这样的 I/O 多路复用函数调用处，以等待发生数据可读 / 写事件。Nginx 采用了异步非阻塞的方式来处理请求，也就是说，Nginx 是能够同时处理成千上万个请求的。

还能够将 Lua 嵌入到 Nginx 中，从而可使用 Lua 来编写脚本，这样就可使用 Lua 编写应用脚本，部署到 Nginx 中运行，即 Nginx 变成了一个 Web 容器；这样开发人员就可使用 Lua 语言开发高性能Web应用了。在开发的时候使用 OpenResty 来搭建开发环境，OpenResty 将 Nginx 核心、LuaJIT、许多有用的 Lua 库和 Nginx 第三方模块打包在一块儿；这样只须要安装 OpenResty，不须要了解 Nginx 核心和写复杂的 C/C++ 模块就能够，只须要使用 Lua 语言进行 Web 应用开发了。

Kong: Kong是一款基于OpenResty（Nginx + Lua模块）编写的高可用、易扩展的，由Mashape公司开源的API Gateway项目。Kong是基于NGINX和Apache Cassandra或PostgreSQL构建的，能提供易于使用的RESTful API来操做和配置API管理系统，因此它能够水平扩展多个Kong服务器，经过前置的负载均衡配置把请求均匀地分发到各个Server，来应对大批量的网络请求。

Kong主要有三个组件：

1. Kong Server ：基于Nginx的服务器，用来接收API请求。
2. Apache Cassandra/PostgreSQL ：用来存储操做数据。
3. Kong dashboard：官方推荐UI管理工具，固然，也可使用 restfull 方式 管理admin api。

Kong采用插件机制进行功能定制，插件集（能够是0或N个）在API请求响应循环的生命周期中被执行。插件使用Lua编写，目前已有几个基础功能：HTTP基本认证、密钥认证、CORS（Cross-Origin Resource Sharing，跨域资源共享）、TCP、UDP、文件日志、API请求限流、请求转发以及Nginx监控。

Kong网关具备如下的特性：

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

Netfilx Zuul：Zuul 是 Netflix 开源的微服务网关组件，它能够和 Eureka、Ribbon、Hystrix 等组件配合使用。社区活跃，融合于 SpringCloud 完整生态，是构建微服务体系前置网关服务的最佳选型。

Zuul的核心是一系列的filters, Zuul 的核心是一系列的过滤器，这些过滤器能够完成如下功能：

1. 身份认证与安全：识别每一个资源的验证要求，并拒绝那些与要求不符的请求。
2. 审查与监控：与边缘位置追踪有意义的数据和统计结果，从而带来精确的生产视图。
3. 动态路由：动态地将请求路由到不一样的后端集群。
4. 压力测试：逐渐增长指向集群的流量，以了解性能。
5. 负载分配：为每一种负载类型分配对应容量，并弃用超出限定值的请求。
6. 静态响应处理：在边缘位置直接创建部分响应，从而避免其转发到内部集群。
7. 多区域弹性：跨越 AWS Region 进行请求路由，旨在实现 ELB（Elastic Load Balancing，弹性负载均衡）使用的多样化，以及让系统的边缘更贴近系统的使用者。

Zuul 目前有两个大的版本：Zuul1 和 Zuul2
Zuul1 是基于 Servlet 框架构建，如图所示，采用的是阻塞和多线程方式，即一个线程处理一次链接请求，这种方式在内部延迟严重、设备故障较多状况下会引发存活的链接增多和线程增长的状况发生。

Netflix 发布的 Zuul2 有重大的更新，它运行在异步和无阻塞框架上，每一个 CPU 核一个线程，处理全部的请求和响应，请求和响应的生命周期是经过事件和回调来处理的，这种方式减小了线程数量，所以开销较小。

Spring Cloud GetWay：Spring Cloud Gateway 是Spring Cloud的一个全新的API网关项目，目的是为了替换掉Zuul1。Gateway能够与Spring Cloud Discovery Client（如Eureka）、Ribbon、Hystrix等组件配合使用，实现路由转发、负载均衡、熔断等功能，而且Gateway还内置了限流过滤器，实现了限流的功能。

  Gateway基于Spring 五、Spring boot 2和Reactor构建，使用Netty做为运行时环境，比较完美的支持异步非阻塞编程。Netty使用非阻塞的IO，线程处理模型创建在主从Reactors多线程模型上。其中Boss Group轮询到新链接后与Client创建链接，生成NioSocketChannel，将channel绑定到Worker；Worker Group轮询并处理Read、Write事件。

Soul: Soul是一个异步的,高性能的,跨语言的,响应式的API网关。参考了Kong，Spring-Cloud-Gateway等优秀的网关后，站在巨人的肩膀上，Soul由此诞生！

Soul特征:

1. 支持各类语言,无缝集成Dubbo,SpringCloud。
2. 丰富的插件支持，鉴权，限流，熔断，防火墙等等。
3. 网关多种规则动态配置，支持各类策略配置。
4. 插件热插拔,易扩展
5. 支持集群部署，支持A/B Test

总结一下:

1. 性能
   Nginx+Lua形式必然是高于Java语言实现的网关的，Java技术栈里面Zuul1.0是基于Servlet实现的，剩下都是基于webflux实现，性能是高于基于Servlet实现的。在性能方面我以为选择网关可能不算那么重要，多加几台机器就能够搞定。
2. 可维护性和扩展性
   Nginx+Lua这个组合掌握的人不算多，若是团队有大神，大佬们就随意了，当没看到这段话，对于通常团队来讲的话，选择本身团队擅长的语言更重要，因此我选择了Java技术栈下的网关。Java技术栈下的3种网关，对于Zuul和Spring Cloud Getway须要或多或少要搞一些集成和配置页面来维护，可是对于Soul我就无脑看看文章，须要哪一个搬哪一个好了，尤为是能够无脑对接Dubbo美滋滋，此外Soul2.0之后版本能够摆脱ZK，在我内心再无诟病，我就喜欢无脑操做。
3. 高可用
   对于网关高可用基本都是统一的策略都是采用多机器部署的方式，前面挂一个负载，对于而外须要用的一些组件你们注意一下。

结束

欢迎你们点点关注，点点赞，感谢!