网关

网关的由来

在微服务架构中，每个服务都是一个可以独立开发和运行的组件，而一个完整的微服务架构由一系列独立运行的微服务组成。其中每个服务都只会完成特定领域的功能，比如订单服务提供与订单业务场景有关的功能、商品服务提供商品展示功能等。各个微服务之间通过轻量级通信机制 REST API 或者 RPC 完成通信。 微服务之后在某些层面会带来一定的影响，比如，一个用户查看一个商品的详情，对于客户端来说，可能需要调用商品服务、评论服务、库存服务、营销服务等多个服务来完成数据的渲染在这个场景中，客户端虽然能通过调用多个服务实现数据的获取，但是会存在一 些问题，比如：

• 客户端需要发起多次请求，增加了网络通信的成本及客户端处理的复杂性。
• 服务的鉴权会分布在每个微服务中处理，客户端对于每个服务的调用都需要重复鉴权。
• 在后端的微服务架构中，可能不同的服务采用的协议不同，比如有 HTTP、RPC 等。客户端如果需要调用多个服务，需要对不同协议进行适配。

微服务网关的作用

所以，我们可以在微服务之前增加一个前置节点，这个节点就是网关，
什么是网关呢？ 大家都知道，从一个房间走到另一个房间，必然要经过一扇门,同样，从一个网络向另一个网络发送信息，也必须经过一道关口，顾名思义，网关就是一个网络连接到另一个网络的“关口”。也就是网络。
而在微服务架构中，它不仅仅只是一个网络互连的一个关口，还有更多的作用，上面分析的这个场景为例，增加网关之后。

对于这个的场景来说，增加了 API 网关之后，在 API 网关层可以把后端的多个服务进行整合，然后提供一个唯一的业务接口，客户端只需要调用这个接口即可完成数据的获取及展示。在网关中会再去消费后端的多个微服务进行统一的整合，给客户端返回一个唯一的响应。
当然，网关不仅只是做一个请求转发以及服务整合，有了网关这个统一的入口之后，它还能提供

• 针对所有请求进行统一鉴权、限流、熔断、日志。
• 协议转化。针对后端多种不同的协议，在网关层统一处理后以 HTTP 协议对外提供服务。
• 用过 Dubbo 框架的读者应该知道，针对 Dubbo 服务还需要提供一个 Web 应用来进行协议转化。
• 统一错误码处理。
• 请求转发，并且可以基于网关实现内外网隔离。

网关的作用

性能：API高可用，负载均衡，容错机制。
安全：权限身份认证、脱敏，流量清洗，后端签名（保证全链路可信调用）,黑名单（非法调用的限制）。
日志：日志记录（spainid,traceid）一旦涉及分布式，全链路跟踪必不可少。
缓存：数据缓存。
监控：记录请求响应数据，api耗时分析，性能监控。
限流：流量控制，错峰流控，可以定义多种限流规则。
灰度：线上灰度部署，可以减小风险。
路由：动态路由规则。

服务网关的要求

从上面的这个架构图来看，网关成了所有流量的入口，那么对于这样一个角色来说，它需要在某些方面有很高的要求。

• 稳定性，
• 安全性，防止恶意请求，以及保障数据传输的安全性
• 高性能、可用性，
  • 网关作为所有流量的入口，那么对于性能这块的要求就非常高了，因为一旦网关的性能出现瓶颈，即便后端的服务性能再高，意义也不大
  • 网关必须要支持集群部署，这个是分布式架构的基本要求。否则网关服务挂掉就会导致整个系统不可用
• 扩展性，可维护性，对于定制化需求方面，如何实现可扩展;

常见的网关方案

OpenResty（Nginx+lua）
Kong，是基于openresty之上的一个封装，提供了更简单的配置方式。 它还提供了付费的商业插件; 
Tyk（开源、轻量级），Tyk 是一个开源的、轻量级的、快速可伸缩的 API 网关，支持配额和速度限制，支持认证和数据分析，支持多用户多组织，提供全 RESTful API。它是基于go语言开发的组件;
Zuul，是spring cloud生态下提供的一个网关服务，性能相对来说不是很高;
Spring Cloud Gateway，是Spring团队开发的高性能网关。

网关选型

对于网关选型，主要关注几个方面

• 部署和维护成本
• 开源还是闭源
• 是否私有化部署
• 功能是否满足当前需求
• 社区资料的完善以及版本迭代和功能维护