API网关帮后端服务做连接管理

本文涉及的产品
云原生 API 网关,700元额度,多规格可选
简介: 使用API网关来管理你的API的时候,由API网关来负责管理所有客户端的连接,后端服务器可以专心处理业务请求,节省了大量连接管理的开销。

当一个互联网产品业务量越来越大,她接入的客户端也会越来越多,不管客户端使用的是长连接还是短连接,对用户的连接管理必将成为一件耗资源且复杂的事情。特别对于使用HTTP短连接进行数据交互的业务,在HTTP连接维护上面,需要花费比较大的开销。

让我们来看看使用HTTP短连接来完成一次数据交互的全过程。

众所周知,HTTP是基于TCP的协议,而使用TCP进行通信前,首先需要通信双方建立TCP连接。我们来看看客户端是如何和服务器端建立连接的:

  1. 请求新的TCP连接时,客户端需要向服务器发送一个小的TCP报文(通常是40-60字节), 这个报文设置了一个特殊的SYN标记。说明这是一个连接请求;
  2. 如果服务器接受了连接,就会对一些连接参数进行计算,并向客户端回送一个TCP报文,这个报文的SYN和ACK标记都被置位。ACK标记被置位是告诉客户端,服务器端已经收到你的连接请求了,SYN标记被置位是服务器告诉客户端,服务器端的连接已经建立;
  3. 最后, 客户端收到刚才的SYN和ACK报文后,向服务器会送一条TCP报文,这个报文的ACK标记都被置位。这个报文是通知服务器端,客户端知道服务器的连接建立好了。

三步完成后,此连接已成功建立, 客户端和服务器端都可以在此连接上发送数据了,这三步就是江湖上经常说道的TCP三次握手的过程,下面我们用一张图来更清晰地描述下这个过程:

三次握手建立连接

连接建立后,客户端在这条连接上发送请求数据,服务器端收到请求后,将请求交给业务线程处理,业务线程在处理完成业务后,将应答数据写入连接。客户端接收到应答数据,将应答数据处理后显示给客户端使用者。此时客户端由于客户端使用的是短连接通信策略,并且数据交互过程已经完成,客户端会主动去关闭这条连接,这个关闭的过程也比较复杂,比建立连接的三步还多一步:

  1. 客户端需要向服务器发送一个标记为FIN的报文,告诉服务器我要关闭这条连接了;
  2. 服务器收到客户端发送的标记为FIN的报文后,给客户端发送一个标记为ACK的报文,告诉客户端我知道你想关闭这条连接了;此时服务器如果还有未发送完的应答数据,也会继续在这条连接上将数据传输完毕;
  3. 服务器端发现自己也没有数据发送给客户端了,这时服务器会给客户端发送一条标记为FIN的报文,告诉客户端,我也准备好关闭这条连接了;
  4. 客户端收到服务器端发送过来的FIN报文后,立即给服务器端发送一个针对这条FIN报文的ACK报文,告诉服务器端,我收到了,你安心释放这条连接的资源吧。服务器收到最后的ACK报文后,将这条连接的资源释放掉。此时客户端在发送完ACK报文后会处于TIME_WAIT状态一段时间,然后再释放这条连接。

让我们用一张简要的图来描述下这个过程:

关闭TCP连接

有时候服务器端会主动发起FIN报文,流程和客户端发起的一样,这块就不继续描述了。

从以上的描述中,我们已经可以了解到,客户端和服务器端处理连接的建立和释放这个过程是非常耗时间和资源的。目前很多APP的业务还都是使用HTTP短连接来完成数据通讯的,这样每完成一次业务通信,就需要完成一次建立连接和关闭连接的过程。使用HTTP短连接做数据通讯,每一次连接的建立和关闭具体会消耗服务器多少时间呢,我们可以通过抓包来量化这个过程。

下面是我抓的一个典型的短连接数据的网络包,客户端向服务器发起请求一个HTTP请求获取一个静态页面,服务器端读取本地页面文件后给客户端返回。

短连接HTTP请求抓包

从这个图中我们可以看到,前三个包是TCP三次握手建立连接的过程,一共花费了服务器22毫秒的样子,中间三个报文是接收HTTP请求和返回应答的报文,一共花费了服务器180毫秒,最后四个报文是关闭连接的报文,花费了服务器60毫秒左右。也就是说服务器在连接的建立与关闭,一共花费了82毫秒的CPU时间,而真实的业务处理花费了180毫秒,连接管理的开销达到了业务开销的45%。这个业务请求是有磁盘IO的,如果业务的操作在内存可以完成,那么连接管理的开销可能达到业务开销的100%。

