有赞网关核心设计

一、API网关简介

随着移动互联网的兴起、开放合作思维的盛行&＃xff0c;不同终端和第三方开发者都需要大量的接入企业核心业务能力&＃xff0c;此时各业务系统将会面临同一系列的问题&＃xff0c;例如&＃xff1a;如何让调用方快速接入、如何让业务方安全地对外开放能力&＃xff0c;如何应对和控制业务洪峰调用等等。于是就诞生了一个隔离企业内部业务系统和外部系统调用的屏障 - API网关&＃xff0c;它负责在上层抽象出各业务系统需要的通用功能&＃xff0c;例如&＃xff1a;鉴权、限流、ACL、降级等。另外随着近年来微服务的流行&＃xff0c;API网关已经成为一个微服务架构中的标配组件。

二、有赞API网关简介

有赞API网关目前承载着微商城、零售、微小店、餐饮、美业、AppSDK、部分PC、三方开发者等多个业务的调用&＃xff0c;每天有着亿级别的流量。

有赞后端服务最开始是由PHP搭建&＃xff0c;随着整个技术体系的升级&＃xff0c;后面逐步从PHP迁移到Java体系。在API网关设计之初主要支持Dubbo、Http两种协议。迁移过程中&＃xff0c;我们发现部分服务需要通过RPC方式调用PHP服务&＃xff0c;于是我们(公司)基于Dubbo开发了一个新的框架Nova&＃xff0c;兼容Dubbo调用&＃xff0c;同时支持调用PHP服务。于是网关也支持了新的Nova协议&＃xff0c;这样就有Dubbo、Http、Nova三种协议。

随着业务的不断发展&＃xff0c;业务服务化速度加快&＃xff0c;网关面临各类新的需求。例如回调类型的API接入&＃xff0c;这种API不需要鉴权&＃xff0c;只需要一个限流服务&＃xff0c;路由到后端服务即可&＃xff1b;另外还有参数、返回值的转换需求也不断到来&＃xff0c;这期间我们快速迭代满足新的需求。而在这个过程中我们也走了很多弯路&＃xff0c;例如API的规范&＃xff0c;在最开始规范意识比较笼统&＃xff0c;导致返回值在对外暴露时出现了不统一的情况&＃xff0c;后续做SDK自动化的时候比较棘手&＃xff0c;经过不断的约束开发者&＃xff0c;最终做到了统一。

三、架构与设计

1. 网关架构

部署架构图

网关的调用方主要包括微商城、微小店、零售等App应用&＃xff0c;以及三方开发者和部分PC业务。通过LVS做负载均衡&＃xff0c;后端Tengine实现反向代理&＃xff0c;网关应用调用到实际的业务集群

应用架构图

网关核心由Pipe链构成&＃xff0c;每个Pipe负责一块功能&＃xff0c;同时使用缓存、异步等特性提升并发及性能

线程模型图

网关采用Jetty部署&＃xff0c;调用采用Http协议&＃xff0c;请求由容器线程池处理(容器开启了Servlet3.0异步&＃xff0c;提升了较大的吞吐量)&＃xff0c;之后分发到应用线程池异步处理。应用线程池在设计之初考虑不同的任务执行可能会出现耗时不一的情况&＃xff0c;所以将任务分别拆分到不同的线程池&＃xff0c;以提高不同类型任务的并发度&＃xff0c;如图分为CommonGroup, ExecutionGroup, ResultGroup

CommonGroup执行通用任务&＃xff0c;ExecutionGroup执行多协议路由及调用任务&＃xff0c;ResultGroup执行结果处理任务(包含异常)

网关业务生态图

网关生态主要包含控制台、网关核心、网关统计与监控
控制台主要对API生命周期进行管理&＃xff0c;以及ACL、流量管控等功能&＃xff1b;
网关核心主要处理API调用&＃xff0c;包含鉴权、限流、路由、协议转换等功能&＃xff1b;
统计与监控模块主要完成API调用的统计以及对店铺、三方的一些报表统计&＃xff0c;同时提供监控功能和报警功能

2. 网关核心设计

2.1 异步

