大家好，我是哪吒。

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

一、服务描述

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

常用的服务描述方式包括RESTful API、XML配置以及IDL文件三种。

其中，RESTful API方式通常用于HTTP协议的服务描述，并且常用Wiki或者Swagger来进行管理。

二、注册中心

服务提供者将自己的服务地址登记到注册中心，服务消费者从注册中心查询所需要调用的服务地址，然后发起请求。

一般来讲，注册中心的工作流程是：

1. 服务提供者在启动时，根据服务发布文件中配置的发布信息向注册中心注册自己的服务。
2. 服务消费者在启动时，根据消费者配置文件中配置的服务信息向注册中心订阅自己所需要的服务。
3. 注册中心返回服务提供者地址列表给服务消费者。
4. 当服务提供者发生变化，比如有节点新增或者销毁，注册中心将变更通知给服务消费者。

三、服务框架

服务消费者在发起调用之前要明确几个问题：

1、服务通信采用什么协议？

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

2、数据传输采用什么方式？

服务提供者和服务消费者之间的数据传输采用哪种方式，是同步还是异步，是单链接传输还是多路复用。

3、数据压缩采用什么形式？

通常数据传输都会对数据进行压缩，来减少网络传输的数据量，从而减少宽带消耗和网络传输时间，比如常见的JSON序列化、Java对象序列化和Protobuf序列化。

四、服务监控

通过服务监控，了解服务是否正常，服务监控的流程如下：

1、指标收集

把每次服务调用的请求耗时和接口情况收集起来，并上传到集中的数据处理中心。

2、数据处理

根据指标收集的数据，进行数据处理分析，计算每秒服务请求量、平均耗时以及成功率等指标。

3、数据展示

数据经过处理后，将数据展示在Dashboard面板上，并且每隔10s等间隔自动刷新，用作业务监控和报警等。

五、服务追踪

除了需要对服务调用情况进行监控之外，还需要记录服务调用经过的每一条链路，以及进行问题追踪和故障定位。

服务追踪的工作原理大致如下：

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

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

六、服务治理

服务治理就是通过一系列的手段来保证在各种意外情况下，服务调用仍然能够正常进行。

在生产环境中，你应该经常会遇到下面几种状况。

1、单机故障

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

2、单IDC故障

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

3、依赖服务不可用

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

七、服务发布和引用

想要构建微服务，首先要解决的问题是，服务提供者如何发布一个服务，服务消费者如何引用这个服务。具体来说，就是这个服务的接口名是什么？调用这个服务需要传递哪些参数？接口的返回值是什么类型？以及一些其他接口描述信息。

最常见的服务发布和引用的方式有三种：

1. RESTful API
2. XML配置
3. IDL文件

服务提供者如何发布一个服务，服务消费者如何引用这个服务，在微服务架构中，可以通过注册中心实现此功能。

八、注册中心

在微服务架构下，主要有三种角色：服务提供者（RPC Server）、服务消费者（RPC Client）和服务注册中心（Registry），三者的交互关系请看下面这张图，我来简单解释一下。

1. RPC Server提供服务，在启动时，根据服务发布文件server.xml中的配置的信息，向Registry注册自身服务，并向Registry定期发送心跳汇报存活状态。
2. RPC Client调用服务，在启动时，根据服务引用文件client.xml中配置的信息，向Registry订阅服务，把Registry返回的服务节点列表缓存在本地内存中，并与RPC Sever建立连接。
3. 当RPC Server节点发生变更时，Registry会同步变更，RPC Client感知后会刷新本地内存中缓存的服务节点列表。
4. RPC Client从本地缓存的服务节点列表中，基于负载均衡算法选择一台RPC Sever发起调用。

九、注册中心实现方式

注册中心的实现主要涉及几个问题：

1. 注册中心需要提供哪些接口，该如何部署；
2. 如何存储服务信息；
3. 如何监控服务提供者节点的存活；
4. 如果服务提供者节点有变化如何通知服务消费者，以及如何控制注册中心的访问权限。

1、注册中心API

1. 服务注册接口：服务提供者通过调用服务注册接口来完成服务注册。
2. 服务反注册接口：服务提供者通过调用服务反注册接口来完成服务注销。
3. 心跳汇报接口：服务提供者通过调用心跳汇报接口完成节点存活状态上报。
4. 服务订阅接口：服务消费者通过调用服务订阅接口完成服务订阅，获取可用的服务提供者节点列表。
5. 服务变更查询接口：服务消费者通过调用服务变更查询接口，获取最新的可用服务节点列表。

