微服务 弹性伸缩_使您的微服务更具弹性的3件事

微服务 弹性伸缩

将分布式系统构建为微服务的优势之一是系统整体能够承受组件，网络，计算资源等的故障和意外故障。即使遇到故障，这些系统也具有弹性。 这种弹性背后的想法很简单：如果我们的整体失败了，它所负责的一切都会随之失败； 因此，让我们将事情分解为更小的部分，以便我们可以承受应用程序的各个部分失败而不会影响整个系统。 从理论上讲，这听起来不错，但是将事情分解成较小的块是否可以做到这一点呢？

一种测试方法是使用Netflix所谓的“混乱猴子”或类似的“混乱”策略：故意在系统中引入干扰，以证明系统或系统的弹性（或脆弱性）。 系统在发生故障时显示其本来的颜色，而不是沿路径进行处理，因此有目的地引入故障是找出实际构建的好方法。 实际上，您真正想要做的是构建抗脆弱系统，但这是另一篇文章的主题：）

将事物分解成较小的部分可以使您具有一些弹性系统的特质，但并非并非没有预见。 例如，我们破坏系统的规模越小，我们可能就越需要“协调”它们或依赖“下游”服务来获取数据，功能或同时使用这两者。 如果这些下游服务中断，我们的服务将如何处理？ 这些依赖关系类型越多，我们的服务在运行时就越互连。 如果我们依赖的服务对其合同，有效负载或事件结构进行了更改，这将如何影响我们的服务？ 当我们的合作者这样做时，我们是否被迫改变？ 如果这样做，这听起来很脆弱。 服务提供商会为我们运行其服务的多个版本吗？ 很多时候，我们依赖（或暗示）对给定事件进行一次或一次服务调用。 或至少一次且仅一次的处理。 如果上游服务遇到网络延迟和重试，会发生什么？ 我们可能会以多次调用结束。 我们做什么？

这些都是微服务的所有细节，在会议之类的大肆宣传中被忽略了，但这是真实情况。 我将共同努力，以涵盖这些“微服务实现细节”，因为我将通过分步示例构建一个不平凡的“微服务”示例（我撰写博客时会在Twitter上宣布它们，他们@christianposta）。 说我们正在“做微服务”并不能消除这些分布式问题。 因此，让我们看一下在构建微服务以增加弹性时应该经常练习的三种相当容易理解的模式。

承诺和后备

马克·伯吉斯（Mark Burgess）首先介绍了承诺理论，以描述IT系统之间的交互方式，向我们表明，我们的系统可能表现得不佳或不理想。 服务提供商发布其“意图”以“做某事”，并且它可能会也可能不会做“某事”。 在许多方面，这也是我们人类之间的互动方式。 我们越是将微服务视为复杂系统中的独立，自主的“代理”，我们就越需要尊重这种自主性，因为他们了解这些系统是自愿提供某些服务的，有时甚至是无法提供的。

那么，当事情没有按计划进行时会发生什么呢？ 让我们再来看一个非计算机示例。 请说一下我是一名顾问，并为客户提供服务。 也许我是一位可以帮助您构建微服务架构的架构师，并且我已承诺会提供一个现场架构研讨会。 这是我自愿为您提供这项服务。 如果我的飞往您公司的航班被取消（即我试图通过奥黑尔:)怎么办？ 我只是打个电话给您说“对不起，无法送出车间，我的航班已取消。” 我想我可以。 然后，下次您要我举办研讨会时，您可能会第二次猜测。 但是也许我说“对不起，我的航班被取消了，也许我还能找到另一个航班？” 或“也许我可以远程交付”，或“我们可以重新安排时间”吗？ 我已经自愿承诺要举办一个关于微服务的研讨会，因此我有责任尽我所能来实现该服务。

