一、背景介绍
羚珑作为一款智能设计平台，简略易懂、可视化操作，同时领有大量模板与素材为用户、商家或业务团队节俭了大量作图工夫从而达到降本增效。
随着应用的用户越来越多，同时业务也一直在增长，这也给羚珑服务端带来了挑战。
羚珑服务端目前架构如图所示由多个平台组成，每个平台都有本人的域名。随着业务增长每次都是启动一个平台来扩大性能，这种模式弊病也显现出来了。
对于后端同学来说，新建一个平台须要对接登录与权限；提供的 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 局部拆分字符串后的树结构示意图：
<img src=”https://storage.360buyimg.com/neos-static-files/4d4b53db-d989-48e9-8de0-ad075c7bb313.png” title=”” alt=”” width=”306″>
咱们通过实现 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 日志等等。