除此之外，为了便于管理，注册中心还必须提供一些后台管理的API，例如：

• 服务查询接口：查询注册中心当前注册了哪些服务信息。
• 服务修改接口：修改注册中心中某一服务的信息。

2、集群部署

注册中心作为服务提供者和服务消费者之间沟通的桥梁，它的重要性不言而喻。所以注册中心一般都是采用集群部署来保证高可用性，并通过分布式一致性协议来确保集群中不同节点之间的数据保持一致。

以开源注册中心ZooKeeper为例，ZooKeeper集群中包含多个节点，服务提供者和服务消费者可以同任意一个节点通信，因为它们的数据一定是相同的，这是为什么呢？这就要从ZooKeeper的工作原理说起：

1. 每个Server在内存中存储了一份数据，Client的读请求可以请求任意一个Server。
2. ZooKeeper启动时，将从实例中选举一个leader（Paxos协议）。
3. Leader负责处理数据更新等操作（ZAB协议）。
4. 一个更新操作成功，当且仅当大多数Server在内存中成功修改 。

通过上面这种方式，ZooKeeper保证了高可用性以及数据一致性。

3、目录存储

还是以ZooKeeper为例，注册中心存储服务信息一般采用层次化的目录结构：

• 每个目录在ZooKeeper中叫作znode，并且其有一个唯一的路径标识。
• znode可以包含数据和子znode。
• znode中的数据可以有多个版本，比如某一个znode下存有多个数据版本，那么查询这个路径下的数据需带上版本信息。

4、服务健康状态检测

注册中心除了要支持最基本的服务注册和服务订阅功能，还必须具备对服务提供者节点的健康状态检测功能，这样才能保证注册中心里保存的服务节点都是可用的。

以Zookeeper为例，它是基于Zookeeper客户端和服务端的长连接和会话超时控制机制，来实现服务监控状况检测的。

在Zookeeper中，客户端和服务端建立连接后，会话也随之建立，并生成一个全局唯一的Seesion ID。服务端和客户端维持的是一个长链接，在SESSION_TIMEOUT的周期内，服务端会检测与客户端的链路是否正常，具体的方式是通过客户端定时向服务端发送心跳消息（ping消息），服务器重置下次SESSION_TIMEOUT时间。如果超过SESSION_TIMEOUT后服务端都没有收到客户端的心跳消息，则服务端就会认为这个session已经结束了。Zookeepr就会认为这个服务节点已经不可用，将从注册中心中删除此接口。

5、服务状态变更通知

一旦注册中心探测到服务提供者节点新加入或者被剔除，就必须立刻通知所有订阅该服务的服务消费者，刷新本地缓存的服务节点信息，确保服务调用不会请求不可用的服务提供者节点。

以Zookeeper为例，基于Zookeeper的Watcher机制，来实现服务状态变更通知给服务消费者。服务消费者在调用Zookeeper的getData()方法订阅服务时，还可以通过监听器Watcher的process方法获取服务的变更，然后调用getData()方法来获取变更后的数据，刷新本地缓存的服务节点信息。

6、白名单机制

注册中心提供白名单机制，只有在白名单中的RPC Server才能够调用注册中心中的接口，这样的话可以避免测试环境中的节点意外跑到线上环境中去。

十、总结

注册中心可以说是微服务的关键，服务提供者和服务消费者不在同一个进程中运行，实现了解耦。

服务提供者可以随意增加和删除节点，通过健康状态检测，注册中心可以保持最新的服务节点信息，并将变化通知给订阅服务的服务消费者。

注册中心一般采用分布式集群部署，来保证高可用性，并且为了实现异地多活，有的注册中心还采用多IDC部署，这对数据一致性产生了很高的要求，这些都是注册中心在实现时必要要解决的问题。

上一篇：微服务架构之路1，服务如何拆分？使用微服务的注意事项？

🏆哪吒多年工作总结：Java学习路线总结，搬砖工逆袭Java架构师。

华为OD机试 2023B卷题库疯狂收录中，刷题点这里

刷的越多，抽中的概率越大，每一题都有详细的答题思路、详细的代码注释、样例测试，发现新题目，随时更新，全天CSDN在线答疑。