一、背景介绍
羚珑作为一款智能设计平台,简单易懂、可视化操作,同时拥有大量模板与素材为用户、商家或业务团队节省了大量作图时间从而达到降本增效。
随着使用的用户越来越多,同时业务也不断在增长,这也给羚珑服务端带来了挑战。
羚珑服务端目前架构如图所示由多个平台组成,每个平台都有自己的域名。随着业务增长每次都是启动一个平台来扩展功能,这种模式弊端也显现出来了。
对于后端同学来说,新建一个平台需要对接登录与权限;提供的 API 功能没有集中管理,不清楚正在开发的 API 是否有重复提供;开发的 API 在某些业务场景下还需要自行限流或降级;缺少全局 API 监控。
对于运维同学来说,要为后端同学开发完成的每个平台新建域名映射(同时还需要申请证书)。
对于前端同学来说,为了复用某些 API 功能还需要对接多个域名,同时还区分测试与生产环境域名,这就导致前端同学在项目中还需要维护一批域名。
根据以上场景,我们可以总结为,缺少 API 的统一入口与管理(统一域名)、统一鉴权、统一流控、统一监控。
如何解决以上架构痛点?我们需要一个服务承载在业务平台之上接收前端的请求,转发到相应的后端平台上,还可以对每个请求进行用户认证与权限校验,还可以对 API 精准限流与降级,同时对 API 请求响应异常进行监控上报。
这个服务就呼之欲出:API 网关,并取名为:Monet。下面我将介绍下这个网关中间件服务。
二、技术选型
确定了 Monet 需求之后,我们就开始进行技术选型。
基础框架选择
牛顿说过,如果说我别人看得更远些,那是因为我站在了巨人的肩膀上。所以我们需要站在巨人的肩膀才可以看得更远。那么 Monet 也一样,需要选取一款网关的