API网关在网龙教育业务中的实践

Posted 网龙开发者团队

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了API网关在网龙教育业务中的实践相关的知识,希望对你有一定的参考价值。

01


API网关介绍




在微服务架构中,由于系统和服务的细分,导致系统结构变得非常复杂,为了跨平台、统一集中管理API,以及不暴露后置服务,进而对请求进行安全、负载均衡、限流、熔断、灰度等操作,一个类似综合前置的系统就产生了,这就是API网关(API Gateway)。


API网关作为分散在各业务系统中的API聚合点和统一接入点,所有的外部请求都需要通过这个接入点,才可访问内部服务。

1.1 流量网关与业务网关


对于API网关,根据网关的部署位置以及功能定位,可以分为:

  • 流量网关:全局性的,跟具体的后端业务系统和服务完全无关的部分,处理安全策略、全局性流控策略、流量分发策略等;
  • 业务网关:针对具体的后端业务系统,或者是服务和业务有一定关联性,一般被直接部署在业务服务的前面;

流量网关与业务网关区别与联系,如下图所示:


02

API网关的选型



在网龙教育业务中,网关的部署如下:

API网关在网龙教育业务中的实践



  • 流量网关做为API统一的外部入口;
  • 业务网关做为业务对外的接口;


2.1 流量网关


针对流量网关,早期我们采用的是:nginx。然而nginx不支持热加载技术,导致每次修改路由规则后,都要使用ng-reload重启一下nginx。

随着业务的发展,当路由配置数量超过1W条后,逐渐发现:

  • nginx重启的时间比较长,往往大于100ms;
  • 频繁的ng reload会产生莫名奇妙的502的异常;

随之而来,就需要重新选择一个支持热加载、方便二次开发的API网关。支持热加载的API网关,有很多,如:Tengine、OpenResty等,其对比如下:

  • Tengine、OpenResty都是基于Nginx的衍生版本、Kong则是OpenResty的衍生版本;
  • Tengine是阿里的开源项目,OpenResty是前阿里员工agentzh主导开发的,Kong则由Kong公司维护;
  • OpenResty引入ngx lua模块,支持lua开发插件;Tengine融入了淘宝的业务场景;Kong则为关注于流量网关能力,二次开发能力更加友好;

考虑到社区的支持、二次开发的便利性,最终确认使用Kong。

注:这边主要考虑的是nginx系列的网关,方便升级。

2.2 业务网关


由于业务网关,往往都需要业务部门进行定制化开发,因此业务网关选择范围比较简单。

考虑到大家都是Java的开发人员,因此选择Spring Cloud套餐,早期选择Zuul、现在逐渐选用Spring Cloud Gateway。

注:其实Zuul、Spring Cloud Gateway两者的性能都差不多,Netflix新版本不准备开源了,因此就转向了Spring Cloud Gateway。

03

流量网关的落地方案



3.1 路由管理:统一域名方案


在网龙教育业务中,对于流量网关的需求场景如下:


以网教通产品为例,该产品由直播、课程、资源、新闻等基本模块,同时需要为每个学校开通一个社区。那么期望:


  • http://www.hbeducloud.com/:用于访问首页;

  • http://www.hbeducloud.com/news:用于访问新闻;

  • http://shishou.hbeducloud.com/news:用于访问石首社区新闻;


如上的路由管理需求,即网龙教育业务采用的统一域名方案。在一次请求中的URL中:


  • 域名:用于表示租户,如上述中的www.hbeducloud.com、shishou.hbeducloud.com;

  • 资源路径的第一段,我们也把这段叫module,用于表示访问的服务,如上述中的news;


具体来说,统一域名方案,在对于一次请求中,不根据域名进行域名,而是根据请求中的module进行路由的方案见下图。如下图所示:


API网关在网龙教育业务中的实践


3.2 部署说明


目前网龙的基础设施,已经逐渐向K8S转移。那么,对于流量网关的控制分为两个部分:


  • 开发者门户:网龙自研的DevOps平台,负责创建Web服务,定义module;

  • K8S:由于每个module运行的实例根据K8S进行伸缩,因此module的运行实例由K8S负责;


基于上述构架,网龙教育业务中,流量网关的部署逻辑如下:


API网关在网龙教育业务中的实践


如上图所示的部署方案中:


  • 流量网关管理台:全局部署一份,对上游负责对外的业务需求,对接开发者门户、K8S;

  • 流量网关代理:流量网关的管理指令通过相关环境的流量网关代理,对KONG进行指令操作。该方案的好处可以允分的保证KONG的管理接口中的安全性。

  • K8S:编写新的K8S的ingress,实现K8S中的实例变更,通知API网关管理台,从而实现对KONG路由控制;

  • 开发者门户:开发者在这边定义服务、以及相关的module;


3.3 监控


关于对流量网关的监控,方案如下:


API网关在网龙教育业务中的实践


