前言
对于目前主流的后端架构来说，微服务的普及范围还是比较广泛的。
以一个后端的电商项目来说，一个系统可以拆分成用户、教育、订单、商品、活动等多个功能模块。如果全部的功能都集成在一个项目里面。某些可以共用的模块（比如用户、权限等）就没有办法共享给其他项目，项目的体积与代码复杂度也会逐步上升。导致后期的维护与协同成本会慢慢增加。
但是上述都不是最主要的问题，最主要的问题是你把多个模块放到一个系统里面，如果说一个模块出问题了，那么整个系统都会崩溃。
对于一个应用的稳定性来说。如果没办法对单一的模块做熔断、升级、回滚等操作。线上不可控的概率就会很大。这也是目前主流。这也是目前主流采用微服务架构最大的原因之一。
但是，当一个系统中的微服务模块非常多的化。那么也经常会出现如下问题：
- 通用性的认证、鉴权、限流等多个功能会导致每个微服务都存在造轮子的行为。
- 业务复杂度上升之后，存在域名分配的问题，没办法对每个服务都重新分配一个域名。同时每一个新的服务上线。运维重复配置的工作量多不少
- 太多的域名服务对客户端不友好。特别是请求层没有做BFF的话。每一次拆分新的微服务出来都可能会引起前端的改造。
- 并非每一个服务都是用同一种语言或者架构所开发。我们可以通过网关的统一入口来调度各个微服务功能模块。使得每个模块都可以专注于自身业务的开发。
什么是网关系统
网关请求类型可以分为：
- 静态资源网关：处理前端资源数据CSR、SSR等。
- API网关：随着微服务架构MSA的普及。通过统一的API网关可以聚合所有零散的微服务资源。保持统一的出口。降低多项目的接入成本以及其他项目的使用成本。
从功能属性上可以分为：
- 流量网关：无关业务属性，单纯做安全（黑白名单）、分流（负载均衡）等
- 业务网关：用户（认证、鉴权）、服务稳定性（降级、容灾）、业务属性灰度、代理（资源代理、缓存）、统一前置（日志）
Gateway
业务性的Gateway需要做点什么：
- 统一鉴权接口，通过统一配置给接口资源添加权限
- 支持RPC微服务调用。减少资源的损耗。
- 系统易于监控。同时可以采集收口进来的消息
通过两者的对比可以看出，Nginx 更关注负载均衡以及反向代理，对业务部分的侵入很低，而 Gateway 作为后端应用，可以携带业务属性，两者可以很好的互补。
在系统架构设计上，我们可以使用 Nginx 作为上文所说的流量网关，由 Nginx 做一层流量代理，通过负载均衡到 Gateway 做业务层的转发处理，这样可以减少我们自建网关系统的工作量。
