当前位置: 首页 > 科技观察

详解微服务编排_0

时间:2023-03-20 11:42:23 科技观察

译者|涂承业评论|SunShujuan您的组织是否使用微服务风格的架构来实现其业务功能?您使用什么方法来实现微服务的通信和编排?在过去的几年中,微服务已成为一种相当占主导地位的应用程序架构,通常与云平台(例如,容器、K8s、FaaS(功能即服务)、临时云服务)结合使用。这些服务类型之间的通信模式差异很大。微服务架构强调独立性和频繁变化的能力,但这些服务往往需要共享数据并在它们之间发起复杂的交互以完成它们的功能。在本文中,我们将研究微服务通信的模式和策略。1.网络中的问题通过网络进行通信会带来可靠性问题。数据包可能会被丢弃、延迟或重复,所有这些都可能导致不稳定和不可靠的服务到服务通信。在最基本的情况下——服务A打开与服务B的连接——我们非常信任应用程序库和网络本身来打开连接并将请求发送到目标服务(在本例中为服务B)。图1:服务A调用服务B的简单示例但是,如果连接需要很长时间才能打开,会发生什么情况?连接超时打不开怎么办?如果连接成功,但连接在处理请求之后但在响应之前关闭怎么办?我们需要一种方法来快速检测连接或请求问题并决定如何处理它们。如果服务A无法与服务B通信,可能会有一些合理的响应(例如,返回错误消息、以固定内容响应、以缓存值响应)。图2:调用多个服务的更复杂示例在稍微复杂一点的情况下,服务A可能需要调用服务B,从服务B的响应中检索一些值,然后使用它来调用服务C。如果调用服务B成功,但调用服务C失败,则返回选项可能稍微复杂一些。也许我们可以回退到预定义的响应、重试请求、根据服务B的响应中的某些数据从缓存中获取数据,或者调用不同的服务?网络中导致连接或请求失败的问题可能会间歇性地发生,应用程序必须对其进行处理。如图3所示,随着从给定服务编排更多服务调用,这些问题变得更有可能和更复杂。图3:尝试跨读/写API编排多个服务调用的示例这些服务不仅仅是“读取”调用。例如,如果服务A调用服务B,服务B执行某种数据更改,必须在下一次调用服务C时使用(例如,服务A告诉服务B客户乔的地址已更新,但还必须告诉服务C由于地址更改而没有更改运输),那么这些失败的调用很重要。这会导致不同服务之间的数据不一致和状态不一致。此类网络错误会影响微服务弹性、数据一致性,并可能影响服务水平目标(SLO)和服务水平协议(SLA)。我们需要一种方法来处理这些网络问题,同时考虑在尝试解释故障时弹出的其他问题。2.有用的网络弹性模式构建API和服务以承受网络不可靠性并不总是那么容易。服务(包括用于构建它们的框架和库)可能会在网络上发生故障,有时会以不可预测的方式进行。以下是一些有助于构建弹性服务通信的模式,但肯定不是唯一的模式。这三种模式可以根据需要使用或结合使用,以提高通信的可靠性(但每种模式都有其自身的缺点):retry/fallback重试——如果调用失败,则重新发送请求,可能会等待一段时间再试。幂等请求处理——多次处理请求并获得相同结果的能力(可能涉及写入操作的去重处理)。异步请求处理-解耦两个服务之间的时间耦合以确保成功的请求传递。让我们仔细看看这些模式。3.回退处理重试网络的不可靠性随时可能发生。如果请求失败或无法建立连接,最简单的方法之一就是重试。通常,我们需要某种有限次数的重试(例如,“重试两次”与“无限次重试”),并且可能需要一种返回重试的方法。有了回退机制,我们可以错开调用失败和重试的时间。关于重试的快速说明:我们不能永远重试,也不能将每个服务配置为重试相同次数。重试会对“重试风暴”事件产生负面影响,其中服务降级,对服务的调用被重试多次,从而对降级的服务施加压力,并最终关闭(或在尝试恢复时关闭)。从调用链上游的少量固定重试次数(例如两次)开始,不要在调用链下游重试。4.幂等请求处理对于根据传入请求更改数据的服务,服务提供者实施幂等请求处理。一个简单的例子是计数器服务,它保持运行总计数并根据传入请求增加计数。例如,请求可能带有值“5”,计数器服务会将当前计数增加5。但是如果服务处理请求(以5为增量),但不知何故响应返回到客户端丢失(网络丢包、连接失败等)?客户端可能会重试请求,但这会将计数再次增加5,这可能不是所需的状态。我们希望服务知道它已经看到了一个特定的请求,然后要么忽略它,要么应用“no-op”。如果构建服务以幂等方式处理请求,则客户端可以安全地重试失败的请求,因为该服务能够过滤掉那些重复的请求。5.异步请求处理对于前面示例中的服务交互,我们假设了某种类型的请求/响应交互,但我们可以在传输过程中持久化消息,并依靠某种队列或日志机制将它们传递给消费者。或者,从而减轻网络的一些麻烦。在这个模型中,我们消除了请求的发送者和接收者同时可用的可能性。我们可以相信消息日志或队列会在未来的某个时间保存和传递消息。重试和幂等请求处理也适用于异步场景。如果消息消费者能够正确应用“至少一次传递”保证中可能发生的更改,那么我们就不需要更复杂的事务协调。6.服务到服务通信的基本工具和注意事项为了在服务到服务通信中建立弹性,团队可能依赖于额外的平台基础设施,例如,像Kafka这样的异步消息日志或像Istio微服务弹性框架这样的服务网格.可以对具有服务网格的应用程序透明地配置和执行重试、熔断和超时等任务。因为您可以从外部控制和配置行为,所以这些行为可以应用于任何/所有应用程序——无论它们是用什么编程语言编写的。此外,可以对这些弹性策略进行快速更改,而无需强制更改代码。另一个有助于在微服务架构中进行服务编排的工具是GraphQL引擎。GraphQL引擎允许团队跨多个服务分散和编排服务调用,同时负责身份验证、授权、缓存和其他访问机制。GraphQL还允许团队更多地关注特定客户端或服务调用的数据元素。GraphQL最初主要用于表示层客户端(Web、移动等),但现在也越来越多地用于服务到服务的API调用。图4:使用GraphQL引擎跨多个服务编排服务调用如上所述,GraphQL还可以与API网关技术甚至服务网格技术相结合。无论用于服务间通信的协议(REST、gRPC、GraphQL等)如何,它们都提供了一个通用且一致的弹性策略层。7.结论大多数团队都希望云基础设施和微服务架构能够在服务交付和扩展方面做出重大承诺。我们可以构建CI/CD、容器平台和健壮的服务架构,但如果我们不考虑运行时微服务编排和随之而来的弹性挑战,那么微服务实际上只是一个过于复杂的部署架构,有所有缺点,没有好处。如果您正在通往微服务的道路上(或已经走上这条道路),请确保服务通信、编排、安全性和可观察性在您的服务中被优先考虑并一致地实施。原文链接:https://dzone.com/articles/microservices-orchestration开发经验。目前就职于壹号科技有限公司,从事比较大型的项目管理工作。