如上图所示:


  • 在流量网关的服务器上,部署Agent,做日志、系统状态等信息的采集代理,定时采集监控数据;

  • 通过Kafka,将日志、系统状态等信息发送至监控系统;

  • 监控系统中,ELK接收访问日志、Falcon接收系统状态数据,做准时时的数据分析,遇到异常情况及时告警;

  • 值的一提的是,ELK接收到的访问日志,可以分析出module的运行情况,如慢请求、请求时长、TPS等等有效数据;当然这主要是监控系统的职责,这里就不展开了。


04

流量网关的应用场景



上述的流量网关部署方案,线上环境曾经有使用6组12台设备支撑住超15万的每秒峰值流量的经历,当然此时所有设备几乎满载,后来为了业务稳定性扩容到12组24台设备。


流量网关在网龙的教育业务中,经历了业务稳定性考验,其主要使用场景如下:


4.1 路由


如常规的统一域名路由规则配置外,为保证业务的稳定性。还为业务配置定制化的路由规则,优化路由访问,部分的业务微服务化拆分不合理,导致单集群访问流量太高。在流量访问高峰峰,会采用人为介入,将特定的API时行分流量。


如:/uc/valid/、/uc/user/都指向同一服务集群,但/uc/valid/的流量是/uc/user/的10倍,在流量高峰期,会将/uc/valid/指定单独的集群以保证该请求不影响其它的业务。


4.2 限流


在流量高峰期,会对部分的流量进行限流管理。如:


  • 允许/uc/login,每秒只允许1000次请求。


当然在网龙的教育业务中,我们还开发一种基于租户化的限流方案,可以控制每个租户访问流量。


4.3 缓存


我们在API网关中开启Http级缓存,支持如下http缓存控制:


  • ETag/If-None-Match

  • max-age


4.4 流量网关的安全控制


也许有人要问,流量网关中安全控制方案是如何处理的。其实在网龙基础设施中,有业务的安全控制方案,该方案也会利用到流量网关的拦截、访问控制等能力,但这里就不展开该方案的内容了,后继有机会单独介绍。


05

 业务网关的实践



在网龙的教育业务中,对于业务网关的实践,其主要的场景还是在于:


  • API适配:这个比较简单,就是解决业务升级过程中,引起的API升级的问题。

  • 业务聚合:其主要目的是为了减小客户端和服务端的请求次数,而提出的在聚合网关中聚合多次请的方案。


下来开始详细介绍业务网关一些实践经验。


5.1 服务的注册机制


在网龙的教育业务中,并不直接使用类似于Spring Cloud Eureka之类的注册中心,主要原因在于:


  • 上文提到网龙有开发者门户,网龙教育业务中整体的服务的注册、发现分别由开发者门户、K8S完成,Spring Cloud Euraka之类的注册中心并不能满足这类的需求;

  • 服务注册中心能服务于整个API网关,即流量网关、业务网关、业务服务都能统一使用该数据;

  • 网龙的注册中心除了提供常规的服务信息外,还提供路由信息,为流量网关、业务网关提供基础路由规则;


因此在网龙的教育业务中,服务的注册机制如下:



  • ND服务注册中应用的数据,其中开发者门户提供应用信息、K8S提供应用的运行实例;

  • ND服务注册中应用的数据,为流量网关提供路由信息,为业务网关、业务服务提供PRC调用数据;


5.2 聚合网关


对于聚合网关的需求,除最基本的聚合多次请求外,还有可能在聚合的多次请求中,可能某个的请求中需要用到其它请求的结果。由于Spring Gateway这样的开源网关服务,并不支持聚合网关的需求,于是我们自研了一个聚合网关。对于聚合网关,理想的管道模型为:



  • 在聚合网关中,包含两个基本的处理模块:聚合请求处理模块、单一请求处理模块;

  • 聚合请求处理模块:将聚合请求异步化,并转成若干个单一请求;聚合请求处理模块中仅当每个单一的请求都处理完成后,才将所有的结果进行聚合,并返回数据;

  • 单一请求处理模块:这是一个请求异步化处理的机制,可以使用mina、netty这样的IO架构实现该机制;


幸运的是,当我们阅读Spring Gateway的源码时,我们发现其依赖的Spring WebFlux可以很方便的实现这么一种聚合网关的管道模型。Spring WebFlux基于Spring Reactor进行开发,响应式的编程框架,能很方便的实现异步化的开发方式,满足我们的需要。


基于Spring WebFlux开发的聚合网关,在实际的压测中,在聚合8个请求的场景下,TPS可以达到1500。



06

 写在最后



写到这里,已经基本上介绍API网关在网龙教育中的实践、总结,说明了流量网关的部署方案、业务网关的实践场景等内容。但基于篇幅等原因限制,实际操作过程中,我们还在KONG,以及Spring WebFlux的使用、性能优化积累了很多的经验,会在后继文章中单独介绍





以上是关于API网关在网龙教育业务中的实践的主要内容,如果未能解决你的问题,请参考以下文章

京东API网关实践之路

某司API网关实践之路

技术干货 | 漫谈API网关——API网关探索与实践

京东大型API网关实践之路

vivo亿级微服务 API 网关架构实践

API网关实践-网易云轻舟微服务