微服务性能模式

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

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

系统集成面临的挑战

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

一、Throttling 节流模式

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

二.Timeouts 超时

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

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

另一个重要的设计是：让不同任务请求通过自个专门的线程池请求到各自微服务，像舱壁一样对资源进行隔离； 假设这么个场景，在应用中你需要使用REST通过HTTP连接五个不同的微服务，使用一个普通的线程池去维持这些连接，如果五个服务中其中一个服务由于某种原因出现异常，所有的池成员都将精疲力尽的等待服务器响应，为了最大限度地减少的影响，它始终是一个很好的做法，定制个性化服务话服务始终是一个号的做法。这可以减少某个异常影响对其他服务的影响，从而使您的应用程序其他部分继续执行。这种模式俗称的舱壁。
下图描述了实施舱壁的简单的示例场景：在左侧，微服务A，用同一个连接池去请求X和Y两个服务。如果服务X或服务的Y其中任何一个行为异常，这会影响连接池的整体行为。如果舱壁模式实现，如该图所示的右侧，即使微服务X被错误操作，只有池X将受到影响。微服务Y可以继续为应用程序提供服务.

四.Circuit Breakers 断路器（CircuitBreaker）设计模式

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

五.Asynchronous Integration 异步集成

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

总结

在本文中，谈到了一些我们所面对集成基于微服务系统性能的挑战。它也提出了一些设计模式，设计系统怎么避免这些性能问题。我们讨论了限制，超时，舱壁和断路器模式。除了这些，异步集成方法也进行了讨论。
简而言之，异步集成应该是首选，只要有可能。其他的设计模式，我们应该根据集成场景去使用，来避免异常引起下游系统的级联副作用。