开发者社区> 晓风瑟瑟> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

基于网关服务治理的研究与实践(五)从开源网关到自研网关

简介: 在上一篇API网关介绍中,由于开源网关方案的不足,且目前没有能够同时兼容Http、Socket、WebSocket协议的开源网关,无法实现对业务请求的统一管控,对于服务治理整体方案略有不足;在当前背景下,产生了自研网关的想法,本篇文章详细记录了自研网关所做的技术研究内容。
+关注继续查看
福利推荐:阿里云、腾讯云、华为云等大品牌云产品全线2折优惠活动来袭,4核8G云服务器899元/3年,新老用户共享优惠,点击这里立即抢购>>>

5 从开源网关到自研网关

5.1 前言介绍

5.1.1 Socket

传统的HTTP协议,是基于TCP/IP的应用层协议,该协议被广泛应用于Web资源的获取。HTTP协议是一种基于请求/响应模式的协议,由客户端主动向服务器发送请求,拉取数据实现半双工通信。因此,在该协议下,服务器端难以直接向客户端推送消息。

Socket协议是一种在HTTP底层的TCP连接上建立一个全双工通信的协议。通过双向的通信连接,网络上的两个程序可以实现数据交换,通信连接的每一端都是一个Socket。一次连接多次使用,当客户端与服务器端建立连接后,并不会马上关闭连接,后续客户端发送请求以及服务器响应数据都使用该连接进行通信。

Socket协议依赖HTTP协议进行第一次握手,在客户端与服务端建立一个不受限的双向通信通道,客户端和服务端就可以在任意时刻发送消息给对方。握手成功后数据就直接从TCP通道传输,传输数据时与HTTP无关,图5.1Socket协议握手过程:

image.png

5.1 Socket协议握手过程图

5.1.2 Socket网关

Socket网关是介于Socket客户端、Socket服务端之间的服务器,与普通的Web网关服务器不同,Web网关服务器使用短连接,即客户端请求服务器,服务器响应完成后就会断开并释放连接;Socket网关服务器使用长连接。

Socket网关作为客户端与服务端的通信中介,主要提供认证鉴权、安全过滤、服务管理、消息路由、长连接管理、消息送达等功能。客户端发起建立Socket连接请求时,Socket网关统一对来自客户端的Socket接入请求进行身份认证与鉴权。Socket网关还能够对客户端消息进行消息路由,即通过路由算法将客户端消息转发至相应服务器。同时,还需要作为服务器的消息中转器,将服务器消息转发至与网关服务器连接的所有客户端。

Socket客户端与Socket网关服务、Socket网关服务与Socket服务端之间通过Socket协议进行通信,图5.2Socket网关模型图。

image.png

5.2 Socket网关模型图

5.2 技术选型

5.2.1 Netty选型

Socket实现方式有很多种方式,常见实现方式有:NettyJettyUndertowSpray等,针对常见实现方案对比如表1所示。其中Netty是一个高性能、事件驱动、异步非阻塞的网络通信框架,可以处理大量用户的并发请求,且能够快速搭建高性能、高可靠性的网络应用程序框架。通常Netty框架也可作为与设备保持长连接的通讯网关。

1 Socket实现方式对比

实现方式

优点

缺点

Netty

多协议,功能强大;定制能力强;性能高;安全可靠;成熟稳定;应用广泛

相对复杂,不易于调试

Jetty

支持高并发;资源使用率较低

依赖于Jetty容器;内存占用较大,会导致频繁垃圾回收;存在并发瓶颈

Undertow

支持高并发;性能高;资源使用率较低

依赖于Undertow容器;内存使用率相比Netty占用较大

Netty是目前业界最流行的NIO框架,鉴于其功能、性能、健壮性、可定制性和扩展性,现已得到成千上万商业项目的实践应用。Netty采用三层网络架构模式,从上到下依次为:Reactor调度层、PipeLine责任链层、Service业务逻辑层,能够共同提升数据接收的效率,Netty网络架构模式如图5.3所示:

image.png

5.3 Netty网络架构图

5.2.2 Spring Boot选型

Spring Boot是基于Spring4搭建的微框架,其宗旨是为了简化Java企业级应用开发。Spring Boot继承了Spring框架的核心特性及相关扩展功能,简化了对Spring已有技术的使用,无须繁杂配置即可快速构建应用程序。Spring Boot是开发单一服务框架的基础,Spring Cloud也建立于Spring Boot框架基础上,利用Spring Boot的开发便捷性简化了微服务基础设施的开发,提供了一套微服务开发工具包,用于增强基于Spring Boot创建的应用程序。

