若依微服务重复请求微服务请求流程

转载

mob64ca140bbb8b 2024-07-03 01:14:52

若依微服务重复请求微服务请求流程_微服务架构

而且在服务调用过程中，服务的请求耗时，调用量，以及成功率等指标都会被记录下来用作监控，调用经过的链路信息会记录下来，用于故障定位和问题追踪。在这期间，如果调用失败，可以通过重试等服务治理手段来保证成功率。

服务调用首先要解决的问题就是服务如何对外描述。比如，你对外提供了一个服务，那么这个服务的服务名是什么？调用这个服务需要提供哪些信息？调用这个服务返回的结果是什么格式的？该如何解析？这些就是服务描述要解决的问题。

RESTful API方式通常用于HTTP协议的服务描述，并且常用Wiki或者Swagger来进行管理。下面是一个RESTful API方式的服务描述的例子。

若依微服务重复请求微服务请求流程_若依微服务重复请求_02

XML配置方式多用作RPC协议的服务描述，通过*.xml配置文件来定义接口名，参数以及返回值类型等。下面是XML配置方式的服务描述的例子。

若依微服务重复请求微服务请求流程_微服务架构_03

IDL 文件方式通常用作 Thrift 和 gRPC 这类跨语言服务调用框架中，比如gRPC就是通过Protobuf文件来定义服务的接口名，参数以及返回值的数据结构，实例如下：

若依微服务重复请求微服务请求流程_微服务架构_04

有了服务的接口描述，下一步要解决的问题就是服务的发布和订阅，就是说你提供一个服务，如何让外部想调用你的服务的人知道。这个时候就需要一个类似注册中心的角色，服务提供者将自己提供的服务以及地址登记到注册中心，服务消费者则从注册中心查询所需调用的服务的地址，然后发起请求。

若依微服务重复请求微服务请求流程_微服务_05

通过注册中心，服务消费者就可以获取到服务提供者的地址，有了地址就可以发起调用。但在发起调用之前你还需要解决以下几个问题。

服务通信采用什么协议？就是说服务提供者和服务消费者之间以什么样的协议进行网络通信，是采用四层TCP，UDP协议，还是采用七层HTTP协议，还是采用其他协议？

数据传输采用什么方式？就是说服务提供者和服务消费者之间的数据传输采用哪种方式，是同步还是异步，实在单连接传输，还是多路复用。

数据压缩采用什么格式？通常数据传输都会对数据进行压缩，来减少网络传输的数据量，从而减少带宽消耗和网络传输时间，比如常见的JSON序列化，Java对象序列化以及Protobuf序列化等。

一旦服务消费者和服务提供者之间能够正常发起服务调用，你就需要对调用情况进行监控，以了解服务是否正常。通常来讲，服务监控主要包括三个流程。

指标收集。就是要吧每一次服务调用的请求耗时以及成功与否收集起来，并上传到集中的数据处理中心
数据处理。有了每次调用的请求耗时以及成功与否等i西南西，就可以计算每秒服务请求量，平均耗时以及成功率等指标。

除了需要对服务调用情况进行监控之外，你还需要记录服务调用经过的每一层链路，以便进行问题追踪和故障定位。
服务追踪的工作原理大致如下：

服务消费者发起调用前，会在本地按照一定的规则生成一个requestid，发起调用时，将requestid当作请求参数的一部分，传递给服务提供者。
服务提供者接收到请求后，记录下这次请求的requestid，然后处理请求。如果服务提供者继续请求其他服务，会在本地再生成一个自己的requestid，然后把这两个requestid都当作请求参数传递下去。

以此类推，通过这种层层往下传递的方式，一次请求，无论最后依赖多少服务调用，经过多少服务节点，都可以通过最开始生成的requestid串联所有节点，从而达到服务追踪的目的。

服务监控能够发现问题，服务追踪能够定位问题所在，而解决问题就的靠服务治理。服务治理就是通过一系列的手段来保证在各种意外情况下，服务调用仍然能够正常进行。

单机故障。通常遇到单机故障，都是靠运维发现并重启服务或者从线上摘除故障节点。然而集群的规模越大，越是容易遇到单机故障，在机器规模超过一百台以上时，靠传统的人肉运维显然难以应对。而服务治理可以通过一定的策略，自动摘除故障节点，不需要认为干预，就能保证单机故障不会影响业务
单IDC故障。你应该经常听说某APP，因为施工挖断光缆导致大批量用户无法使用的严重故障。而服务治理可以通过自动化切换故障IDC的流量到其他正常IDC，可以避免因为单IDC故障引起的大批量业务受影响。
依赖服务不可用。比如你的服务依赖另一个服务，当另一个服务出现问题时，会拖慢甚至拖垮你的服务。而服务治理可以通过限流，在依赖服务异常的情况下，一段时间内停止发起调用而直接放回，这样一方面保证了服务消费者能够不被拖垮，另一方面也给服务提供者减少压力，使其能够尽快恢复。