三件事能让你的微服务更具有弹性(微服务)

作者:xinwang_m@163.com
发布时间: 2020-07-21 04:49:28 (5年前)
关键词: 微服务
摘要:

                              
                                     建立一个分布式微服务系统的优点是能够应对承受故障发生以及弹性使用网络资源，弹性的定义很简单，如果传统的monolith发生故障，里面的一切就不能运行了，而微服务则是将其分离成很多小组件，每个组件微服务失败故障不会影响其他。

<p>建立一个分布式微服务系统的优点是能够应对承受故障发生以及弹性使用网络资源，弹性的定义很简单，如果传统的monolith发生故障，里面的一切就不能运行了，而微服务则是将其分离成很多小组件，每个组件微服务失败故障不会影响其他。</p><p>为了真正测试这种弹性情况，Netflix使用“chaos monkey” 或类似 “混沌chaos” 策略：引入扰动到系统中目地是为了证明系统的弹性真的能面对失败。</p><p>把大块头切分成更小的碎片可以给你弹性系统的品质，但是没有一些超前想法则不行，我们将它们切分得越小，就更需要协调组合它们，或者它们依赖“下游downstream”服务数据, 函数等等. 如果这些下游服务失败了，我们的服务怎么办？</p><h2><a href="#承诺和错误反馈" name="承诺和错误反馈">承诺和错误反馈</a></h2><p>承诺理论(Promise theory)首先由Mark Burgess引入， 是为了描述IT系统彼此交互，系统之间或许并不如我们所希望那样有预期行为，一个服务提供发送内容需要做某事，但是也许它不是确定肯定做这个事情，这如同人与人之间交互一样，我们可以将微服务看成是独立的匿名代理，我们越尊重这种自主性，越需要了解这些系统自愿打算提供一些的服务有时会无法实现。</p><p>在微服务架构中更加要注重这种承诺理论，如果交互服务中有一个不可用怎么办？有没有回馈告诉我们？许多时候，这种反馈常常是被业务人员发现，解决方法无非是返回失败响应，或选择一个不同备份服务，总之，需要积极面对出乎意料的错误。</p><p>因此在微服务者，需要考虑多个服务调用时如果一个服务发生问题怎么办，解决这个问题方法引入：Apache Camel和Netflix Hystrix。</p><h2><a href="#消费合约consumer-contracts" name="消费合约consumer-contracts">消费合约Consumer contracts</a></h2><p>服务作为内容提供者进行了承诺和错误反馈，那么作为服务的消费者怎么办？</p><p>服务方提供一个合约形式，比如是描述请求和预期响应的文档或XML之类schema，消费者会确认这些文档，按照服务者同意的这份合约实现自己内部的数据模型。消费者也许与服务交互，进行序列化或反序列化转换，这时如果服务改变了合约，比如增加了新的字段内容，那么消费者这种转换过程就被迫中断，因为我们注重服务的自主性，因此这种情况出现肯定不好，我们需要将服务的变动不会对其他关系者造成脉冲扰动。</p><p>一个解决方案是基于“将保守留在服务发送方，将自由留在服务接受方”，我们只要做刚刚足够的响应验证，然后立即取出我们需要的数据，而不是试图做完整的数据验证。这意味着我们转换逻辑足够聪明到能在数据模型变化时也能工作。此外，如果我们能够捕捉到消费者真正关心的部分，将这一信息循环反馈给服务提供商，以帮助他们理解服务消费者在他们改变服务时会导致什么变化后果。这种方式称为消费驱动合约：Consumer Driven Contracts: A Service Evolution Pattern</p><p>Schema registries 能够 帮助我们做到这点</p><h2><a href="#幂等消费者" name="幂等消费者">幂等消费者</a></h2><p>幂等消费者就是能够在服务发生问题时，不断重试，多次重试不会对业务状态有任何影响，比如新增操作不是幂等，因为多次新增操作后业务会多一些状态。幂等消费者对应着幂等服务dempotent services.</p><p>以上三点建议可以帮助你建立弹性的微服务，虽然他们不是唯一需要考虑的设计原则。还有其他需要考虑的事情包括隔离、舱壁bulkhead模式、负载平衡、服务发现、apologies，最终一致性等等。,建立一个分布式微服务系统的优点是能够应对承受故障发生以及弹性使用网络资源，弹性的定义很简单，如果传统的monolith发生故障，里面的一切就不能运行了，而微服务则是将其分离成很多小组件，每个组件微服务失败故障不会影响其他。</p><p>为了真正测试这种弹性情况，Netflix使用“chaos monkey” 或类似 “混沌chaos” 策略：引入扰动到系统中目地是为了证明系统的弹性真的能面对失败。</p><p>把大块头切分成更小的碎片可以给你弹性系统的品质，但是没有一些超前想法则不行，我们将它们切分得越小，就更需要协调组合它们，或者它们依赖“下游downstream”服务数据, 函数等等. 如果这些下游服务失败了，我们的服务怎么办？</p><h2><a href="#承诺和错误反馈" name="承诺和错误反馈">承诺和错误反馈</a></h2><p>承诺理论(Promise theory)首先由Mark Burgess引入， 是为了描述IT系统彼此交互，系统之间或许并不如我们所希望那样有预期行为，一个服务提供发送内容需要做某事，但是也许它不是确定肯定做这个事情，这如同人与人之间交互一样，我们可以将微服务看成是独立的匿名代理，我们越尊重这种自主性，越需要了解这些系统自愿打算提供一些的服务有时会无法实现。</p><p>在微服务架构中更加要注重这种承诺理论，如果交互服务中有一个不可用怎么办？有没有回馈告诉我们？许多时候，这种反馈常常是被业务人员发现，解决方法无非是返回失败响应，或选择一个不同备份服务，总之，需要积极面对出乎意料的错误。</p><p>因此在微服务者，需要考虑多个服务调用时如果一个服务发生问题怎么办，解决这个问题方法引入：Apache Camel和Netflix Hystrix。</p><h2><a href="#消费合约consumer-contracts" name="消费合约consumer-contracts">消费合约Consumer contracts</a></h2><p>服务作为内容提供者进行了承诺和错误反馈，那么作为服务的消费者怎么办？</p><p>服务方提供一个合约形式，比如是描述请求和预期响应的文档或XML之类schema，消费者会确认这些文档，按照服务者同意的这份合约实现自己内部的数据模型。消费者也许与服务交互，进行序列化或反序列化转换，这时如果服务改变了合约，比如增加了新的字段内容，那么消费者这种转换过程就被迫中断，因为我们注重服务的自主性，因此这种情况出现肯定不好，我们需要将服务的变动不会对其他关系者造成脉冲扰动。</p><p>一个解决方案是基于“将保守留在服务发送方，将自由留在服务接受方”，我们只要做刚刚足够的响应验证，然后立即取出我们需要的数据，而不是试图做完整的数据验证。这意味着我们转换逻辑足够聪明到能在数据模型变化时也能工作。此外，如果我们能够捕捉到消费者真正关心的部分，将这一信息循环反馈给服务提供商，以帮助他们理解服务消费者在他们改变服务时会导致什么变化后果。这种方式称为消费驱动合约：Consumer Driven Contracts: A Service Evolution Pattern</p><p>Schema registries 能够 帮助我们做到这点</p><h2><a href="#幂等消费者" name="幂等消费者">幂等消费者</a></h2><p>幂等消费者就是能够在服务发生问题时，不断重试，多次重试不会对业务状态有任何影响，比如新增操作不是幂等，因为多次新增操作后业务会多一些状态。幂等消费者对应着幂等服务dempotent services.</p><p>以上三点建议可以帮助你建立弹性的微服务，虽然他们不是唯一需要考虑的设计原则。还有其他需要考虑的事情包括隔离、舱壁bulkhead模式、负载平衡、服务发现、apologies，最终一致性等等。</p>

0 条回复

动动手指，沙发就是你的了！

登录后才能参与评论