【微服务干货系列】微服务性能模式

前言：基于微服务系统越来越普遍。下面我们就来看看五种常见的特定微服务性能的挑战，以及如何应解他们。

背景：在IT界微服务架构为基础的系统越来越多， 每一个应用系统都集成了不同的组件和服务，几乎所有的特定业务应用程序都需要集成一个或更多的应用服务。但是一个综合性系统集成不同的服务无疑是一个巨大的挑战。随着基于微服务架构的发展，集成点和接触点的数量大量增加，许多系统基于微服务提供的服务或功能开始进行系统自身的分解。这反过来又增加了性能挑战，影响系统的整体功能。本文主要讨论一些能影响以微服务为基础系统的性能的关键性挑战，也提出了一些能够避免这些问题的技术。

系统集成面临的挑战

分布式计算本来就有它自己的挑战，所有这些挑战不仅有据可查，而且还几乎每天都在分布式系统上工作的专业人士都经历过。尤其在集成环境中接触点超过了“正常点”，就会变得更糟糕。如果我们的应用程序没有设计优雅地处理这种情况，这对我们的应用程序的性能和稳定性将产生不利影响。当连接到其他微服务（在同一界范围内或者远程的，外部系统）时，很多事情都可能出错，可能导致微服务的连接速度变慢甚至奔溃。

在本节中，我们将讨论一些方法和设计方面的决策，这可以帮助我们在微服务为基础的环境中实现更好的性能，增强系统的弹性和整体稳定性。

一、Throttling 节流模式

节流是一种技术，可用于避免任何由于行为异常发送的请求超过我们的应用程序处理的荷载，而导致的系统过载或奔溃。实现节流的一个简单方法是限定单个应用程序的连接数。比如有两个厂商调用我们的微服务从账户中取钱。如果一个供应商是一个很大的应用程序像亚马逊，那么它调用应用的次数要比一个拥有小用户群体的供应商要多的多。因此，我们可以提供这两家厂商两个独立的专门“切入点”专用节流进行连接限制。这样，大量来自亚马逊未来的请求不会妨碍从第二个供应商来请求。此外，我们可以调节各个合作伙伴，这样发送请求速度就不会超过我们的处理速度了。来自外部负载均衡器或HTTP服务器同步请求或其他这样的切入点就是节流。

二.Timeouts 超时

如果请求的微服务回应比较迟钝，这会导致系统的一次请求需要花费很长时间。甚至应用程序线程在很长的时间内处于忙碌状态。这可能对我们的应用程序中的级联影响，导致应用/服务器成为完全哽咽/响应。大多数库/APIs/框架和服务器都为各种特定的请求超时提供配置。您可能需要设置读取请求/写请求/等待超时/保活超时超时/连接池等待超时等。这些超时值只能通过适当的性能测试/验证SLA等确定

三.Dedicated Thread Pools/Bulkheads 专门的线程池/舱壁模式

另一个重要的设计是：让不同任务请求通过自个专门的线程池请求到各自微服务，像舱壁一样对资源进行隔离； 假设这么个场景，在应用中你需要使用REST通过HTTP连接五个不同的微服务，使用一个普通的线程池去维持这些连接，如果五个服务中其中一个服务由于某种原因出现异常，所有的池成员都将精疲力尽的等待服务器响应，为了最大限度地减少的影响，它始终是一个很好的做法，定制个性化服务始终是一个好的做法。这可以减少某个异常影响对其他服务的影响，从而使您的应用程序其他部分继续执行。这种模式俗称的舱壁。

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

四.Circuit Breakers 断路器设计模式

断路器是一种设计模式，它是用来减少任何下游的不可访问或系统故障（由于计划内或计划外的中断的）影响。断路器用于检查外部系统/服务的可用性，一旦外部系统或服务奔溃了，断路器应用程序就可以阻止发送请求到这些外部系统。这种做法作为一种安全措施，在超时/舱壁，其中一个可能不希望，甚至等待超时所规定的期限上。如果下游系统宕机，对于每个请求来说是没有用的等待时间，而且最后还获得超时异常的响应。相反，请求甚至不要尝试连接到这些系统中。断路器有内置的逻辑来执行外部系统进行必要的健康检查。

五.Asynchronous Integration 异步集成

将各个微服务之间的通信进行解耦可以避免多数的集成性能问题，异步集成方法就是实现解耦的一种机制，如果您的系统是基于微服务系统设计的，而且各个微服务之间都是点到点的整合，那么这就值得认真思考了。任何标准的消息代理系统都可用于提供发布 - 订阅功能。

总结

在本文中，我们谈到了一些基于微服务系统集成性能所面对的挑战。同时也提供了避免这些问题的一些设计，我们讨论了限制、超时、舱壁和断路器模式以及异步集成方法。

简而言之，只要有可能异步集成应该是首选，其他的设计模式，我们应该根据集成场景去使用，来避免异常引起下游系统的级联副作用。