1 简介
1.1 网关服务的意义
1.1.1 点对点
- 服务之间直接调用，每个微服务都开放Rest API，并调用其他微服务的接口
1.1.2 API网关（使用最广）
随着服务数量增多，如果还是每个服务都直接对外部客户端提供接口，就会变得很复杂，最显然的就是每个服务都得自己实现鉴权。
这时，就需要一个角色充当 request 请求的统一入口，即服务网关。
业务接口通过API网关暴露，是所有客户端接口的唯一入口。 微服务之间的通信也通过API网关。
1.2 网关要素及演进史
- 稳定，高可用
- 安全性
- 性能、并发性
- 扩展性
- 限流熔断
- 动态路由和负载均衡
基于 Path 的路由
api.xxx.com/pathx
截获器链
日志采集和 Metrics 埋点
响应流优化
网关是具体核心业务服务的看门神，相比于具体实现业务的系统服务，它是一个边缘服务，主要提供动态路由，监控，弹性，安全性等功能。
下面我们从单体应用到多体应用的演化过程来讲解网关的演化历程，一般业务系统发展历程都是基本相似的，从单体应用到多应用，从本地调用到远程调用。
1.2.1 单体应用
由于只需一个应用，所有业务模块的功能都打包为了一个 War 包进行部署，这可以减少机器资源和部署的繁琐。
单体应用中，网关模块和应用部署到同一JVM进程，当外部移动设备或者web站点访问单体应用的功能时，请求是先被应用的网关模块拦截，网关模块对请求进行鉴权、限流等动作后在把具体的请求转发到当前应用对应的模块处理。
多体应用
先看个不用网关的案例，有的公司架构，虽然是微服务，但全部通过 nginx 进行请求转发
这样有啥缺点呢？
每个暴露的服务都需要自己的域名，且一旦修改，其他各个使用该服务的服务配置都需要修改。这些服务直接暴露在公网，存在安全问题。而且随着外部设备种类增多，大量兼容适配工作繁杂。
随着业务发展，网站流量越来越大，在单体应用中简单的通过加机器的方式可以带来的承受流量冲击的能力也越来越低，这时候就会考虑根据业务将单体应用拆成若干功能独立应用，单体应用拆为多个应用后，由于不同的应用开发对应的功能，所以多应用开发之间可以独立开发而不用去理解对方的业务，另外不同的应用模块只承受对应业务流量的压力，不会对其他应用模块造成影响，这时多体的分布式系统就出现了，如下
多体应用中业务模块A和B单独启个应用，每个应用里有自己的网关模块。
如果业务模块太多，每个应用都有自己的网关模块，复用性不好，考虑把网关模块提出来，单独作为一个应用做服务路由，如下
如上图当移动设备发起请求时候是具体发送到网关应用的，经过鉴权后请求会被转发到具体的后端服务应用上，对应前端移动设备来说他们不在乎也不知道后端服务器应用是一个还是多个，他们只能感知到网关应用的存在。
