服务网关与流量网关

1.为什么需要服务网关

在了解这个问题 之前，我们需要知道什么是网关，很多地方将网关比如成门, 没什么问题, 但是需要区分网关与网桥的区别。

网桥 工作在数据链路层，在不同或相同类型的LAN之间存储并转发数据帧，必要时进行链路层上的协议转换。可连接两个或多个网络，在其中传送信息包。

网关 是一个大概念，不具体特指一类产品，只要连接两个不同的网络都可以叫网关,网桥一般只转发信息,而网关可能进行包装。

传统的单体架构中只需要开放一个服务给客户端调用，但是微服务架构中是将一个系统拆分成多个微服务，如果没有网关，客户端只能在本地记录每个微服务的调用地址，当需要调用的微服务数量很多时，它需要了解每个服务的接口，这个工作量很大。那有了网关之后，能够起到怎样的改善呢？

网关作为系统的唯一流量入口，封装内部系统的架构，所有请求都先经过网关，由网关将请求路由到合适的微服务，所以，使用网关的好处在于：

• 简化客户端的工作。 网关将微服务封装起来后，客户端只需同网关交互，而不必调用各个不同服务；
• 降低函数间的耦合度。 一旦服务接口修改，只需修改网关的路由策略，不必修改每个调用该函数的客户端，从而减少了程序间的耦合性。
• 解放开发人员把精力专注于业务逻辑的实现。 由网关统一实现服务路由(灰度与ABTest)、负载均衡、访问控制、流控熔断降级等非业务相关功能，而不需要每个服务 API 实现时都去考虑。

但是 API 网关也存在不足之处，在微服务这种去中心化的架构中，网关又成了一个中心点或瓶颈点，它增加了一个我们必须开发、部署和维护的高可用组件。

正是由于这个原因，在网关设计时必须考虑即使 API 网关宕机也不要影响到服务的调用和运行，所以需要对网关的响应结果有数据缓存能力，通过返回缓存数据或默认数据屏蔽后端服务的失败。

在服务的调用方式上面，网关也有一定的要求，API 网关最好是支持 I/O 异步、同步非阻塞的，如果服务是同步阻塞调用，可以理解为微服务模块之间是没有彻底解耦的，即如果A依赖B提供的API，如果B提供的服务不可用将直接影响到A不可用，除非同步服务调用在API网关层或客户端做了相应的缓存。

因此为了彻底解耦，在微服务调用上更建议选择异步方式进行。而对于 API 网关需要通过底层多个细粒度的 API 组合的场景，推荐采用响应式编程模型进行而不是传统的异步回调方法组合代码，其原因除了采用回调方式导致的代码混乱外，还有就是对于 API 组合本身可能存在并行或先后调用，对于采用回调方式往往很难控制。

2.服务网关的基本功能

3.流量网关与服务网关的区别

流量网关和服务网关在系统整体架构中所处的位置如上图所示，流量网关（如Nignx)是指提供全局性的、与后端业务应用无关的策略，例如 HTTPS证书卸载、Web防火墙、全局流量监控、日志记录、黑白名单控制、接入请求到业务系统的负载均衡等，Kong 就是典型的流量网关。

而微服务网关（如Spring Cloud Gateway）是指与业务紧耦合的、提供单个业务域级别的策略，如服务治理、身份认证,权限控制、日志输出、数据加密、熔断限流等等。

业务网关每个微服务应用都需要，因此存在着大量重复的代码实现。

而且由于系统的迭代、人员的更替，各个微服务中这些功能的实现细节出现了较大的差异，导致维护成本变高。另一方面，原先单体应用下非常容易做的接口管理，在服务拆分后没有了一个集中管理的地方，无法统计已存在哪些接口、接口定义是什么、运行状态如何。

网关就是为了解决上述问题。作为微服务体系中的核心基础设施，一般需要具备接口管理、协议适配、熔断限流、安全防护等功能，各种开源的网关产品（比如 zuul,Gateway）都提供了优秀高可扩展性的架构、可以很方便的实现我们需要的一些功能、比如鉴权、日志监控、熔断限流等。

也就是说，流量网关负责南北向流量调度及安全防护，微服务网关负责东西向流量调度及服务治理。

这里需要补充一点的是，业务网关一般部署在流量网关之后、业务系统之前，比流量网关更靠近业务系统。通常API网指的是业务网关。 有时候我们也会模糊流量网关和业务网关，让一个网关承担所有的工作,所以这两者之间并没有严格的界线。

4.常见网关对比

目前常见的开源网关大致上按照语言分类有如下几类：

• Nginx+lua：OpenResty、Kong、Orange、Abtesting gateway 等
• Java：Zuul/Zuul2、Spring Cloud Gateway、Kaazing KWG
• gravitee、Dromara soul 等
• Go：Janus、fagongzi、Grpc-gateway
• Dotnet：Ocelot
• NodeJS：Express Gateway、Micro Gateway

按照使用数量、成熟度等来划分，主流的有 4 个：

• OpenResty
• Kong
• Zuul/Zuul2
• Spring Cloud Gateway

在我们SpringCloud微服务架构体系下，我们最常用的便是Zuul、Spring Cloud Gateway。

因为zuul2.0连续跳票和zuul的性能表现不是很理想，所以催生了spring团队开发了Gateway项目。

Zuul使用的是阻塞式的 API，不支持长连接，比如 websockets。底层是DNservletS缓存，Zuul处理的是http请求。没有提供异步支持，流控等均由hystrix支持。

Gateway则是Spring Boot和Spring Webflux提供的Netty底层环境，不能和传统的Servlet容器一起使用，也不能打包成一个WAR包。

依赖spring-boot-starter-webflux和spring-cloud-starter-gateway提供了异步支持，提供了抽象负载均衡，提供了抽象流控，并默认实现了RedisRateLimiter。

两者的相同点和不同点：
相同点：

• 1、底层都是servlet
• 2、两者均是web网关，处理的是http请求

不同点：

• 1、内部实现：
  gateway对比zuul多依赖了spring-webflux，在spring的支持下，功能更强大，内部实现了限流、负载均衡等，扩展性也更强，但同时也限制了仅适合于Spring Cloud套件
  zuul则可以扩展至其他微服务框架中，其内部没有实现限流、负载均衡等。
• 2、是否支持异步
  zuul仅支持同步
  gateway支持异步。理论上gateway则更适合于提高系统吞吐量（但不一定能有更好的性能），最终性能还需要通过严密的压测来决定