我们使用Jetty容器来部署应用&＃xff0c;并开启Servlet3.0的异步特性&＃xff0c;由于网关业务本身就是调用大量业务接口&＃xff0c;因此IO操作会比较频繁&＃xff0c;使用该特性能较大提升网关整体并发能力及吞吐量。另外我们在内部处理开启多组线程池进行异步处理&＃xff0c;以异步回调的方式通知任务完成&＃xff0c;进一步提升并发量

2.2 二级缓存

为了进一步提升网关的性能&＃xff0c;我们增加了一层分布式缓存&＃xff08;借用Codis实现&＃xff09;&＃xff0c;将一些不经常变更的API元数据缓存下来&＃xff0c;这样不仅减少了应用和DB的交互次数&＃xff0c;还加快了读取效率。我们同时考虑到Codis在极端情况下存在不稳定因素&＃xff0c;因此我们在本地再次做了本地缓存&＃xff0c;这样的读取可以从ms级别降低到ns级别。为了实现多台机器的本地缓存一致性&＃xff0c;我们使用了ZK监听节点变化来更新各机器本地缓存

2.3 链式处理

在设计网关的时候&＃xff0c;我们采用责任链模式来实现网关的核心处理流程&＃xff0c;将每个处理逻辑看成一个Pipe&＃xff0c;每个Pipe按照预先设定的顺序先后执行&＃xff0c;与开源的Zuul 1.x类似&＃xff0c;我们也采用了PRPE模式(Pre、Routing、Post、Error)&＃xff0c;在我们这里Pre分为PrePipe、RateLimitPipe、AuthPipe、AclPipe、FlowSepPipe&＃xff0c;这些Pipe对数据进行预处理、限流、鉴权、访问控制、分流&＃xff0c;并将过滤后的Context向下传递&＃xff1b;Routing分为DubboPipe、HttpPipe&＃xff0c;这些Pipe分别处理Dubbo协议、Http协议路由及调用&＃xff1b;Post为ResultPipe&＃xff0c;处理正常返回值以及统计打点&＃xff0c;Error为ErrorPipe&＃xff0c;处理异常场景

2.4 线程池隔离

Jetty容器线程池(QTP)负责接收Http请求&＃xff0c;之后交由应用线程池CommonGroup&＃xff0c;ExecutionGroup, ResultGroup&＃xff0c;通用的操作将会被放到CommonGroup线程池执行&＃xff0c;执行真实调用的被放到ExecutionGroup&＃xff0c;结果处理放到ResultGroup。这样部分Pipe之间线程隔离&＃xff0c;通常前置Pipe处理都比较快&＃xff0c;所以共享线程池即可&＃xff0c;真实调用通常比较耗时&＃xff0c;因此我们放到独立的线程池&＃xff0c;同时结果处理也存在一些运算&＃xff0c;因此也放到独立线程池

2.5 平滑限流

最早我们采用了简单的分布式缓存&＃xff08;Codis&＃xff09;计数实现限流&＃xff0c;以IP、API维度构建Key进行累加&＃xff0c;这种限流方式实现简单&＃xff0c;但是不能做到连续时间段内平滑限流。例如针对某个API每分钟限流100次&＃xff0c;第1秒发起20次&＃xff0c;第二秒发起30次&＃xff0c;第3秒发起40次&＃xff0c;这样的限流波动比较大&＃xff0c;因此我们决定将其改进。经过调研我们最终选择了令牌桶限流&＃xff0c;令牌桶限流相比于漏桶限流能适应闲置较长时段后的尖峰调用&＃xff0c;同时消除了简单计数器限流带来的短时间内流量不均的问题。目前网关支持IP、店铺、API、应用ID和三方ID等多个维度的限流&＃xff0c;也支持各维度的自由组合限流&＃xff0c;可以很容易扩展出新的维度

2.6 熔断降级

