网关：系统架构设计

如果希望实现一个能支撑百亿级吞吐量的网关，那么它就应该是按照分布式架构思维做去中心化设计，支持横向扩展。让每一台网关服务都成为一个算力，把不同的微服务RPC接口，按照权重策略计算动态分配到各个算力组中，做到分布式运算的能力。

此外从设计实现上，要把网关的通信模块、管理服务、SDK、注册中心、运营平台等依次分开单独开发实现，这样才能进行独立的组合包装使用。

这就像为什么 ORM 框架在开发的时候不是与 Spring 强绑定在一起，而是开发一个独立的组件，当需要有 Spring 融合使用的时候，再单独开发一个 Mybatis-Spring 来整合服务。

所以在这里设计网关的时候也是同样的思路，就像官网的通信不应该一开始就把 Netty 相关的服务全部绑定到 Spring 容器，这样即增加了维护成本，也降低了系统的扩展性。

诸如此类的软件架构设计，都会在这套网关微服务架构中体现，整体架构如图 1-2 所示

整个API网关设计核心内容分为这么五块；

• 第一块：是关于通信的协议处理，也是网关最本质的处理内容。这里需要借助 NIO 框架 Netty 处理 HTTP 请求，并进行协议转换泛化调用到 RPC 服务返回数据信息。
• 第二块：是关于注册中心，这里需要把网关通信系统当做一个算力，每部署一个网关服务，都需要向注册中心注册一个算力。而注册中心还需要接收 RPC 接口的注册，这部分可以是基于 SDK 自动扫描注册也可以是人工介入管理。当 RPC 注册完成后，会被注册中心经过AHP权重计算分配到一组网关算力上进行使用。
• 第三块：是关于路由服务，每一个注册上来的Netty通信服务，都会与他对应提供的分组网关相关联，例如：wg/(a/b/c)/user/... a/b/c 需要匹配到 Nginx 路由配置上，以确保不同的接口调用请求到对应的 Netty 服务上。PS：如果对应错误或者为启动，可能会发生类似B站事故。
• 第四块：责任链下插件模块的调用，鉴权、授信、熔断、降级、限流、切量等，这些服务虽然不算是网关的定义下的内容，但作为共性通用的服务，它们通常也是被放到网关层统一设计实现和使用的。
• 第五块：管理后台，作为一个网关项目少不了一个与之对应的管理后台，用户接口的注册维护、mock测试、日志查询、流量整形、网关管理等服务。

综上系统微服务模块结构如下：

序号	系统	描述
1	api-gateway-core	网关核心系统：用于网络通信转换处理，承接http请求，调用RPC服务，责任链模块调用
2	api-gateway-admin	网关管理系统：用于网关接口后台管理，注册下线停用控制
3	api-gateway-sdk	网关注册组件：用于注解方式采集接口，发送消息注册接口
4	api-gateway-center	网关注册中心：提供网关注册中心服务，登记网关接口信息
5	api-gateway-test-provider	网关测试工程：提供RPC接口
6	api-gateway-test-consumer	网关测试工程：消费RPC接口