概述
-
微服务中的有一个非常关键的组件: 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的插件机制是极高可扩展性的, 可以很方便的为路由和服务提供各种插件
- 网关所需要的基本特性，它也全部都具备