由于我们经常遇到调用后端接口超时&＃xff0c;或者异常的情况&＃xff0c;后端服务无法立即恢复&＃xff0c;这种情况下再将请求发到后端已没有意义。于是我们使用Hystrix进行熔断降级处理。Hystrix支持线程池和信号量2种模式的隔离方案&＃xff0c;网关的业务场景是多API和API分组&＃xff0c;每个API都可能路由到不同后端服务&＃xff0c;如果我们对API或者API分组做线程池隔离&＃xff0c;就会产生大量的线程&＃xff0c;所以我们选择了信号量做隔离。我们为每个API提供一个降级配置&＃xff0c;用户可以选择自己配置的API在达到多少错误率时进行熔断降级。
引入Hystrix后&＃xff0c;Hystrix会对每个API做统计&＃xff0c;包括总量、正确率、QPS等指标&＃xff0c;同时会产生大量事件&＃xff0c;当API很多的时候&＃xff0c;这些指标和事件会占用大量内存&＃xff0c;导致更加频繁的YoungGC&＃xff0c;这对应用性能产生了一定的影响&＃xff0c;不过整体的收益还是不错的

另外有赞内部也开发了一个基于Hystrix的服务熔断平台&＃xff08;Tesla&＃xff09;&＃xff0c;平台在可视化、易用性、扩展性上面均有较大程度的提升&＃xff1b;后续网关会考虑熔断模块的实现基于服务熔断平台&＃xff0c;以提供更好的服务

2.7 分流

有赞内部存在多种协议类型的后端服务&＃xff0c;最原始的服务是PHP开发&＃xff0c;后面逐渐迁移到Java&＃xff0c;很早一部分API是由PHP暴露的&＃xff0c;后续为了能做灰度迁移到Java&＃xff0c;我们做了分流&＃xff0c;将老的PHP接口的流量按照一定的比例分发到新的Java接口上

3. 控制台

除了核心功能的调用外&＃xff0c;网关还需要支持内部用户(下称业务方)快速配置接口暴露给开发者。 控制台主要职责包括&＃xff1a;快速配置API、一站式测试API、一键发布API&＃xff0c;自动化文档生成&＃xff0c;自动化SDK生成

• 快速配置API&＃xff1a;这块我们主要是按照对外、对内来进行配置&＃xff0c;业务方将自己要对外公开的名称、参数编辑好&＃xff0c;再通过对内映射将对外参数映射到内部服务的接口里面

• 一站式测试API&＃xff1a;API配置完成后&＃xff0c;为了能让业务方快速测试&＃xff0c;我们做了一站式获取鉴权值&＃xff0c;参数值自动保存&＃xff0c;做到一站式测试

• 一键发布API&＃xff1a;在完成配置和测试后&＃xff0c;API就可以直接发布&＃xff0c;这个时候选择对应环境的注册中心或者服务域名即可

• 自动化文档生成&＃xff1a;我们针对文档这块做了文档中心&＃xff0c;对内部用户&＃xff0c;他们只需要到平台来搜索即可&＃xff0c;对外部用户&＃xff0c;可以在有赞云官网查看或者在控制台直接导出pdf文件给用户

• 自动化SDK生成&＃xff1a;对于开发者来说&＃xff0c;接入一个平台必然少不了SDK&＃xff0c;我们针对多语言做了自动化SDK生成&＃xff0c;当用户的接口发布成功后&＃xff0c;我们会监听到有新的接口&＃xff0c;这时会触发自动编译(Java)SDK的模块&＃xff0c;将新接口打包成新版本的压缩包&＃xff0c;供开发者使用&＃xff1b;如果编译失败(Java)则不会替换老的压缩包&＃xff0c;我们会发送报警给相应的开发者&＃xff0c;让其调整不规范的地方

4. 数据统计

为了让业务方能在上线后了解自己的接口的运行状况&＃xff0c;我们做了API相关的统计。我们通过在核心模块里面打日志&＃xff0c;利用rsyslog采集数据到Kafka&＃xff0c;然后从Kafka消费进行统计&＃xff0c;之后回流到数据库供在线查询

除此之外&＃xff0c;我们为每个商家做了他们授权的服务商调用接口的统计。这块功能的实现&＃xff0c;我们通过Storm从Kafka实时消费&＃xff0c;并实时统计落HBase&＃xff0c;每天凌晨将前一天的数据同步到Hive进行统计并回流到数据库

5. 报警监控

