转载

微服务的性能模式

【编者按】本文作者 Rohit Dhall 是一名企业架构师，目前就职于 HCL 科技公司。 Rohit 拥有 18 年的 IT 工作经验，熟悉Java/J2ee 、 P2P 、 DWH 、SOA 等技术。本文介绍了五种微服务系统常见的性能挑战，并探讨了相应的解决策略。

本文系 OneAPM 工程师编译呈现，以下为正文。

在IT基础设施中，基于微服务架构的系统变得越来越受欢迎，在这种架构中，但凡与业务相关的功能都会由多于一个的应用组成，但是对于整个集成系统的性能而言，这种集成也带来了巨大的挑战。在基于微服务的系统中，功能通过多个服务组合提供，因此存在大量的集成点和接触点。这反过来也加重了性能负担，甚至会影响系统的整体表现。本文主要讨论一些微服务系统所面临的关键性能挑战，同时也向大家介绍一些能够帮助大家解决问题的技术和模式。

集成系统所面临的挑战

分布式计算本来就有其自身的挑战，所有这些挑战不仅有据可查，而在分布式系统上工作的专业人士几乎每天都在为之困扰，尤其在集成环境中接触点超过了「正常」集成环境时，情形则会更加糟糕。当连接到应用内部或者远程外部系统中其他微服务时，很多环节都可能出错。例如，被连接的微服务可能非常缓慢或宕机，那么如果应用程序没有提前设计好如何处理这种情况，将会对程序的性能和稳定性产生不利影响。

缓解性能挑战

在本节中，笔者将讨论一些方法和设计策略，帮助在基于微服务的环境中实现更好的性能，增强系统的弹性和整体稳定性。

节流模式

节流是一种用于规避异常应用的技术，当异常应用发送的请求超过应用程序的处理负载时，可能导致系统过载甚至崩溃。

一个实现节流的简单方法是限定单个应用程序的连接数。假设有两个厂商调用微服务从账户中取钱。其中一个供应商是像亚马逊那样庞大的应用，那么它调用应用的次数要比拥有小众群体的供应商多的多。因此，可以提供这两家厂商两个独立的专用「入口点」，通过节流进行连接限制。这样，大量来自亚马逊的请求就不会妨碍第二个供应商的请求。此外，也可以限制各个协作对象的请求频率，这样发送请求的速度就不会超过微服务的处理速度了。

一般情况下，来自外部服务/系统的同步请求会通过负载均衡器、 HTTP 服务器或其他类似的入口点进行节流限制。

超时

如果请求的微服务响应缓慢，会使得应用需要花费很长时间才能完成一个请求，应用线程在很长的时间内都处于忙碌状态。这会对应用程序产生级联影响，导致应用或服务器完全堵塞甚至失去响应。

大多数库(libraries)、 API 、框架和服务器都为各种特定的请求超时提供配置，只需设置读写请求超时、等待超时、连接池等待超时、活跃会话超时等的数值即可，但这些超时需要通过适当的性能测试或 SLA 验证才能确定。

专用线程池

另一个重要的设计是将不同的任务请求或不同的微服务连接放到独立的线程池中，就像Bulkheads那样对资源进行隔离。大家不妨设想一下这样的场景，在应用流中需要使用 REST 通过 HTTP 连接五个不同的微服务，也可以使用一个普通的线程池去维持这些连接，如果其中某个服务因为某种原因出现异常，那么池内所有的微服务都会受到牵连。为了最大限度地减少这种异常的负面影响，将单独的服务放进专门的线程池显然是更明智的做法。这不仅可以减少某个异常对其他服务的影响，还能保证应用程序的其他部分继续正常地工作。

这种模式通常被称为Bulkheads模式。下图描述了该模式的示例场景：在左侧，微服务 A 用同一个连接池去请求 X 和 Y 两个服务。如果服务 X 或 Y 其中任何一个行为异常，都将影响连接池的整体表现。如果采用Bulkheads模式，如该图右侧所示，即使微服务 X 被错误操作，也只有 X 池受到影响，微服务 Y 还可以继续正常地为应用程序提供服务。

微服务的性能模式

Circuit Breakers

Circuit Breakers是一种设计模式，可以用来减少任何下游不可访问或故障对系统整体的影响。Circuit Breakers用于检查外部系统/服务的可用性，一旦外部系统或服务宕机，应用程序就可以避免再次发送请求到这些外部系统。这种做法其实也是一种安全措施，可以避免超时或Bulkheads模式因某些故障而导致的不必要超时。如果下游系统宕机，请求就没必要一直等待直至响应超时，之后再收到超时异常的响应。相反，当下游系统处于宕机过程时，Circuit Breakers让请求不再尝试连接，进而大大地缩减了响应时间。

Circuit Breakers有内置的逻辑来对外部系统进行必要的健康检查，从而确保这些系统正常工作后再开始转发请求。