Httpclient核心架构设计

本文涉及的产品
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
全局流量管理 GTM,标准版 1个月
云解析 DNS,旗舰版 1个月
简介: 大概两周前,团队需要对httpclient进行调优,领到任务后,大致研究了源码很快就确定了调优方向。但是对于一个重度强迫症患者,对一件事情的理解就只有两种程度,完全懂或者完全不懂,于是悲催的开始httpclient整体架构的探索之路,每天晚上回家抽点边角料的时间写,之前的理解建立在一个宏观基础上,对整体有个把握,写的过程中细节不断丰富细节,理解开始变得立体起来。背景知识 Http简介 通常,我

大概两周前,团队需要对httpclient进行调优,领到任务后,大致研究了源码很快就确定了调优方向。但是对于一个重度强迫症患者,对一件事情的理解就只有两种程度,完全懂或者完全不懂,于是悲催的开始httpclient整体架构的探索之路,每天晚上回家抽点边角料的时间写,之前的理解建立在一个宏观基础上,对整体有个把握,写的过程中细节不断丰富细节,理解开始变得立体起来。

背景知识

Http简介

通常,我们使用IE或者safari来访问互联网上的内容,只需要输入资源地址,浏览器便会呈现给你想要的内容。这一切的背后,都是迄今为止在计算机领域最成功的协议–http协议。

Http协议分为请求和响应,客户端建立连接,接着发送请求,服务端接受并处理请求,再发送应答,再由客户端接受并处理应答。浏览器是最最常见的一种客户端,它将用户的交互行为作为http请求发送,并接受服务端的应答,再将应答内容展示,一般应答都是html类型的超文本。

浏览器显然不是唯一的客户端,理论上任何遵循了http规范都可作为客户端。在程序里也可以通过Java api实现简单的客户端–使用HttpURLConnection发送http请求,并解析应答。假设应答是个html或者json,则只需要基于双方约定的格式进行解析就能得到聚焦的结果。

Http, tcp/ip和socket区别

Tcp/ip是传输层协议,而http则是建立在它之上的上层应用协议。Http主要解决的是数据规范层面的事情,而tcp/ip主要解决的则是数据传输层面的事情。如果没有规范的应用协议,数据能从网络里的A节点传到B节点,但却无法有效识别,建立在tcp/ip上的应用协议很多,像rpc,ftp等,反过来不管应用协议有多强大最终都需要依靠传输层协议进行数据传输。 
Socket则是tcp/ip的一个编程实现,在程序里http请求(连接)最终一定需要绑定到一个具体的socket连接进行上行和下行传输。

整体架构

对于简单应用,HttpURLConnection完全可以满足。但是对于1)系统复杂度高,2)性能要求高,3)可靠性要求也高的应用,则需要一个更强大的组件。

Httpclient架构
Httpclient将对接的服务器或者集群(相同域名)称为route,并为每个route建立若干连接池化在连接池里。Client通过tcp/ip协议发送请求以及接受应答,在发送请求前和接收应答后都会经由interceptor进行链式处理,在httpclient里这些interceptor被称为HttpProcessor,负责处理诸如设置报文头,报文体,编码格式等以及解析报文头,报文体,解码格式等http规范报文格式范畴内的事情。

HttpClient静态结构

静态结构 
- HttpClient通过建造者构建出来,用户可以通过建造者暴露出来的参数属性方法来组织最终生成的产品属性。HttpClients是个工厂类,用于生产HttpClient,同时也提供custom方法返回builder,由使用者组织client属性。 
- HttpClient主要由5个组件组成,分别是: 
1. Closeable: 代表需要关闭的组件,client服务关闭时会回调注册的所有Closeable组件依次关闭。用户可以通过HttpClientBuilder#addCloseable添加自定义关闭组件。HttpClient内部利用Closeable关闭IdleConnectionEvictor以及HttpClientConnectionManager 
2. IdleConnectionEvictor: 用来关闭闲置连接,它会启动一个守护线程进行清理工作。用户可以通过builder#evictIdleConnections开启该组件,并通过builder#setmaxIdleTime设置最大空闲时间。 
3. HttpClientConnectionManager管理着连接的整个生命周期。连接在连接池中创建、复用以及移除。 
连接状态 
connection被创建出来后处于闲置状态,由连接池管理,被lease后会校验是否是open状态,不是的话会进行connect,connect的过程就是将http请求(连接)绑定到socket的过程。同时连接也会因为心跳或者过期等原因被close变成stale状态,直至被下一次get到时或者连接满时被清理出去。