5.2.3 Rocket MQ选型

通常服务端会主动向客户端发送数据,使用WebSocket协议可以实时的完成服务端向客户端推送数据的操作。Socket网关与服务端之间的通信则通过消息队列机制来实现。图5.4Socket网关与客户端、服务端推送数据通信模型。

image.png

5.4 Socket网关推送数据通信模型

服务端与Socket网关之间选择轻量级的事件广播方案,Socket网关与服务端则基于消息队列的事件监听和处理。其中,实现广播可以选择基于RocketMQ的消息广播、基于Redis的发布/订阅、基于ZooKeeper的通知等方案,其优缺点如2常用事件广播方案比较所示。

2常用事件广播方案比较

?

优点

缺点

RocketMQ

吞吐量高、高可用、保证可靠

实时性不如Redis

Redis

实时性高、实现简单

不能保证消息可靠性

ZooKeeper

实现简单

写入性能较差,不适合频繁写入场景

5.2.4 小结

本方案采用基于Netty框架的WebSocket协议技术作为Socket网关的实现,其中技术选型特点如表3所示。

3技术选型

?

选型

特点

Socket网关

Netty(Spring Boot+Netty)

轻量,高并发,传输快,多路复用,异步非阻塞等

客户端通信

WebSocket

长连接,减少网络交互,减少连接次数,推送数据

服务间通信

HTTP REST、MQ

简单、可扩展,业务解耦

语言选择

JAVA

支持JAVA实现,与平台无关


5.3 方案选择

5.3.1 OpenResty

OpenResty 是一个基于 Nginx Lua 的高性能、可伸缩的 Web 平台,其内部集成了大量精良的 Lua 库、第三方模块以及大多数的依赖项。用于方便地搭建能够处理超高并发、扩展性极高的动态 Web 应用、Web 服务和动态网关。其中采用OpenResty开发的网关,使用较流行的有Apache ApisixKong等。

基于OpenResty 开发的优缺点及适用场景如下:

OpenResty具有高并发、热更新等特点。OpenResty提供了大量组件如MysqlRedisMemcached等,使其在Nginx上开发Web应用更方便更简单。同时,借助于Nginx的事件驱动模型和非阻塞IO,可以实现高性能的Web应用程序。OpenResty适用于处理准入控制和安全检查,请求限流等场景,比如:新浪微博采用OpenResty 构建了上行请求和下行推送的一站式应用网关,新浪新闻、微博广告、天气通也同时在使用OpenResty;京东的实时价格、秒杀、动态服务、单品页、列表页等都在使用Nginx+Lua架构;美团网内部的Oceanus也是基于Nginxngx-lua扩展实现的,主要提供服务注册与发现、动态负载均衡、可视化管理、定制化路由、安全反扒、Session ID复用、熔断降级、一键截流和性能统计等功能;其他公司如淘宝、去哪儿网等。

使用OpenResty作为Socket网关的不足之处:开发层面,需要Lua开发,定制化开发成本较高,可维护性较差,不便于程序调试;业务层面,不适用于处理复杂的业务逻辑,如单聊、群聊、广播、组播等复杂通信场景,及长时间阻塞调用的过程;技术人员层面,需要开发人员精通LuaLuaJIT,以及 Nginx等相关技术栈。

5.3.2 Spring Cloud Gateway

Spring Cloud GatewaySpring官方提供的基于Spring 5Spring Boot 2.0Project Reactor等核心技术开发的网关框架,其核心目标是为微服务架构的应用提供简单、有效和统一的API路由管理方案,还用于替代Netflix的网关组件Zuul。它可以在 Web 协议(如 HTTP WebSocket)与内部使用的非 Web 友好协议之间转换。

?

5.3.3 Netflix Zuul 2.x

ZuulNetflix开源的网关服务组件,是一个提供了微服务路由、负载均衡和过滤器解决方案的边缘服务框架,它的主要设计目标是动态路由、监控、弹性和安全。Zuul 1.x基于同步的I/O模型实现,但其不支持长连接;目前,多数大型互联网公司基于Zuul 1.x来实现API网关服务,比如携程(日流量超 50 亿)。Zuul2.xZuul1.x升级版本,基于Reactor模式,选择成熟的Netty 框架实现了异步非阻塞,引入了事件、总线、队列机制,事件环处理,并加入了对WebSocket的支持,但Spring尚未有引入计划,商业应用成熟度不高。

