之前介绍了什么时候进行服务化,以及服务化拆分的两种方式即横向拆分和纵向拆分,还提到了引入微服务架构需要解决的问题。
这篇文章将进行介绍微服务架构的各个组成部分。
下图是微服务架构的模块图,在具体介绍之前先来看下一次正常的服务调用的流程。
首先服务提供者(就是提供服务的一方)按照一定格式的服务描述,向注册中心注册服务,声明自己能够提供哪些服务以及服务的地址是什么,完成服务发布。
接下来服务消费者(就是调用服务的一方)请求注册中心,查询所需要调用服务的地址,然后以约定的通信协议向服务提供者发起请求,得到请求结果后再按照约定的协议解析结果。
而且在服务的调用过程中,服务的请求耗时、调用量以及成功率等指标都会被记录下来用作监控,调用经过的链路信息会被记录下来,用于故障定位和问题追踪。在这期间,如果调用失败,可以通过重试等服务治理手段来保证成功率。
总结一下,微服务架构下,服务调用主要依赖下面几个基本组件:
接下来进行介绍这些组件。
服务调用首先解决的问题就是服务如何对外描述。服务描述主要解决对外服务的服务名是什么,调用需要提供哪些信息,返回格式是什么以及如何进行解析。
常用的服务描述方式包括 RESTful API、XML 配置以及 IDL 文件三种。
RESTful API 方式通常用于 HTTP 协议的服务描述。RESTful API 方式的服务描述如下:
GET /sysDictoryDict/mapByUserId/{userId} POST /enterprise/enterpriseDetail/top PUT /enterprise/{enterpriseId} DELETE /enterprise/{enterpriseId}
XML 配置方式多用作 RPC 协议的服务描述,通过 *.xml 配置文件来定义接口名、参数以及返回值类型等。XML 配置方式的服务描述主要分三个步骤:
IDL 文件方式通常用作 Thrift 和 gRPC 这类跨语言服务调用框架中,比如 gRPC 就是通过 Protobuf 文件来定义服务的接口名、参数以及返回值的数据结构。
服务描述方式 | 使用场景 | 缺点 |
---|---|---|
RESTful API | 跨语言平台,组织内外都适用 | 相比 TCP,HTTP 作为通信协议性能较差 |
XML 配置 | Java 平台,一般用于组织内部 | 不支持跨语言平台 |
IDL 文件 | 跨语言平台,组织内外都适用 | 修改/删除 PB 字段不能向前兼容 |
接下来要解决的问题就是服务的发布和订阅,也就是说你提供一个服务,如何让外部想调用这个服务的人知道。就需要注册中心出场了,服务提供者将自己提供的服务以及地址登记到注册中心,服务消费者则从注册中心查询所需要调用的服务的地址,然后发起请求。
在整个微服务架构中,注册中心是最基础的核心服务之一,它记录着服务和服务地址的映射关系,为服务提供方提供注册、注销功能,为服务消费方提供服务发现的功能。
注册中心一般的工作流程是:
常见的注册中心有 Netflix 的 Eureka、HashiCorp 的 Consul、雅虎的 Zookeeper、阿里的 Nacos 等。
通过注册中心,服务消费者就可以获取到服务提供者的地址,有了地址后就可以发起调用。但在发起调用之前你还需要解决以下几个问题。
这三部分就组成了一个完成的 RPC 调用框架,通信框架提供了基础的通信能力,通信协议描述了通信契约,而序列化和反序列化则用于数据的编/解码。一个通信框架可以适配多种通信协议,也可以采用多种序列化和反序列化的格式。
可以正常发起服务调用后,就需要对调用情况进行监控,以了解服务是否正常。通常来讲,服务监控主要包括三个流程。
记录服务调用经过的每一层链路,以便进行问题追踪和故障定位。
服务追踪的工作原理大致如下:
以此类推,通过这种层层往下传递的方式,一次请求,无论最后依赖多少次服务调用、经过多少服务节点,都可以通过最开始生成的 requestid 串联所有节点,从而达到服务追踪的目的。
常用的服务追踪有 Twitter 的 Zipkin、华为的 skywalking、Uber 的 jaeger、大众点评的 CAT等。
服务治理就是保证在各种意外情况下,服务调用仍然能够正常进行。
在生产环境中,经常会遇到下面几种情况:
还有其他服务治理的手段比如自动扩缩容、负载均衡、服务路由以及服务容错等。
主要对微服务架构中的组件进行了介绍,微服务架构主要由服务描述、注册中心、服务框架、服务监控、服务追踪以及服务治理等组成。
参考
https://dwz.cn/FscvpObJ
https://dwz.cn/3PTGdySt