网关: 用途和产品对比

概述

• 微服务中的有一个非常关键的组件: API网关

• 和配置中心一样，在没有采用微服务架构的时候

• 我们可以自己搭建自己的API网作作为统一的 API 出口和安全验证

• 在微服务架构之下，服务被拆的非常的零散，在降低了耦合度的同时

• 也给服务的统一管理增加了难度，就如下边这张图

  

• 在旧的服务治理下，像身份验证, 限速, 安全, 日志等等这些通用的功能

• 需要在每一个服务中单独实现, 这使得系统的维护就没有一个全局的视图来统一的管理这些功能

• Api 网关致力于解决这些问题，它为微服统一管理这些通用的功能

• 在此基础上提高系统的可扩展性，看下面这张图

• 用了微服务之后，搭建上API网关就变成了下面这样

  

• 它可以使得服务本身更专注于自己的领域，很好的对服务调用者和服务提供者做了隔离

• 也就是身份认证，限速，安全，日志，缓存，监控等等，这些都由API网关来做了

• 而下边的每一个服务，它只需要关心自己的领域，做好自己的服务就可以了

API网关的意义

• 首先它可以集合多个API， 统一API的入口
  • 既然是微服务，肯定会有很多很多的服务
  • 假如有API网关在调用多个微服务的时候，就只需要调用API网关就可以了
  • 不用关心每一个微服务，它的地址是什么等等
  • 调用的时候只需要告诉API网关, 我要调用哪个微服务就可以
• 避免内部信息的泄露
  • 因为它对所有的API进行了管控，自然也就避免了泄露
  • 这样下边的服务就不用关心安全问题了，也不用关心自己的敏感信息被暴露的问题
• 提供安全认证
  • 为服务还提供了安全认证，比如说 sql 注入安全验证等等
  • 权限的控制，也可以在API网关中来做
• 支持混合的通信协议
  • 一般都会采用 HTTP Restful 等协议
  • 而微服务内部的通信一般会使用 GRPC，AMQP协议等等，它是不统一的
  • 这些一般外部系统也是不支持的，所以需要通过API网关来对外提供API的服务，并且统一协议
• 降低微服务的复杂度
  • 微服务一般会比单体架构有很大的管理复杂度，比如说令牌的验证，限流等等
  • 假如没有API网关的话，每个微服务都要自己来做这些功能
  • 微服务对外开放后就要考虑安全的问题
  • 微服务引入了API网关之后呢，每个服务就不用关心这些问题
  • 这些问题都放在API网关上来做就行了

API网关弊端

• 集合增加额外管理和维护成本
  • 首先它需要安装新的中间件
  • 这样也就增加了额外的管理和维护的成本
• 避免开发时需遵循网关路由规则
  • 开发的时候，指定路由的时候，需要按照api的网关的规则来指定
• 容易引发单点故障
  • 因为是api网关，所以就会有单一的入口
  • 大家请求都会访问到这个入口
  • 假如API网关出现问题以后，就会导致所有的微服务都不可用了

API 网关产品对比

1 ）nginx

• 它用的比较广泛，它是免费开源的高性能的HTTP服务器和反向代理服务器
• 同时也是可以用作 API 网关的，它以高性能稳定丰富的功能级简单的配置和资源的消耗闻名
• Nginx 作为API网关非常的简单，配置也比较简单

2 ) Zuul

• 它是 SpringCloud中的一个组件，使用非常方便，它提供了一些非常多的功能
• 比如说，认证，鉴权，限流，动态路由，监控，弹性，安全负载均衡等等
• 所以用做来做网关是一个非常不错的选择

3 ）Kong

• 它是专注于提供微服务API网关的一个平台
• 对比，Zuul 只是其中一个组件，而Kong是专注于提供微服务网关，它专门做这个，并且是一个平台
• 它本身是基于Nginx来实现的, 但是它在Nginx的基础之上，又提供了更方便的配置方式和插件
  • 比如说：验证，日志，限流等等
• 当需要为应用添加限流功能的时候
  • 因为它只提供了基本的路由功能
  • 开发者需要自己来研发相应的功能，才可以
  • 可能你觉得一个功能还并不麻烦
  • 但是如果在此基础上，今后提出更多的要求，那就比较麻烦了
• 对于Kong来说，限流功能就是一个插件，只需要简单的配置就可以
• Kong的插件机制是极高可扩展性的, 可以很方便的为路由和服务提供各种插件
• 网关所需要的基本特性，它也全部都具备