5.3.4 WebSocket实现框架

2.2节中介绍了Spring Boot选型的相关内容,其中实现WebSocket 的框架,比较主流的有NettySocketIOWebSocket容器三个框架,并对这三个框架从易用性、协议支持、性能、业务场景等方面进行比较,具体如表4所示:

4实现WebSocket的框架比较

?

WebSocket容器

Netty-SocketIO

Netty

易用性

简单

简单

中等

协议支持

WebSocket

WebSocket、Polling

多协议

代码开发量

少量

少量

较多

容器支持

需要

不需要

不需要

性能

一般

业务场景分析

适合用户连接数较少、业务不复杂的服务

适合用户连接较多及对性能有要求的服务

适合平台型服务;适合用户连接较多及对性能有要求的服务;

优势

可支持HTTP与WebSocket两种协议;与Spring结合非常方便

框架内部封装较好,拿来即用;多语言客户端支持

灵活性强;可定制化,二次开发;支持多种协议

劣势

强依赖容器性能

不支持HTTP协议

研发成本高,需要手写较多代码

1)基于支持WebSocket 的容器,开发简单,例如TomcatJettyUndertow;但在高并发方面表现较差,存在并发瓶颈,连接的时会出现断开情况,强于依赖容器,可扩展性差。

2Netty-SocketIO是基于Netty框架基础上的封装,效率同Netty 一样,是一个全平台方案,提供API支持。京东Logbook也是用了SocketIO 来传递日志。

3Netty 是业内主流的NIO框架,NettyJava NIO 做了封装,让开发者更多关注业务,降低开发成本。很多著名的 RPC 框架都采用了Netty作为传输层,功能非常强大,内置了很多编解码协议,实现WebSocket 协议十分方便。

Netty的高性能是基于Reactor模式的线程模型,Reactor模式采用IO多路复用结合线程池的设计思想,如图5.5 Reactor模型所示;而NettyReactor 线程模型的支持提供了灵活的定制能力,所以可以满足不同业务场景的性能诉求。

image.png

5.5 Reactor模型

5.3.5 综合比较

本章节对常见的Socket网关实现方案进行了详细调研,其中各方案优缺点综合比较如表5所示。

5常见的Socket网关方案比较

?

优点

缺点

OpenResty

超高并发、扩展性极高、热更新

不便于程序调试;不适用于处理复杂的业务逻辑;不支持JAVA

Spring Cloud Gateway

基于Reactor-Netty实现;支持高并发;支持长连接、WebSocket;线程开销少;

只能完成转发WebSocket请求,需要对应Socket服务端;无法管理长连接

Netflix Zuul 2.x

基于Netty实现异步非阻塞编程模型(APO);线程开销较小;连接数易扩展;支持WebSocket;支持Groovy,可动态更新filter(性能会有损耗)

开发调试运维复杂;编程模型复杂;高并发有出错概率较大;Spring Cloud不支持集成;商业化应用程度低;只能完成转发WebSocket请求,需要对应Socket服务端;无法管理长连接

Spring Boot + Netty

可扩展、可定制化二次开发;高性能;灵活性强;支持多种协议;稳定成熟;商业化应用广泛

需要自研,手写较多代码


5.4 技术实现方式

5.4.1 架构设计

根据第二、三章节的技术选型与方案对比,对不同的Socket应用场景均使用基于Netty框架技术构建Socket网关,具体可划分为Netty Socket网关和WebSocket路由网关,如图5.6所示。客户端发起的Socket请求由Socket网关负责统一接入,以加强系统安全性。

image.png

5.6 Socket网关架构设计

5.4.2 服务化拆分

5.4.2.1 基于Netty的Socket网关

基于NettySocket网关,其运行模式如图5.7所示,其主要职责如下:

1)负责建立及保持与客户端之间的长连接;

2)接收客户端发起请求,并对客户端请求进行解码处理;

3)处理高并发上下行通信,提供通信加解密、白名单过滤等基础能力;

4)能够支持消息队列、Restful接口为应用服务器提供数据推送通道,网关服务器接收应用服务器数据,并通过Socket通道推送给与网关服务器建立Socket连接且在线的客户端。

image.png

5.7 基于NettyWebSocket网关运行模式

5.4.2.2 Websocket路由网关

WebSocket路由网关,可采用Spring Cloud Gateway实现,其运行模式如图5.8所示,其主要职责如下:

