概述
不同的微服务一般会有不同的网络地址，而外部客户端可能需要调用多个服务的接口才能完成一个业务需求，如果让客户端直接与各个微服务通信，会有以下的问题：
- 客户端会多次请求不同的微服务，增加了客户端的复杂性。
- 存在跨域请求，在一定场景下处理相对复杂。
- 某些微服务可能使用了防火墙/浏览器不友好的协议，直接访问会有一定的困难。
- 难以重构，随着项目的迭代，可能需要重新划分微服务。例如，可能将多个服务合并成一个或者将一个服务拆分成多个。如果客户端直接与微服务通信，那么重构将会很难实施。
- 认证复杂，每个服务都需要独立认证。
以上这些问题可以借助网关解决。
网关的角色是作为一个 API 架构，用来保护、增强和控制对于 API 服务的访问。它是介于客户端和服务器端之间的中间层，所有的外部请求都会先经过网关这一层。也就是说，API 的实现方面更多的考虑业务逻辑，而安全、性能、监控可以交由网关来做，这样既提高业务灵活性又不缺安全性，
架构
网关的典型架构图如下图所示：
四大职能
- 请求接入： 作为所有 API 接口服务请求的接入点，管理所有的接入请求。
- 业务聚合： 作为多有后端业务服务的聚合点，所有的业务服务都可以在这里被调用。
- 中介策略： 实现安全、验证、路由、过滤、流控、缓存等策略，进行一些必要的中介处理。
- 统一管理： 提供配置管理工具，对所有 API 服务的调用生命周期和相应的中介策略进行统一管理。
分类与功能
面对互联网复杂的业务系统，基本可以将网关分为两类：流量网关和业务网关。
- 流量网关： 跟具体的后端业务系统和服务完全无关的部分，比如安全策略、全局性流控策略、流量分发策略等。
- 业务网关： 针对具体的后端业务系统，或者是服务和业务有一定关联性的部分，并且一般被直接部署在业务服务的前面。业务网关一般部署在流量网关之后，业务系统之前，比流量网关更靠近系统。我们大部分情况下说的 API 网关，狭义上指的是业务网关。并且如果系统的规模不大，我们也会将两者合二为一，使用一个网关来处理所有的工作。
应用场景
- 单点入口
- 路由转发
- 限流熔断
- 日志监控
- 安全认证
高级应用场景
- 红绿部署
- 开发者测试分支
- 埋点测试
- 压力测试
- 调试路由
- 金丝雀测试（粘性）
- 失败注入测试
- 降级测试
网关 VS 反向代理
网关提供的基本功能与传统反向代理是大同小异的，不过网关主要是面向 API 和微服务，以提供更灵活的、可以由研发自助（可编程）的的动态配置的能力。
主流开源网关概览
| 支持公司 | 实现语言 | 亮点 | 不足 | |
|---|---|---|---|---|
| Nginx(2004) | Nginx Inc | C/Lua | 高性能，成熟稳定 | 门槛高，偏运维，可编程弱 |
| Kong(2014) | Kong Inc | OpenResty/Lua | 高性能，可编程 API | 门槛较高 |
| Zuul1(2012) | Netflix/Pivotal | Java | 成熟，简单门槛低 | 性能一般，可编程一般 |
| Spring Cloud Gateway(2016) | Pivotal | Java | 异步，配置灵活 | 早期产品 |
| Envoy(2016) | Lyft | C++ | 高性能，可编程 API，ServiceMesh 继承 | 门槛较高 |
| Traefik(2015) | Containous | Golang | 云原生，可编程 API，对接各种服务发现 | 生产案例不多 |
