vlambda博客
学习文章列表

1.1 流量网关与业务网关

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

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

2.1 流量网关

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

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

2.2 业务网关

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进行路由的方案见下图。如下图所示：

3.2 部署说明

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

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

• K8S：由于每个module运行的实例根据K8S进行伸缩，因此module的运行实例由K8S负责；

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

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

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

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

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

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

3.3 监控

关于对流量网关的监控，方案如下：

如上图所示：

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

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

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

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

  
  

上述的流量网关部署方案，线上环境曾经有使用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 流量网关的安全控制

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

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

• 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。

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