1)接收客户端请求,并将客户端请求转发至目标Socket服务器;

2)保持长连接,并透传数据;

3)实现对Socket服务端的负载均衡

该模式适用于Socket客户端与Socket服务端通信,WebSocket网关完全起到中介作用,通过路由将数据透传给目标Socket服务端。

image.png

5.8 基于Spring Cloud GatewayWebSocket网关运行模式

5.4.3 功能模块

根据对Socket网关功能特性分析,将Socket网关整体功能划分模块如图5.9所示:

image.png

5.9 Socket网关整体功能模块

5.4.4 自定义通信协议

通信模块是Socket网关的核心,Socket网关采用基于TCP协议的长连接通信方式,而由于TCP数据传输是无边界的字节流传输形式,接收方接收到的数据流可能是半个数据包,也可能是多个数据包黏在一起,即TCP的黏包/拆包问题。为解决这个问题,需要网关层设计消息的边界,因此对于Socket网关架构中的通信协议采用自定义消息协议,以保证数据的完整性和安全性。消息协议主要包括协议头和消息体两个部分,如图5.10所示,数据的编码和解码均按此协议进行解析,具体每个字段解释如下:

image.png

5.10自定义消息协议格式

l? command8bit,指令编码,客户端请求服务端时,网关根据command寻址;

l? version2byte,版本号

l? security8bit,安全位,用于识别该协议是否加密

l? length4byte,消息内容长度

l? data:长度未知,消息内容,由length指定

5.5 关键功能设计

5.5.1双向心跳检测机制

心跳是指在TCP长连接中客户端和服务端定期的互相发送数据包;心跳检测机制是发送方(客户端或服务端)按照一定规则(周期性发送、空闲发送等)向接收方(客户端或服务端)发送固定格式的消息,接受方收到消息后回复一个固定格式的消息,如果长时间没有收到,比如心跳周期的3倍,则认为当前连接失效,并主动将其断开,如图5.11所示。

心跳检测通常用于判断长连接是否存活:当长连接没有流量时,无法判断是通信异常引起还是通信正常没有业务流量引起,通过发送心跳包进行判断。

image.png

5.11 心跳检测机制

5.5.2 拉取模式与推送模式

推送数据模式是由服务端通过Socket网关主动向客户端(在线)发送数据的过程,其推送方式可通过接口或消息队列实现;同时,还需要网关负责整合各类厂商消息通道,其运行流程如图5.12推送模式所示。

image.png

5.12 推送数据模式

拉取数据模式是由客户端主动发送指令,Socket网关根据指令匹配到对应的业务服务API,并使用HTTP短连接方式,请求目标业务服务获取数据的过程。其运行流程如图5.13拉取模式所示。

image.png

5.13 拉取数据模式

5.5.3 离线模式

离线模式是在推送模式基础上的扩展,业务服务通过接口或消息队列向客户端推送数据,当客户端不在线时,Socket网关将无法向客户端正常推送消息。为了确保消息能够安全地送达客户端,应由Socket网关结合离线消息处理机制,将消息进行暂存,在客户端重新上线时,采取拉取或再次推送的方式将数据推送到客户端。如图5.14离线数据模式。

image.png

5.14 离线数据模式

5.6 应用场景

5.6.1 消息推送/提醒

唯品会采用Netty作为底层通信协议设计了消息网关,以作为消息发送的总入口,对接上游各个业务系统,为业务系统提供友好的发送受理服务。其消息网关实现了基于优先级队列的消息分发,反馈统计,延时发送,订阅控制,以及其他一些辅助功能。

爱奇艺号是爱奇艺内容创作、分发和变现的平台,涵盖自媒体、网大、网剧、儿童、知识、纪录片等多个业务,是爱奇艺内容生态的重要组成。爱奇艺号作为前台系统,对用户体验有较高要求,直接影响着创作者的创作热情。目前,爱奇艺号有多个业务场景中用到了WebSocket推送技术,包括:

l? 用户评论。实时的将评论消息推送到浏览器。

l? 实名认证。合同签署前需要对用户进行实名认证,用户扫描二维码后进入第三方的认证页面,认证完成后异步通知浏览器认证的状态。

l? 活体识别。类似实名认证,当活体识别完成后,异步将结果通知浏览器。

目前WebSocket长连接网关已在爱奇艺号图片滤镜结果通知、MCN电子签章等多个业务场景中得到应用。

5.6.2 网页游戏