业务方API上线后&＃xff0c;除了查看统计外&＃xff0c;当API出问题时&＃xff0c;还需要及时发现。我们针对这块做了API报警功能。用户在平台配置自己的API的报警&＃xff0c;这里我们主要支持基于错误数或RT维度的报警。
我们实时地从Kafka消费API调用日志&＃xff0c;如果发现某个API的RT或者错误次数超过配置的报警阈值&＃xff0c;则会立即触发报警

四、实践总结

1. 规范

在网关上暴露的API很多&＃xff0c;如何让这些API按照统一的标准对外暴露&＃xff0c;让开发者能够低门槛快速接入是网关需要思考的问题

网关规范主要是对API的命名、入参&＃xff08;公用入参、业务入参&＃xff09;、内部服务返回值、错误码&＃xff08;公用错误码、业务错误码&＃xff09;、出参&＃xff08;公用出参、业务出参&＃xff09;&＃xff0c;进行规范

在我们的实践过程中&＃xff0c;总结了以下规范&＃xff1a;

• 命名规范&＃xff1a;youzan.[业务线(可选)].[应用名].[动作].[版本]&＃xff0c;例如&＃xff1a;youzan.item.create.3.0.0
• 入参规范&＃xff1a;要求全部小写&＃xff0c;组合单词以下划线分隔&＃xff0c;例如&＃xff1a;title, item_id&＃xff1b;入参如果是一个结构体&＃xff0c;要求以json字符串传入&＃xff0c;并且json中的key必须小写并且以下划线分隔
• 出参规范&＃xff1a;要求全部小写&＃xff0c;组合单词以下划线分隔&＃xff0c;例如&＃xff1a;page_num, total_count&＃xff1b;如果参数为结构体&＃xff0c;结构体里面的key必须小写且以下划线分隔
• 错误码规范&＃xff1a;我们做了统一的错误码&＃xff0c;例如系统级错误码51xxx&＃xff0c;业务错误码50000&＃xff0c;详情信息由msg显示&＃xff1b;业务级错误码由业务方自行定义&＃xff0c;同时约束每个业务方的错误码范围
• 服务返回值规范&＃xff1a;针对不同的业务方&＃xff0c;每个API可能会有不同的业务错误&＃xff0c;我们需要将这部分业务级错误展示给开发者&＃xff0c;因此我们约定返回值需要按照一个POJO类型(包含code, msg, data)来返回&＃xff0c;对于code为200&＃xff0c;我们认为正常返回&＃xff0c;否则认为是业务错误&＃xff0c;将返回值包装为错误结果

2. 发布

• 我们将API划分到3个环境&＃xff0c;分别为测试环境、预发环境、生产环境。API的创建、编辑必须在测试环境进行&＃xff0c;测试完成后&＃xff0c;可以将API发布到预发环境&＃xff0c;之后再从预发环境发布到生产环境&＃xff0c;这样可以保持三个环境的API数据一致。好处是&＃xff1a;一方面可以让测试开发能在测试环境进行自动化验证&＃xff0c;另一方面可以防止用户直接编辑线上接口引发故障

3. 工具化

• 对于内部用户经常可能需要排查问题&＃xff0c;例如OAuth Token里面带的参数&＃xff0c;需要经常查询&＃xff0c;我们提供工具化的控制台&＃xff0c;能让用户方便查询&＃xff0c;从而减少答疑量
• 我们上线后也曾经出现过缓存不一致的情况&＃xff0c;为了能快速排查问题&＃xff0c;我们做了缓存管理工具&＃xff0c;能在图形化界面上查看本地缓存以及Codis的缓存&＃xff0c;可以进行对比找出差异
• 为了更好的排查线上问题&＃xff0c;我们接入了有赞对比引擎&＃xff08;Replay&＃xff09;平台&＃xff0c;该平台能将线上的流量引到预发&＃xff0c;帮助开发者更快定位问题

五、踩过的坑