如果你的业务服务器部署在阿里云API网关的后面,由阿里云API网关负责管理所有客户端的连接,阿里云API网与后端业务服务器之间使用长连接进行通信。由于长连接通信不需要频繁的建立、释放TCP连接,那么后端的业务服务器完全不用在连接管理上面有额外开销,所有的CPU资源都可以花销在业务处理上。我们来看一下这块的架构图:

架构图

结论:

使用API网关来管理你的API的时候,由API网关来负责管理所有客户端的连接,后端服务器可以专心处理业务请求,节省了大量连接管理的开销。

需要注意的一点是,后端服务器的HTTP容器必须配置成支持HTTP长连接才能享受到使用API网关带来福利。

目录
相关文章
|
1月前
|
弹性计算 监控 负载均衡
|
23天前
|
JSON 缓存 测试技术
构建高效RESTful API的后端实践指南####
本文将深入探讨如何设计并实现一个高效、可扩展且易于维护的RESTful API。不同于传统的摘要概述,本节将直接以行动指南的形式,列出构建RESTful API时必须遵循的核心原则与最佳实践,旨在为开发者提供一套直接可行的实施框架,快速提升API设计与开发能力。 ####
|
26天前
|
JSON API 数据格式
探索后端开发:从零构建简易RESTful API
在数字时代的浪潮中,后端开发如同搭建一座桥梁,连接着用户界面与数据世界。本文将引导读者步入后端开发的殿堂,通过构建一个简易的RESTful API,揭示其背后的逻辑与魅力。我们将从基础概念出发,逐步深入到实际操作,不仅分享代码示例,更探讨如何思考和解决问题,让每一位读者都能在后端开发的道路上迈出坚实的一步。
|
1月前
|
缓存 前端开发 API
深入浅出:后端开发中的RESTful API设计原则
【10月更文挑战第43天】在数字化浪潮中,后端开发如同搭建梦想的脚手架,而RESTful API则是连接梦想与现实的桥梁。本文将带你领略API设计的哲学之美,探索如何通过简洁明了的设计,提升开发效率与用户体验。从资源定位到接口约束,从状态转换到性能优化,我们将一步步构建高效、易用、可维护的后端服务。无论你是初涉后端的新手,还是寻求进阶的开发者,这篇文章都将为你的开发之路提供指引。让我们一起走进RESTful API的世界,解锁后端开发的新篇章。
|
29天前
|
JSON 关系型数据库 测试技术
使用Python和Flask构建RESTful API服务
使用Python和Flask构建RESTful API服务
|
1月前
|
缓存 API 开发者
构建高效后端服务:RESTful API设计原则与实践
【10月更文挑战第43天】在数字化时代的浪潮中,后端服务的稳定性和效率成为企业竞争力的关键。本文将深入探讨如何构建高效的后端服务,重点介绍RESTful API的设计原则和实践技巧,帮助开发者提升服务的可用性、可扩展性和安全性。通过实际代码示例,我们将展示如何将这些原则应用到日常开发工作中,以确保后端服务能够支撑起现代Web和移动应用的需求。
|
1月前
|
存储 SQL API
探索后端开发:构建高效API与数据库交互
【10月更文挑战第36天】在数字化时代,后端开发是连接用户界面和数据存储的桥梁。本文深入探讨如何设计高效的API以及如何实现API与数据库之间的无缝交互,确保数据的一致性和高性能。我们将从基础概念出发,逐步深入到实战技巧,为读者提供一个清晰的后端开发路线图。
|
1月前
|
存储 JSON 测试技术
构建高效后端API:实践和原则
【10月更文挑战第43天】本文深入探讨了如何设计和实现高效、可维护的后端API,强调了设计哲学、最佳实践和常见陷阱。通过具体示例,我们展示了如何运用这些原则来提高API的性能和可用性。
|
1月前
|
JSON API 开发者
构建高效API:后端开发中的RESTful最佳实践####
在数字化时代,API作为不同系统间通信的桥梁,其重要性日益凸显。本文将深入探讨RESTful API的设计原则与最佳实践,通过实际案例分析,揭示如何构建高效、可维护且易于使用的API接口,助力后端开发者提升项目质量与用户体验。 ####
|
1月前
|
JSON 缓存 API
探索后端开发中的RESTful API设计原则
【10月更文挑战第41天】在后端开发的广阔天地中,API的设计如同绘制一幅精细的地图,指引着数据的流向和前端的交互。本文将带你走进RESTful API的世界,一起探索如何用简洁高效的设计原则来构建一个清晰、可维护且易于理解的API结构。我们将从RESTful API的基础概念出发,通过实际案例分析,揭示如何在实践中应用这些设计原则,并讨论如何在复杂的业务逻辑中保持API的简洁性和一致性。

热门文章

最新文章

下一篇
DataWorks