在微服务架构中提供服务时，以这种方式思考很重要。 当协作者服务不可用时会怎样？ 我可以使用哪些后备程序？ 很多时候，这种回退可能是由业务决定的。 也许您返回了罐头回复。 也许您调用其他服务作为备份。 也许您自己做一个简化的计算。 无论哪种方式，面对某些意外故障，您都应该考虑通过哪些替代方法来帮助实现（或部分实现）服务承诺。

Apache Camel和Netflix Hystrix对此提供了帮助。

消费者合同

从SOA时代开始，我们就已经根深蒂固地将服务合同视为服务提供商发布的东西。 在以上有关承诺的讨论中，这将是提供者的“意图”。 但是，从上面我们还可以看到，提供者也可能遇到无法履行其承诺，甚至可能返回其他东西的情况。 消费者应该如何React？

服务提供者提供某种形式的合同（即描述请求和预期响应的有效负载的文档或架构），并且消费者根据提供者的要求遵循这些文档并实现其内部数据模型。 然后，消费者将在这些服务交互期间取消编组，甚至可能验证有效负载的内容。 现在，如果提供商最终更改合同（即添加新字段），则这些数据有效载荷的解组和验证可能会中断。 这不好，因为我们重视我们的服务自主性。 我们应该能够对服务进行更改，而不会强加更改对其他服务的连锁React。

一种解决方案基于以下原则：“在提供给服务的内容上要保守，而在接受的内容上要放宽”。 基本上，我们对响应进行“足够”的验证，仅提取我们需要的数据，而不是尝试进行完整的数据验证。 这意味着我们的编组逻辑应该足够聪明，可以处理数据模型/响应不了解（或不在乎）的部分。 此外，如果我们可以捕获消费者真正关心的响应部分，则可以开始在反馈循环中将其返回给服务提供商，以帮助他们了解服务消费者中实际使用的内容以及进行更改时的更改。可能正在改变。 Thoughtworks的Ian Robinson在《 消费者驱动的合同：服务演进模式》中对此做了很好的介绍。

架构注册表可以帮助您

幂等消费者

出问题了怎么办？ 还是服务失败时？ 服务可能会在交易过程中中断。 行为不当的服务可能会无意间使我们的服务受到要求的影响。 使用中的服务可能会遇到网络延迟（请在云部署中期待！），并且可能已超时并重试。 根据定义，期望一次接收一次消息传递的系统很脆弱。 如果您构建服务以能够处理此类“意外”行为，它们将具有更大的弹性。 我们需要幂等的服务 。

一个示例是在系统之间不以“增量”形式交换消息。 这些不是幂等消息； 如果您多次收到“递增X乘20”的消息，则可能会得出不一致的值。 也许更喜欢“当前值”类型的消息，如果您多次收到它们，它们不会增加数据中的任何不一致之处。

另一个选择是采用可以过滤出重复项的基础结构。 例如，在故障转移方案中，当生产者向代理发送消息时， Apache ActiveMQ可以过滤出重复项，然后由于某种原因而最终故障转移到另一个代理。 经纪人索引可以跟踪和识别重复项并将其丢弃。

另一个选择是跟踪您在服务中收到的消息中的唯一标识符，并拒绝已成功处理的标识符。 将此信息存储在LRU缓存中可帮助您快速诊断是否已查看消息，并返回罐装响应，原始响应或忽略它。 Apache Camel使使用这种幂等消费者模式的服务的构建变得非常容易。

但是，您实现这些模式并不重要，但是我们需要可以优雅地处理故障的系统。 所有这些都是经过尝试的真实模式。 这些想法都不是新想法，但我不认为它们经常实施。 恕我直言，应始终执行它们。 遵循这三个建议将帮助您构建弹性服务，尽管它们并非唯一。 其他要考虑的因素包括隔离，隔离模式，负载平衡，服务发现，道歉​​，最终一致性等。 帮助提高弹性。 如果微服务的优势之一是弹性，那么我们应该在最前沿使用这些概念设计微服务架构。

翻译自: https://www.javacodegeeks.com/2016/05/3-easy-things-make-microservices-resilient.html

微服务 弹性伸缩