一文快速了解微服务架构

服务提供者按照一定格式的服务描述，向注册中心注册服务，声明自己能够提供哪些服务及服务的地址是什么，完成服务发布。

服务消费者请求注册中心，查询所需要调用服务的地址，然后以约定的通信协议向服务提供者发起请求，得到请求结果后再按照约定的协议解析结果。

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

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

1、服务描述

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

常用的服务描述方式包括 RESTful API、XML 配置及 IDL 文件 3 种。其中，XML 配置方式多用作 RPC 协议的服务描述，通过*.xml 配置文件来定义接口名、参数及返回值类型等。IDL 文件方式通常用作 Thrift 和 gRPC 这类跨语言服务调用框架中，如 gRPC 就是通过 Protobuf 文件来定义服务的接口名、参数及返回值的数据结构。

2、注册中心

单体应用由于部署在同一个 WAR 包里，接口之间的调用属于进程内的调用。而拆分为微服务独立部署后，服务提供者该如何对外暴露自己的地址，服务调用者该如何查询所需要调用的服务的地址呢？此时就需要一个类似登记处的地方，能够记录每个服务提供者的地址以供服务调用者查询，在微服务架构里，这个地方就是注册中心。

如果用户提供了一个服务，要想让外部想调用这项服务的人知道，就需要一个类似注册中心的角色，服务提供者将自己提供的服务及地址登记到注册中心，服务消费者则从注册中心查询所需要调用的服务的地址，然后发起请求。

一般来讲，注册中心的工作流程如下。

1. 服务提供者在启动时，根据服务发布文件中配置的发布信息向注册中心注册自己的服务。

2. 服务消费者在启动时，根据消费者配置文件中配置的服务信息向注册中心订阅自己所需要的服务。

3. 注册中心返回服务提供者地址列表给服务消费者。

4. 当服务提供者发生变化，如有节点新增或者销毁，注册中心将变更通知给服务消费者。

3、服务框架

对于单体应用来说，不同功能模块之间相互交互时，通常是以类库的方式来提供各个模块的功能。对于微服务来说，每个服务都运行在各自的进程中，应该以何种形式向外界传达自己的信息呢？答案就是接口，无论采用哪种通信协议（HTTP 或者 RPC），服务之间的调用都通过接口描述来约定，约定内容包括接口名、接口参数及接口返回值。

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

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

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

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

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

4、服务监控

通常对于一个服务，人们最关心的是 QPS（调用量）、AvgTime（平均耗时）及 P999（99.9%的请求响应时间在多少毫秒以内）等指标。

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

1. 指标收集：就是把每一次服务调用的请求耗时及成功与否收集起来，并上传到集中的数据处理中心。

2. 数据处理：有了每次调用的请求耗时及成功与否等信息，就可以计算每秒服务请求量、平均耗时及成功率等指标。

3. 数据展示：数据收集起来，经过处理后，还需要以友好的方式对外展示，才能发挥价值。通常都是将数据展示在 Dashboard 面板上，并且每隔 10 秒等间隔自动刷新，用作业务监控和报警等。

5、服务追踪

在单体应用拆分为微服务后，一次用户调用可能依赖多个服务，每个服务又部署在不同的节点上，如果用户调用出现问题，则需要有一种解决方案能够将一次用户请求进行标记，并在多个依赖的服务系统中继续传递，以便串联所有路径，从而进行故障定位。

微服务中服务追踪的工作原理大致如下。

1. 服务消费者发起调用前，会在本地按照一定的规则生成一个 requestid，发起调用时，将 requestid 当作请求参数的一部分，传递给服务提供者。

2. 服务提供者接收到请求后，记录下这次请求的 requestid，然后处理请求。如果服务提供者继续请求其他服务，会在本地再生成一个自己的 requestid，然后把这两个 requestid 都当作请求参数继续往下传递。以此类推，通过这种层层往下传递的方式，一次请求，无论最后依赖多少次服务调用、经过多少服务节点，都可以通过最开始生成的 requestid 串联所有节点，从而达到服务追踪的目的。

6、服务治理

可以想象，拆分为微服务架构后，服务的数量变多了，依赖关系也变复杂了。比如一个服务的性能有问题时，依赖的服务都势必会受到影响。可以设定一个调用性能阈值，如果一段时间内一直超过这个值，那么依赖服务的调用可以直接返回，这就是熔断，也是服务治理最常用的手段之一。

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

• 单机故障。通常遇到单机故障后，都是靠运维发现并重启服务或者从线上摘除故障节点。然而集群的规模越大，越容易遇到单机故障，在机器规模超过 100 台以上时，仅靠传统的人工运维显然难以应对。而服务治理可以通过一定的策略，自动摘除故障节点，不需要人为干预，就能保证单机故障不会影响业务。

• 单 IDC 故障。大家或许经常听说某某 App，因为施工挖断光缆导致大批量用户无法使用的严重故障。而服务治理可以通过自动切换故障 IDC 的流量到其他正常 IDC，从而避免因为单 IDC 故障引起的大批量业务受到影响。

• 依赖服务不可用。如果你的服务依赖于另一个服务，当另一个服务出现问题时，会拖慢甚至拖垮你的服务。而服务治理可以通过熔断，在依赖服务异常的情况下，一段时期内停止发起调用而直接返回。这样一方面保证了服务消费者能够不被拖垮，另一方面也给服务提供者减少了压力，使其能够尽快恢复。

微服务是松藕合的，无论是在开发阶段还是部署阶段都是独立的。(能够快速响应，局部修改容易，一个服务出现问题不会影响整个应用。易于和第三方应用系统集成，支持使用不同的语言开发，允许融合最新技术。

每个微服务都很小，足够内聚，足够小，代码容易理解。团队能够更关注自己的工作成果，聚焦指定的业务功能或业务需求。但也带来了过多的运维操作，可能需要团队具备一定的 DevOps 技巧。当服务数量增加后，管理复杂性也会增加。