• Meta区Full GC导致服务无法响应

  现象&＃xff1a;应用hung死&＃xff0c;调用接口返回503&＃xff0c;无法服务

  排查过程&＃xff1a;现场dump了内存&＃xff0c;GC记录&＃xff0c;以及线程运行快照。首先看了GC发现是Full GC&＃xff0c;但是不清楚是哪里发生的&＃xff0c;看线程运行快照也没发现什么问题。于是在本地用HeapAnalysis分析&＃xff0c;堆区没看出什么问题&＃xff0c;大对象都是应该占用的&＃xff1b;于是查看方法区&＃xff0c;通过ClassLoader Analysis发现Fastjson相关的类较多&＃xff0c;因此怀疑是class泄露&＃xff0c;进一步通过MAT的OQL语法分析&＃xff0c;发现是Fastjson在序列化Jetty容器的HttpServletRequest时&＃xff0c;为了加快速度于是创建新的类时抛了异常&＃xff0c;导致动态创建的类在方法区堆积从而引发Full GC&＃xff0c;后续我们也向Fastjson提了相关bug

  解决方案&＃xff1a;将序列化HttpServletRequest的代码移除

• 伪死循环导致CPU 100%

  现象&＃xff1a;在有赞双11全链路压测期间&＃xff0c;某个业务调用API&＃xff0c;导致我们的应用CPU几乎接近100%

  排查过程&＃xff1a;经过日志分析&＃xff0c;发现该接口存在大量超时&＃xff0c;但是从代码没看出特别有问题的地方。于是我们将接口在QA环境模拟调用&＃xff0c;用VisualVM连上去&＃xff0c;通过抽样器抽样CPU&＃xff0c;发现某个方法消耗CPU较高&＃xff0c;因此我们迅速定位到源码&＃xff0c;发现这段代码主要是执行轮询任务是否完成&＃xff0c;如果完成则调用完成回调&＃xff0c;如果未完成继续放到队列。再结合之前的环境观察发现大量超时的任务被放到队列&＃xff0c;导致任务被取出后&＃xff0c;任务仍然是未完成状态&＃xff0c;这样会将任务放回队列&＃xff0c;这样其实构成了一个死循环

  解决方案&＃xff1a;将主动轮询改为异步通知&＃xff0c;我们这里是Dubbo调用&＃xff0c;Dubbo调用返回的Future实际是一个FutureAdapter&＃xff0c;可以获取到里面的ResponseFuture(DefaultFuture)&＃xff0c;这个类型的Future支持设置Callback&＃xff0c;任务完成时会通知到设置的回调

六、未来展望

1. 业务级资源组隔离。随着业务的不断发展&＃xff0c;当业务线较多时&＃xff0c;可以将重要的业务分配到更优质的资源组(例如&＃xff1a;机器性能、线程池的大小)&＃xff0c;将一般业务放到普通资源组&＃xff0c;这样可以更好的服务不同的业务场景
2. 更高并发的线程池/IO的优化。随着业务的发展&＃xff0c;未来可能会出现更高的并发&＃xff0c;需要更精良的线程及IO模型
3. 更多的协议支持。以后技术的发展&＃xff0c;Http2可能会蓬勃发展&＃xff0c;这时需要接入Http2的协议

七、结语

有赞网关目前归属有赞共享技术-基础服务中心团队开发和维护&＃xff1b;
该团队目前主要分为商品中心、库存中心、物流中心、消息沟通平台、云生态5个小组&＃xff1b;
商品/库存/物流中心&＃xff1a;通过不断抽象上层业务&＃xff0c;完成通用的模型建设&＃xff1b;为上层业务方提供高可用的服务&＃xff0c;并快速响应多变的业务需求&＃xff1b;针对秒杀、洪峰调用、及上层业务多变等需求&＃xff0c;三个小组还齐力开发和持续完善着 对比引擎、服务熔断、热点探测等三个通用系统&＃xff1b;
消息沟通平台&＃xff1a;提供几乎一切消息沟通相关的能力及一套帮助商家与用户联系的多客服系统&＃xff0c;每天承载着上亿次调用&＃xff08;短信、apppush、语音、微信、微博、多客服、邮件等通道&＃xff09;&＃xff1b;
云生态&＃xff1a;承担着核心网关的建设和发展&＃xff08;上面的网关应用系统&＃xff09;、三方推送系统、有赞云后台、商业化订购以及App Engine的预研和开发&＃xff1b;