网页游戏通常需要游戏服务器主动推送消息客户端,例如广播消息;游戏服务器对即时性要求高,通常采用客户端与服务端Socket直连的架构模式。而直连架构具有一定的缺陷和不足,比如:安全方面,容易被第三方拦截抓包,造受外部恶意攻击;业务方面,区服之间无法相互通信,无法实现跨服战场等业务需求;客户端或服务端需要额外实现负载均衡器。

网关服务器的主要职责是将客户端和游戏服务器隔离,客户端程序直接与这些网关服务器通信,并不需要知道具体的游戏服务器内部架构,通过网关服务器转发数据包间接地与游戏服务器交互。同样,游戏服务器也不直接与客户端通信,发给客户端的协议都通过网关服务器进行转发。如图5.15 分区服游戏架构模型。

image.png

5.15 分区服游戏架构模型

5.6.3 物联网

Socket网关也被用于物联网,比如设备控制(扫码开锁或者扫码乘车),智能家居、城轨列车运行监测等。其中以北京地铁7号线的城轨列车地面在线监测与分析系统为例,其架构如图5.16所示,该系统负责接收、解析、存储城市轨道交通车辆的状态信息数据,在此基础上进行数据应用与分析。平台主要分为 4 个层级,包括数据接入层、数据缓冲层、数据解析层、数据存储层与数据应用层,其中数据接入层的功能主要由地面数据网关实现,网关负责接收和解析城轨列车传送的数据。

image.png

5.16地面在线监测与分析系统架构

5.6.4 即时通讯

在即时通讯架构中,网关承担着与异构即时通信系统的互联互通,网关接入层负责维护与客户端之间的长连接,它是唯一一个与客户端进行直接通信的服务入口。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
基于网关服务治理的研究与实践(六)服务编排
本文是基于网关服务治理的研究与实践系列的第六篇文章,从以上几篇文章中,介绍了网关服务治理相关内容,包括微服务架构、服务治理相关概念、服务治理技术框架、API网关技术及自研网关,服务编排也是以上架构技术基础上的进一步深入的研究,也是服务治理领域非常值得研究的内容。
0 0
基于网关服务治理的研究与实践(四)API网关技术
API网关旨在对外提供针对所有API调用的统一入口,实现对微服务接口的统一接入、请求转发。API网关建立与各微服务的路由访问关系映射,并将客户端的请求转发至对应的后端服务实例。
0 0
基于网关服务治理的研究与实践(二)服务治理
接上篇,本篇原创系列是对服务治理的相关背景说明,主要介绍了服务治理相关概念、技术及演进历程。
0 0
基于网关服务治理的研究与实践(七)未来展望
历经一个多月完成基于网关服务治理的研究与实践七篇文章系列,研究了与网关服务治理相关内容,包括微服务架构、服务治理相关概念、服务治理技术框架、API网关技术到自研网关,及服务编排等内容,本篇作一个阶段性总结。
0 0
下一代网关——云原生网关商业化发布 | 学习笔记
快速学习 下一代网关——云原生网关商业化发布
0 0
长连接网关技术专题(八):B站基于微服务的API网关从0到1的演进之路
也就是在这一年,B 站开始正式用 Go 重构 B 站,从此B站的API网关技术子开始了从0到1的持续演进。。。
0 0
阿里终面:如何设计一个高性能网关?
最近在github上看了soul网关的设计,突然就来了兴趣准备自己从零开始写一个高性能的网关。经过两周时间的开发,我的网关ship-gate核心功能基本都已完成,最大的缺陷就是前端功底太差没有管理后台?。
0 0
即构自研WebRTC网关服务器架构实践
即构为什么要自研WebRTC网关服务器?我们从开源和自行研发的优劣势说起。
3512 0
网关平台架构分享
#概述 由于物种起源、历史变革等不可控因素,我们的后端服务有A、B平台之分。A平台开发之初,对外出口就设定在网关上,一直被叫做A网关。B平台的架构大致是,后端各个业务系统,服务治理、RPC,使用dubbox,对外有两个web 服务层应用(controller层),分别对应车机和手机端入口,通过注册中心获取各个业务服务提供者信息,rpc调用之。
2578 0
+关注
文章
问答
文章排行榜
最热
最新
相关电子书
更多
超融合网关和软硬件网关编排平台
立即下载
微服务架构演进与挑战-API网关,分布式事务
立即下载
云服务总线微服务网关
立即下载


http://www.vxiaotou.com