业务网关该如何划分

业务网关通常是外部网关和内系统之间的桥梁，我们该如何划分呢？业务系统配置多少个网关才合适？也许你会说项目一个拦截器或者过滤器就搞定了，但项目升级等限流很难，需要调整业务应用，架构需要让我们应用层变的简单和清晰。

在实际的业务系统，一般分为客户端、运营端、移动端、开放平台API，一个统一的网关无法解决开放API和内部、多端 API 强耦合的问题，所肯定需要多网关的。

首先开放平台是指为企业内部系统提供对外服务的平台。开放平台可以将企业内部系统的服务对外开放，让开发者和第三方合作伙伴可以方便地使用和集成这些服务，实现企业与外部生态系统的互动。开放平台通常包含API接口、SDK、文档、开发者社区等组件。

内部业务网关通常是微服务服务架构中的一个组件，负责服务之间的路由、转发、负载均衡、容错等工作。还可以提供鉴权、限流、熔断、降级等功能，保障服务的安全性和可用性。服务网关是服务治理的入口，能够对系统的请求流量进行统一管理和控制。

网关验权，让应用层更简单。如果对性能要求比较高，把对应的数据token及权限信息，直接推送到相关的Redis及ETCD中，不要再去调用相关的接口。

开放平台API和内部系统API应该要分开的，两者的鉴权方式不同，限流的策略也不同，更重要的是考虑隔离性，互不影响。

运营端和客户端的 API 也最好分开，两者权限是不同的，客户端一般是根据用户ID去操作鉴权，运营端根据角色去做鉴权。客户端的流量一般比较大，方便限流。一般内部运营管理系统，需要做内外网隔离。

如果是多租户系统，还会有租户管理端，管理端的管理员用户有着访问和操作更多数据的权限，如果误操作，就会产生严重的安全事故。运营端和客户端接口权限是不能相互访问的。因此，我认为业务网关需要至少分为三个网关：开放平台API网关、客户端API网关、运营端（管理端）API网关。关系图如下：

某个业务如果要想区分每个路由的转发前缀，建议从业务应用的Controller第一层Mapping做区分，这样通过统一定义规范，清晰看见每个应用的接口归属的端。

内部业务应用如果部署到容器云上，还会有一层容器云网关，读到这里你可能会问，这么多网关合理吗？网关要做到高性能、清晰可靠，肯定是需要每一个链路节点起的作用是不同的，行业常用的架构分层也多是多层级网关架构。有负责流量入口的流量网关，有业务层的业务网关，有能力层的能力网关。所以这么多网关也是是合理的。