为什么会出现网关在微服务的架构体系中，可以简单的看成是一个大应用拆分成多个小应用。小应用可以形成自己的系统，可以有自己的数据库、Frameworks甚至语言等，每个小应用一般通过Rest接口的形式被第三方、H5或者APP调用。这时候难免会出现这样的情况，有些页面需要多种服务的组合才能获取用户需要的信息。举个例子：在电商系统中，查看商品详情页。这个商品详情页面包含了商品的详情、价格、库存、评论等，这些数据对于后端来说是位于不同的微服务系统中。后台系统服务是这样拆分的：商品服务：负责提供商品的标题、描述、规格等。营销服务：负责产品定价、价格策略计算、促销价格等。库存服务：负责产品库存。评价服务：负责用户对产品的评价和回复。当我们不做任何处理的时候，调用是这样的：这个地方的缺点是前端需要多次调用服务才能拿到我们想要的数据。为了解决这个问题，我们可以做一个中间聚合层，聚合层也就是我们通常所说的BFF（Back-endforFront-end）。BFF可以认为是一个适配服务，对后端微服务进行适配（主要包括聚合、裁剪和格式适配的逻辑），实现上没有太多的限制，做请求转发和适配就可以了数据转换。升级后，框架如下所示。之前我们的系统就是这个阶段：多个汇聚层，有很多代码跨段重复，比如安全认证，日志记录。监控、限流和熔断等，代码随着时间的发展变得不可维护；随着访问量和业务的增加，两个BFF层已经不能满足我们的业务了，所以我们需要抽象出更多的BFF，采用集群部署。接下来，我们再次升级我们的架构，如下图所示：这里我们介绍一下本章主角的网关。通过网关的加入，我们可以把所有跨段的代码都抽象到网关层，这样我们的BFF层只需要专注于服务适配。配置的逻辑也解决了之前单点多节点业务的问题。这时候你可能会认为网关的部署也是单点的。这时候可以考虑在网关前面挂一层NG或者F5。如果随着业务的发展由网关管理的服务越来越多，也可以按照业务领域将网关作为一个整体进行拆分。至此，您一定已经明白为什么需要网关了。写到这里，突然想起一位伟人说过的一句话。没有什么是加个中间层解决不了的。如果有就加两个...，BFF或者gateway或者是我们的中间层。网关选择目前市场上大概有一些网关，根据不同的技术栈实现：接下来简单了解一下以上五种网关：Nginx：Nginx由内核和模块组成。内核的设计非常小巧简洁，完成的工作也非常简单，只需搜索配置文件，匹配客户端请求的URL，用于启动不同的模块，完成相应的工作。Nginx启动后会有一个Master进程和多个Worker进程。Master进程和Worker进程通过进程间通信进行交互，如图所示。Worker工作进程的阻塞点在select()、epoll_wait()等I/O多路复用函数调用处，等待数据读写事件发生。Nginx采用异步非阻塞的方式处理请求，也就是说Nginx可以同时处理上千个请求。也可以把Lua嵌入到Nginx中，这样就可以用Lua写脚本，这样就可以用Lua写应用脚本，部署到Nginx中运行，也就是Nginx成为一个web容器；使开发者可以使用Lua语言开发高性能的网络应用。开发时使用OpenResty搭建开发环境。OpenResty封装了Nginx核心、LuaJIT、很多好用的Lua库，以及Nginx第三方模块；这样，你只需要安装OpenResty，不需要了解Nginx核心和编写复杂的C/C++模块就可以了，只需要使用Lua语言进行web应用开发。Kong：Kong是Mashape基于OpenResty（Nginx+Lua模块）编写的高可用、易扩展的API网关项目。Kong基于NGINX和ApacheCassandra或PostgreSQL构建。它可以提供一个易于使用的RESTfulAPI来操作和配置API管理系统，因此可以水平扩展多个Kong服务器并将请求平均分配到每个服务器，以处理大量的网络请求。Kong具有三个主要组件：KongServer：基于Nginx的服务器，用于接收API请求。ApacheCassandra/PostgreSQL：用于存储运行数据。Kongdashboard：推荐使用官方的UI管理工具。当然adminapi也可以用RESTful方式管理。Kong采用插件机制进行功能定制，插件集（可以是0或N）在API请求响应周期的生命周期中执行。插件使用Lua编写，目前有几个基本功能：HTTP基本认证、密钥认证、CORS（Cross-OriginResourceSharing，跨域资源共享）、TCP、UDP、文件日志、API请求限流、请求转发和Nginx监控。KongGateway具有以下特点：可扩展性：通过简单地添加更多的服务器，它可以很容易地横向扩展，这意味着您的平台可以在较低的负载下处理任何请求；模块化：您可以通过添加可通过RESTfulAdminAPI轻松配置的新插件进行扩展；在任何基础设施上运行：Kong网关可以在任何地方运行。您可以在云或内部网络环境中部署Kong，包括单个或多个数据中心设置，以及公共、私有或仅限邀请的API。NetflixZuul：Zuul是Netflix开源的微服务网关组件，可与Eureka、Ribbon、Hystrix等组件配合使用。社区活跃，融入SpringCloud完整生态。是构建微服务系统前端网关服务的最佳选择。Zuul的核心是一系列过滤器。Zuul的核心是一系列过滤器。这些过滤器可以完成以下功能：认证和安全：识别每个资源的验证要求，拒绝那些不符合要求的请求。审计和监控：通过边缘位置跟踪有意义的数据和统计数据，从而获得准确的生产视图。动态路由：将请求动态路由到不同的后端集群。压力测试：逐渐增加集群的流量以了解性能。负载分配：为每种负载类型分配相应的容量，并丢弃超过限制的请求。静态响应处理：直接在边缘构建部分响应，避免将它们转发到内部集群。多区域弹性：跨AWS区域的请求路由，旨在多样化ELB（ElasticLoadBalancing，弹性负载平衡）的使用，让系统的边缘更接近系统的用户。Zuul目前有两个主要版本：Zuul1和Zuul2。Zuul1是基于Servlet框架构建的。如图所示，它采用阻塞和多线程的方式，即一个线程处理一个连接请求。这种方式在内部延时严重，设备故障较多的情况下，会导致存活连接数增加，导致大量设备故障。发生线程增加。Netflix发布的Zuul2有了重大更新。它在异步和非阻塞框架上运行。每个CPU内核都有一个线程来处理所有请求和响应。请求和响应的生命周期是通过事件和回调来处理的。方式减少了线程数，因此开销更少。SpringCloudGetWay：SpringCloudGateway是SpringCloud全新的API网关项目，目的是替代Zuul1。Gateway可以与SpringCloudDiscoveryClient（如Eureka）、Ribbon、Hystrix等组件配合使用，实现路由转发、负载均衡、熔断等功能。网关还内置了限流滤波器，实现限流功能。Gateway建立在Spring5、SpringBoot2和Reactor之上，使用Netty作为运行环境，完美支持异步非阻塞编程。Netty采用非阻塞IO，线程处理模型建立在主从Reactors多线程模型之上。其中，BossGroup轮询新连接并与Client建立连接，生成NioSocketChannel，并将channel绑定到Worker；WorkerGroup轮询并处理Read和Write事件。Soul：Soul是一个异步的、高性能的、跨语言的、响应式的API网关。参考Kong、Spring-Cloud-Gateway等优秀网关后，站在巨人的肩膀上，Soul诞生了！灵魂特性：支持多种语言，无缝集成Dubbo、SpringCloud。丰富的插件支持，认证、限流、断路器、防火墙等。网关动态配置多条规则，支持多种策略配置。插件支持热插拔，易于扩展，支持集群部署，支持A/BTest。下面都是基于WebFlux实现的，性能比基于Servlet的要高。性能方面，我觉得网关的选择可能没那么重要，多加几台机器就可以了。可维护性和可扩展性，Nginx+Lua的组合没有多少人。如果队伍有高手，高手可以为所欲为。如果没有看到这段话，对于一般的团队来说，选择自己团队擅长的语言比较重要，所以我选择了Java技术栈下的网关。对于Java技术栈下的三个网关，Zuul和SpringCloudGetway都或多或少需要集成和配置页面来维护，但是对于Soul，我无脑看文章，需要动哪一个，特别棒无需动脑就能连接到Dubbo。另外Soul2.0以后的版本可以去掉ZK。心里没有批评，喜欢无脑操作。对于高可用，网关高可用的策略基本上是一个统一的策略。都是采用多机部署的方式，前面挂一个负载。请注意一些需要在外部使用的组件。