同时连接池还能对连接进行限流–全局和单route连接数。Connection manager封装了对连接池的具体操作,比如向连接池租用和归还连接;还提供了基于不同schema(主要是http和https)创建不同的socket连接(ssl和plain)并且将http请求(连接)绑定到socket的能力,等等。 
4. HttpRoutePlanner用来创建HttpRoute。后者代表客户端request的对端服务器,主要包含rout的host以及proxy信息。 
5. ClientExecChain代表一次完整的调用执行过程,它是一个包装类,类似于java io类,每个包装类完成一个特定的功能,多层嵌套完成一个系统性的功能,比如处理协议范畴的例如cookie、报文解析等,又比如处理自动重试的,等等。

连接池

CPool静态结构

  • CPool里的连接分为三种–available, leased和pending,分别对应空闲,占用和堵塞三种状态,连接池为这三种状态建立三个列表(List/Set)。对连接数的管理则有两个维度,分别是全局最大数和单route最大数。全局连接和单route连接都对应三种状态列表,CPool内部维护了route和RouteSpecificPool的映射,通过后者对单route连接进行管理,并且严格保证一个route只会对应一个route pool。操作(租用,释放,阻塞或者移除等等)连接时CPool首先会依据route信息取出route pool,对其上维护的连接进行操作,之后再对CPool上的相应连接操作。RouteSpecificPool是个friend的abstract类,也就是说它是CPool隐藏起来的实现细节,对外只暴露CPool的行为甚至用户都可以不理会CPool只关心connection mananger。

  • 连接池对外透出的是PoolEntryFuture,后者的get方法能够获取一个闲置连接,或者进入堵塞等待。  
    requestConn交互
    连接池的连接连同route信息一起被包含在PoolEntry里返回给消费者,除此之外,PoolEntry还包含了连接的失效时间等等,超过失效时间会在下一次被get到时close。

  • CPool还有流控功能,get请求在没有空闲连接但连接数没达到阈值时通过连接池创建连接并池化放入available或者leased。leased连接数达到阈值时对请求进行堵塞–PoolEntryFuture#await,并且将PoolEntryFuture放入pending。其他请求释放连接时会唤醒堵塞请求,被唤醒的请求获取到连接后会被从pending列表中移除。 
    连接池交互
    超过任何一个最大数阈值后CPool首先都会进行收缩,超过单route最大数,则收缩单route连接,超过全局最大数,则收缩全局连接。收缩的过程只会关闭空闲连接,直至连接数等于阈值-1。

执行链

执行链静态结构

  • MainClientExec是真正执行客户端请求的,它位于包装类的最里层,它通过连接管理器向CPool requestConnection,绑定http请求到socket,通过request executor发送请求,并且还能基于keep-alive策略处理连接的复用等等。

  • ProtocolExec通过一系列的HttpProcessor处理链对Http消息按格式编码以及解码。每一个processor处理一个范畴的事情,比如处理header,content以及cookie等等。

  • RetryExec,对io某些特殊情形的io异常进行重连,保证可用性。

  • RedirectExec,处理301,302,303和307的情况,即move和redirect。

  • BackoffStrategyExec对出现连接或者响应超时异常的route进行降级,缩小该route上连接数,能使得服务质量更好的route能得到更多的连接。降级的速度可以通过因子设置,默认是每次降级减少一半的连接数,即降级因子是0.5。

最后注意一点,以上的这些exec只有MainClientExec和ProtocolExec是默认开启的,其他的都需要通过HttpClientBuilder设置参数开启,具体可以参考文档或者源码。

调优方向

了解了架构原理后,就可以着手在3个方向进行调优: 
1. 连接数,通过设立全局最大连接数和单route连接数,增加吞吐能力。用户可通过HttpClientBuilder#maxConnTotal和#maxConnPerRoute分别设置。 
2. 获取连接的超时时间,调小超时时间能够有效提高响应速度并且降低积压请求量,但相应的也会增加请求失败的几率。用户可以通过RequestConfig的connectionRequestTimeout进行设置。 
3. 建立连接和route响应的超时时间,调小能够有效的降低bad request对连接的占用,留给质量更好的请求,有效提高系统提高吞吐能力及响应速度。否则有可能在峰值期被慢请求占满连接池,导致系统瘫痪。两者分别可通过RequestConfig#connectionTimeout和socketTimeout进行设置。 
4. 开启BackoffStrategyExec,对状况差的route进行降级处理,将连接让给其他route。

