初探微服务架构

以前介绍了何时进行服务化，以及服务化拆分的两种方式即横向拆分和纵向拆分，还提到了引入微服务架构须要解决的问题。

这篇文章将进行介绍微服务架构的各个组成部分。

下图是微服务架构的模块图，在具体介绍以前先来看下一次正常的服务调用的流程。

首先服务提供者（就是提供服务的一方）按照必定格式的服务描述，向注册中心注册服务，声明本身可以提供哪些服务以及服务的地址是什么，完成服务发布。

接下来服务消费者（就是调用服务的一方）请求注册中心，查询所须要调用服务的地址，而后以约定的通讯协议向服务提供者发起请求，获得请求结果后再按照约定的协议解析结果。

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

总结一下，微服务架构下，服务调用主要依赖下面几个基本组件：

• 服务描述：RESTful API （HTTP）、XML 配置（RPC）、IDL 文件（gRPC/Thrift）
• 注册中心：注册（服务提供者->注册中心）、订阅（服务消费者->注册中心）、返回（注册中心->服务消费者）、通知（注册中心->服务消费者）
• 服务框架：通讯框架、通讯协议、序列化和反序列化
• 服务监控（发现问题）：指标收集、数据处理、数据展示
• 服务追踪（定位问题）：RequestId传递
• 服务治理（解决问题）：单机故障-自动摘除、单IDC故障-自动切换、依赖服务不可用-熔断

接下来进行介绍这些组件。

服务描述

服务调用首先解决的问题就是服务如何对外描述。服务描述主要解决对外服务的服务名是什么，调用须要提供哪些信息，返回格式是什么以及如何进行解析。

经常使用的服务描述方式包括 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 配置方式的服务描述主要分三个步骤：

1. 服务提供者定义接口，并实现接口
2. 服务提供者进程启动时，经过加载 server.xml 配置文件将接口暴露出去。
3. 服务消费者进程启动时，经过加载 client.xml 配置文件引入要调用的接口。

IDL 文件方式一般用做 Thrift 和 gRPC 这类跨语言服务调用框架中，好比 gRPC 就是经过 Protobuf 文件来定义服务的接口名、参数以及返回值的数据结构。

服务描述方式比较

服务描述方式	使用场景	缺点
RESTful API	跨语言平台，组织内外都适用	相比 TCP，HTTP 做为通讯协议性能较差
XML 配置	Java 平台，通常用于组织内部	不支持跨语言平台
IDL 文件	跨语言平台，组织内外都适用	修改/删除 PB 字段不能向前兼容

注册中心

接下来要解决的问题就是服务的发布和订阅，也就是说你提供一个服务，如何让外部想调用这个服务的人知道。就须要注册中心出场了，服务提供者将本身提供的服务以及地址登记到注册中心，服务消费者则从注册中心查询所须要调用的服务的地址，而后发起请求。

在整个微服务架构中，注册中心是最基础的核心服务之一，它记录着服务和服务地址的映射关系，为服务提供方提供注册、注销功能，为服务消费方提供服务发现的功能。

注册中心通常的工做流程是：

• 服务提供者在启动时，根据服务发布文件中配置的发布信息向注册中心注册本身的服务。
• 服务消费者在启动时，根据消费者配置文件中配置的服务信息向注册中心订阅本身所须要的服务。
• 注册中心返回服务提供者地址列表给服务消费者。
• 当服务提供者发生变化，好比有节点新增或者销毁，注册中心将变动通知给服务消费者。

常见的注册中心有 Netflix 的 Eureka、HashiCorp 的 Consul、雅虎的 Zookeeper、阿里的 Nacos 等。

服务框架

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

• 服务通讯采用什么协议？就是说服务提供者和服务消费者之间以什么样的协议进行网络通讯，是采用四层 TCP、UDP 协议，仍是采用七层 HTTP 协议，仍是采用其余协议？
• 数据传输采用什么方式？就是说服务提供者和服务消费者之间的数据传输采用哪一种方式，是同步仍是异步，是在单链接上传输，仍是多路复用。
• 数据压缩采用什么格式？一般数据传输都会对数据进行压缩，来减小网络传输的数据量，从而减小带宽消耗和网络传输时间，好比常见的 JSON 序列化、Java 对象序列化以及 Protobuf 序列化等。

这三部分就组成了一个完成的 RPC 调用框架，通讯框架提供了基础的通讯能力，通讯协议描述了通讯契约，而序列化和反序列化则用于数据的编/解码。一个通讯框架能够适配多种通讯协议，也能够采用多种序列化和反序列化的格式。

• 通讯框架：解决客户端和服务端如何创建链接、管理链接以及服务端如何处理请求的问题。
• 通讯协议：解决客户端和服务端采用哪些数据传输协议的问题。
• 序列化和反序列化：解决客户端和服务端采用哪一种数据编码的问题。

服务监控

能够正常发起服务调用后，就须要对调用状况进行监控，以了解服务是否正常。一般来说，服务监控主要包括三个流程。

• 指标收集：把每一次服务调用的请求耗时以及成功与否收集起来，并上传到集中的数据处理中心。
• 数据处理：根据每次调用的请求耗时以及成功与否等信息，就能够计算每秒服务请求量、平均耗时以及成功率等指标。
• 数据展现：一般都是将数据展现在 Dashboard 面板上，而且每隔 10s 等间隔自动刷新，用做业务监控和报警等。

服务追踪

记录服务调用通过的每一层链路，以便进行问题追踪和故障定位。

服务追踪的工做原理大体以下：

• 服务消费者发起调用前，会在本地按照必定的规则生成一个 requestid，发起调用时，将 requestid 看成请求参数的一部分，传递给服务提供者。
• 服务提供者接收到请求后，记录下此次请求的 requestid，而后处理请求。若是服务提供者继续请求其余服务，会在本地再生成一个本身的 requestid，而后把这两个 requestid 都看成请求参数继续往下传递。

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

经常使用的服务追踪有 Twitter 的 Zipkin、华为的 skywalking、Uber 的 jaeger、大众点评的 CAT等。

服务治理

服务治理就是保证在各类意外状况下，服务调用仍然可以正常进行。

在生产环境中，常常会遇到下面几种状况：

• 单机故障：服务治理能够经过必定的策略，自动摘除故障节点，就能保证单机故障不会影响业务。
• 单 IDC 故障：服务治理能够经过自动切换故障 IDC 的流量到其余正常 IDC，能够避免由于单 IDC 故障引发的大批量业务受影响。
• 依赖服务不可用：服务治理能够经过熔断，在依赖服务异常的状况下，一段时期内中止发起调用而直接返回。既保证了服务消费者可以不被拖垮，也给服务提供者减小压力，使其可以尽快恢复。

还有其余服务治理的手段好比自动扩缩容、负载均衡、服务路由以及服务容错等。

总结

主要对微服务架构中的组件进行了介绍，微服务架构主要由服务描述、注册中心、服务框架、服务监控、服务追踪以及服务治理等组成。

参考

https://dwz.cn/FscvpObJ

https://dwz.cn/3PTGdySt