一、背景介绍
羚珑作为一款智能设计平台，简单易懂、可视化操作，同时拥有大量模板与素材为用户、商家或业务团队节省了大量作图时间从而达到降本增效。
随着使用的用户越来越多，同时业务也不断在增长，这也给羚珑服务端带来了挑战。
羚珑服务端目前架构如图所示由多个平台组成，每个平台都有自己的域名。随着业务增长每次都是启动一个平台来扩展功能，这种模式弊端也显现出来了。
对于后端同学来说，新建一个平台需要对接登录与权限；提供的 API 功能没有集中管理，不清楚正在开发的 API 是否有重复提供；开发的 API 在某些业务场景下还需要自行限流或降级；缺少全局 API 监控。
对于运维同学来说，要为后端同学开发完成的每个平台新建域名映射（同时还需要申请证书）。
对于前端同学来说，为了复用某些 API 功能还需要对接多个域名，同时还区分测试与生产环境域名，这就导致前端同学在项目中还需要维护一批域名。
根据以上场景，我们可以总结为，缺少 API 的统一入口与管理（统一域名）、统一鉴权、统一流控、统一监控。
如何解决以上架构痛点？我们需要一个服务承载在业务平台之上接收前端的请求，转发到相应的后端平台上，还可以对每个请求进行用户认证与权限校验，还可以对 API 精准限流与降级，同时对 API 请求响应异常进行监控上报。
这个服务就呼之欲出：API 网关，并取名为：Monet。下面我将介绍下这个网关中间件服务。
二、技术选型
确定了 Monet 需求之后，我们就开始进行技术选型。
基础框架选择
牛顿说过，如果说我别人看得更远些，那是因为我站在了巨人的肩膀上。所以我们需要站在巨人的肩膀才可以看得更远。那么 Monet 也一样，需要选取一款网关的框架，并在此基础之上进行扩展。
在技术选型需要从语言体系、社区活跃度、扩展性、性能等角度考虑。我们从社区活跃度比较高的选出了两个分类：非 Java 语言网关：Nginx、Kong、Traefik；Java 语言网关：Spring Cloud Gateway 与 Spring Cloud Zuul 2。
由于后端采用 Java 的 Spring 生态开发的，所以在编程语言一致性上更加倾向 Java 语言开发的组件。所以在 Spring 生态中有两款网关可供选择，分别是：Spring Cloud Gateway 与 Spring Cloud Zuul 2
Spring Cloud Gateway 由官方主推网关，Zuul 2 由 Netfix 公司开源的网关。两者在实际生产使用性能相比没有差距，Spring Cloud Gateway 基于 Spring 5.0、Spring Boot 2.0 与 Project Reactor，为服务提供一个简单有效的 API 网关；而 Zuul 1 基于同步 IO 与 Zuul 2 基于 Netty Server 异步 IO，都是 Spring Cloud 生态中的组件。以下两者一些区别：
| 网关 | Spring Cloud Gateway | Spring Cloud Zuul 2 |
|---|---|---|
| 易用性 | 简单易用 | 参考资料较少 |
| 可维护性 | Spring 系列可扩展强，易配置可维护性好 | 可维护性差 |
| 成熟度 | Spring 社区成熟，但 Gateway 资源较少 | 开源不久，资料少 |
两者相比之下，Spring Cloud Gateway 更具有接入的优势。所以我们最终选择了 Spring Cloud Gateway 作为基础框架
三、落地实现
在前面介绍到我们需要 Monet 来完成统一 API 入口与管理、统一鉴权、统一流控与统一监控。接下来一一介绍实现。
统一 API 入口与管理
统一 API 入口
统一 API 入口比较简单，我们只需要将一个域名解析到 Monet，Monet 基于 Spring Cloud Gateway 实现，可通过路由配置即可实现将请求转发到相应服务。这里讲述一下我们实现过程遇到的问题，首先 Spring Cloud Gateway 的路由配置有两种：项目配置文件和基于代码路由配置
以上两种都有个弊端，那就是一旦路由配置有变更，都需要将 Monet 服务重启，在实际生产环境中不太可取。
在查询了一些资料发现，可以通过 RouteDefinitionRepository 接口实现获取路由配置信息，我们可以实现从数据库中获取路由配置信息，当我们变更了路由配置之后，触发 Spring Cloud Gateway 路由配置重载事件，就可以让 Monet 获取到最新的路由配置从而达到动态路由的效果，所以我们可以扩展为以下流程：
统一 API 管理
为什么要做 API 管理呢？API 管理主要为了避免 API 重复建设与 API 安全。
Monet 如何识别请求 URI 是属于哪个 API 呢？要知道在 Restful API 中 URI 目录中是带有参数的，给 Monet 识别是哪个 API 带来一定难度，但不是不可解。
可以利用 前缀树 数据结构来 API 解析与匹配，前缀树又叫单词查找树，典型应用于统计、排序等等，利用字符串的公共前缀来减少查询时间，最大限度地减少不必要的字符串比较，从而提高匹配的速度。将 API URI 部分拆分字符串后的树结构示意图：
我们通过实现 Spring Cloud Gateway 的 GlobalFilter 实现 API 解析与监管，通过后端服务导出 API 信息导入到网关控制台（利用 Zookeeper 存储 API 信息），API 解析过滤器也是从 Zookeeper 获取API 信息并缓存，如果找不到匹配 API 只能响应 404，能匹配上 API 的将解析出来的结果放到上下文中，方便后面的过滤器得到 API 信息进行下一步操作，例如权限校验等等；
同时我们也会在网关控制台建立审核制度，得需要项目负责人审核后方可将 API 上线。
统一鉴权
统一鉴权也分为两部分：用户认证与权限校验。
用户认证
为了让后端服务无需关注登录流程，用户登录认证的过程只需要在 Monet 完成，与 API 解析过滤器一样，用户认证也是通过 GlobalFilter 实现形成 Monet 的过滤器，用户认证完了之后每个请求都能读取到用户的相关信息并且放入到上下文中，便于后面的过滤器或者后端服务获取到。如图所示：
权限校验
为了能够让后端服务将权限集中管理，特地形成了一套权限体系，并且专门由一个服务负责，并且根据后端服务需求在权限服务上进行自定义即可形成各个服务权限，权限服务就不在此过多讲述。由于前面 API 解析已经能够得到 API 信息与用户认证得到的用户信息，我们就可以对当前用户进行权限校验了。
统一流控
由于现在的限流与熔断组件都非常成熟了，我们直接在 Spring Cloud Gateway 所支持的限流与熔断的组件进行选型，支持限流熔断组件有：Hystrix 与 Sentinel，两个组件区别：
| 功能 | Sentinel | Hystrix |
|---|---|---|
| 成熟度 | 社区活跃，文档较全 | 已经停止维护 |
| 熔断降级策略 | 基于响应时间、异常比率、异常数 | 基于异常比率 |
| 实时统计实现 | 滑动窗口 | 滑动窗口 |
| 动态规则配置 | 支持多种数据源 | 支持多种数据源 |
| 扩展性 | 多个扩展点 | 插件形式 |
| 限流 | 基于 QPS，支持基于调用关系的限流 | 优先支持 |
| 流量整形 | 支持预热模式、匀速器模式、预热排队模式（流量规则可配置） | 不支持 |
| 系统自适应保护 | 支持 | 不支持 |
根据以上功能区别我们最终选择 Sentinel ，Sentinel 功能丰富同时我们可将相关限流与熔断的配置规则放进 Zookeeper 便于我们在网关控制台上进行配置，通过 Sentinel 可以对用户、IP、或者 API 级别进行限流或者熔断降级能力。
统一监控
API 的监控也是比较简单，也是通过实现 GlobalFilter 并且在 API 解析之后，拿到 API 信息并记录请求信息上报，例如：API 请求时间、响应耗时等数据。在此处为了能够适配各种监控系统，在此处定义了一套监控接口，只需要实现该接口即可实现不同监控系统，例如：内部版本接入京东内部监控系统，对应的就是独立一个实现；同时可根据监控接口对接另外一套监控平台，更具有扩展性。
以上就是完整的 Monet 架构。
四、总结
我们先通过介绍目前架构的痛点讲述项目背景及技术选型，基于 Spring Cloud Gateway 落地实现 Monet 中的 统一入口与 API 管理、统一鉴权、统一流控、统一监控。虽然完成了以上功能，但是其实还有很多需要扩展的地方，例如：API 管理的审核流程、接入非 Java 服务、Access 日志等等。