推荐阅读:
微服务是⼀种分布式架构,系统内各部分(服务)被部署为单独的应用程序,并通过某种远程访问协议进⾏通讯。分布式应⽤的挑战之⼀就是如何管理远程服务的可用性和它们的响应。本⽂主要探讨服务的响应时间对系统的影响和应对。
上图是简化的微服务调用链路过程,为清晰阐述三个相关方,图中的客户端被限定为用户端(如移动端应用、浏览器页面等),服务端被区分为服务消费方(网络调用中客户端)和服务提供方(网络调用中服务端)。⼤部分服务既为服务消费方,⼜为服务提供方,如处于调⽤链路中间的业务服务,大概率需要去整合数据,所以通常会同时作为服务消费方和服务提供方,两种资源消耗并存。小部分服务是纯粹的服务提供方,如数据库、缓存、ZooKeeper 等。下⽂先来分析服务响应时间过⻓对资源消耗问题。
1、资源消耗分析 静态分析
微服务都有⾃身的硬件资源上限,直观来看,响应时间会对资源消耗产⽣直接影响。
服务消费方
-
协议消耗,每次发起 TCP 连接请求时,通常会让系统选取⼀个空闲的本地端⼝(local port),该端⼝是独占的,不能和其他 TCP 连接共享。TCP 端⼝的数据类型是 unsigned short,因此可⽤端⼝最多只有 65535,所以在全部作为 client 端的情况下,最⼤TCP 连接数 65535。
-
除端⼝消耗外,发起调⽤的业务进程、线程、协程等待过程中,⽆法释放其所消耗的内存、CPU 等,是服务消费⽅发起调⽤的主要消耗。
服务提供方
-
协议消耗,主要是建⽴连接的消耗,每接收每⼀个 tcp 连接都要占⼀个⽂件描述符,理论上是 server 端单机最⼤tcp 连接数约为 2 的 48 次⽅。
-
业务逻辑消耗。在复杂的业务逻辑、机器资源和⽹络带宽条件下,最⼤并发 tcp 连接数远不能达到理论上限,有时候会发现,单机 1w 并发往往也是⽐较困难。因此,服务提供⽅主要是业务逻辑的⼤量资源消耗,如 CPU、⽹络带宽、磁盘 IO 等。
动态分析
在调⽤持续发⽣且服务提供⽅不及时返回的情况下,未触发性能拐点前,可以简化认为资源的消耗是线性增⻓。微服务发起⼀个请求,会占⽤⼀个空闲的本地端⼝,当然,每个连接所对应的业务处理过程,