目录
相关文章
|
网络协议
Httpclient核心架构设计
背景知识 Http简介 通常,我们使用IE或者safari来访问互联网上的内容,只需要输入资源地址,浏览器便会呈现给你想要的内容。这一切的背后,都是迄今为止在计算机领域最成功的协议–http协议。 Http协议分为请求和响应,客户端建立连接,接着发送请求,服务端接受并处理请求,再发送应答,再由客户端接受并处理应答。浏览器是最最常见的一种客户端,它将用户的交互行为作为
4294 0
|
1月前
|
弹性计算 API 持续交付
后端服务架构的微服务化转型
本文旨在探讨后端服务从单体架构向微服务架构转型的过程,分析微服务架构的优势和面临的挑战。文章首先介绍单体架构的局限性,然后详细阐述微服务架构的核心概念及其在现代软件开发中的应用。通过对比两种架构,指出微服务化转型的必要性和实施策略。最后,讨论了微服务架构实施过程中可能遇到的问题及解决方案。
|
2月前
|
Cloud Native Devops 云计算
云计算的未来:云原生架构与微服务的革命####
【10月更文挑战第21天】 随着企业数字化转型的加速,云原生技术正迅速成为IT行业的新宠。本文深入探讨了云原生架构的核心理念、关键技术如容器化和微服务的优势,以及如何通过这些技术实现高效、灵活且可扩展的现代应用开发。我们将揭示云原生如何重塑软件开发流程,提升业务敏捷性,并探索其对企业IT架构的深远影响。 ####
50 3
|
2月前
|
Cloud Native 安全 数据安全/隐私保护
云原生架构下的微服务治理与挑战####
随着云计算技术的飞速发展,云原生架构以其高效、灵活、可扩展的特性成为现代企业IT架构的首选。本文聚焦于云原生环境下的微服务治理问题,探讨其在促进业务敏捷性的同时所面临的挑战及应对策略。通过分析微服务拆分、服务间通信、故障隔离与恢复等关键环节,本文旨在为读者提供一个关于如何在云原生环境中有效实施微服务治理的全面视角,助力企业在数字化转型的道路上稳健前行。 ####
|
1月前
|
Java 开发者 微服务
从单体到微服务:如何借助 Spring Cloud 实现架构转型
**Spring Cloud** 是一套基于 Spring 框架的**微服务架构解决方案**,它提供了一系列的工具和组件,帮助开发者快速构建分布式系统,尤其是微服务架构。
168 69
从单体到微服务:如何借助 Spring Cloud 实现架构转型
|
1月前
|
设计模式 负载均衡 监控
探索微服务架构下的API网关设计
在微服务的大潮中,API网关如同一座桥梁,连接着服务的提供者与消费者。本文将深入探讨API网关的核心功能、设计原则及实现策略,旨在为读者揭示如何构建一个高效、可靠的API网关。通过分析API网关在微服务架构中的作用和挑战,我们将了解到,一个优秀的API网关不仅要处理服务路由、负载均衡、认证授权等基础问题,还需考虑如何提升系统的可扩展性、安全性和可维护性。文章最后将提供实用的代码示例,帮助读者更好地理解和应用API网关的设计概念。
69 8
|
2月前
|
Dubbo Java 应用服务中间件
服务架构的演进:从单体到微服务的探索之旅
随着企业业务的不断拓展和复杂度的提升,对软件系统架构的要求也日益严苛。传统的架构模式在应对现代业务场景时逐渐暴露出诸多局限性,于是服务架构开启了持续演变之路。从单体架构的简易便捷,到分布式架构的模块化解耦,再到微服务架构的精细化管理,企业对技术的选择变得至关重要,尤其是 Spring Cloud 和 Dubbo 等微服务技术的对比和应用,直接影响着项目的成败。 本篇文章会从服务架构的演进开始分析,探索从单体项目到微服务项目的演变过程。然后也会对目前常见的微服务技术进行对比,找到目前市面上所常用的技术给大家进行讲解。
62 1
服务架构的演进:从单体到微服务的探索之旅
|
2月前
|
负载均衡 Java 持续交付
深入解析微服务架构中的服务发现与负载均衡
深入解析微服务架构中的服务发现与负载均衡
91 7
|
2月前
|
消息中间件 运维 Kubernetes
后端架构演进:从单体到微服务####
本文将探讨后端架构的演变过程,重点分析从传统的单体架构向现代微服务架构的转变。通过实际案例和理论解析,揭示这一转变背后的技术驱动力、挑战及最佳实践。文章还将讨论在采用微服务架构时需考虑的关键因素,包括服务划分、通信机制、数据管理以及部署策略,旨在为读者提供一个全面的架构转型视角。 ####
42 1
|
2月前
|
弹性计算 运维 开发者
后端架构优化:微服务与容器化的协同进化
在现代软件开发中,后端架构的优化是提高系统性能和可维护性的关键。本文探讨了微服务架构与容器化技术如何相辅相成,共同推动后端系统的高效运行。通过分析两者的优势和挑战,我们提出了一系列最佳实践策略,旨在帮助开发者构建更加灵活、可扩展的后端服务。

热门文章

最新文章