疯狂架构师最强分享：分布式架构与性能优化，你学会了吗？

分布式系统在如今越来越普及，了解分布式系统中的原理与实现更是很重要，本系列从分布式原理以及性能优化角度来剖析分布式架构

彻底搞通服务发现的原理和实现

服务发现，作为互联网从业人员，大家应该都不陌生，一个完善的服务集群，微服务是必不可少的功能之一。

最近一直想写这个话题，也一直在构思，但不知道从何入手，或者说不知道写哪方面。如果单纯写如何实现，这个未免太乏味枯燥了；而如果只是介绍现有成熟方案呢，却达不到我的目的。想了很久，准备先从微服务的架构入手，切入 服务发现 要解决什么问题，搭配常见的处理模式，最后介绍下现有的处理方案。

微服务服务于分布式系统，是个分散式系统。服务部署跨主机、网段、机房乃至大区。各个服务之间通过 RPC(remote procedure call)进行调用。然后，在架构上最重要的一环，就是服务发现。如果说服务发现是微服务架构的灵魂也当之无愧，试想一下，当一个系统被拆分成多个服务，且被大量部署的时候，有什么能比"找到"想调用的服务在哪里，以及能否正常提供服务重要呢？同样的，有新服务启动时，如何让其他服务知道该服务在哪里？

微服务考研的是治理大量服务的能力，包含多种服务，同样也包含多个实例。

概念

服务发现之所以重要，是因为它解决了微服务架构最关键的问题：如何精准的定位需要调用的服务 ip 以及端口。无论使用哪种方式来提供服务发现功能，大致上都包含以下三点：

• Register, 服务启动时候进行注册
• Query, 查询已注册服务信息
• Healthy Check,确认服务状态是否健康

整个过程很简单。大致就是在服务启动的时候，先去进行注册，并且定时反馈本身功能是否正常。由服务发现机制统一负责维护一份正确或者可用的服务清单。因此，服务本身需要能随时接受查下，反馈调用方服务所要的信息。

注册模式

一整套服务发现机制顺利运行，首先就得维护一份可用的服务列表。包含服务注册与移除功能，以及健康检查。服务是如何向注册中心"宣告"自身的存在？健康检查，是如何确认这些服务是可用的呢？

做法大致分为两类：

• 自注册模式自注册，顾名思义，就是上述这些动作，有服务(client)本身来维护。每个服务启动后，需要到统一的服务注册中心进行注册登记，服务正常终止后，也可以到注册中心移除自身的注册记录。在服务执行过程中，通过不断的发送心跳信息，来通知注册中心，本服务运行正常。注册中心只要超过一定的时间没有收到心跳消息，就可以将这个服务状态判断为异常，进而移除该服务的注册记录。
• 三方注册模式这个模式与自注册模式相比，区别就是健康检查的动作不是有服务本身(client)来负责，而是由其它第三方服务来确认。有时候服务自身发送心跳信息的方式并不精确，因为可能服务本身已经存在故障，某些接口功能不可用，但仍然可以不断的发送心跳信息，导致注册中心没有发觉该服务已经异常，从而源源不断的将流量打到已经异常的服务上来。

这时候，要确认服务是否正常运转的健康检查机制，就不能只依靠心跳，必须通过其它第三方的验证(ping)，不断的从外部来确认服务本身的健康状态。

这些都是有助于协助注册中心提高服务列表精确到的方法。能越精确的提高服务清单状态的可靠性，整套微服务架构的可靠度就会更高。这些方法不是互斥的，在必要的时候，可以搭配使用。

发现模式

服务发现的发现机制主要包括三种：

• 服务提供者：服务启动时将服务信息注册到注册中心，服务退出时将注册中心的服务信息删除掉。
• 服务消费者：从服务注册表获取服务提供者的最新网络位置等服务信息，维护与服务提供者之间的通信。
• 注册中心：服务提供者和服务消费者之间的一个桥梁

服务发现机制的关键部分是注册中心。注册中心提供管理和查询服务注册信息的 API。当服务提供者的实例发生变更时（新增/删除服务），服务注册表更新最新的状态列表，并将其最新列表以适当的方式通知给服务消费者。目前大多数的微服务框架使用 Netflix Eureka、Etcd、Consul 或 Apache Zookeeper 等作为注册中心。

为了说明服务发现模式是如何解决微服务实例地址动态变化的问题，下面介绍两种主要的服务发现模式：

• 客户端发现模式
• 服务端发现模式。

客户端模式与服务端模式，两者的本质区别在于，客户端是否保存服务列表信息。

客户端发现模式

在客户端模式下，如果要进行微服务调用，首先要进行的是到服务注册中心获取服务列表，然后再根据调用端本地的负载均衡策略，进行服务调用。

在上图中，client 端提供了负载均衡的功能，其首先从注册中心获取服务提供者的列表，然后通过自身负载均衡算法，选择一个最合理的服务提供者进行调用:

1、 服务提供者向注册中心进行注册，提交自己的相关信息

2、 服务消费者定期从注册中心获取服务提供者列表

3、 服务消费者通过自身的负载均衡算法，在服务提供者列表里面选择一个合适的服务提供者，进行访问

客户端发现模式的优缺点如下：

• 优点：
• 负载均衡作为 client 中一个功能，用自身的算法，从服务提供者列表中选择一个合适服务提供者进行访问，因此 client 端可以定制化负载均衡算法。优点是服务客户端可以灵活、智能地制定负载均衡策略，包括轮询、加权轮询、一致性哈希等策略。
• 可以实现点对点的网状通讯，即去中心化的通讯。可以有效避开单点造成的性能瓶颈和可靠性下降等问题。
• 服务客户端通常以 SDK 的方式直接引入到项目，这种方式语言的整合程度最佳，程序执行性能最佳，程序错误排查更加容易。
• 缺点：
• 当负载均衡算法需要更新时候，很难做到同一时间全部更新，所以就造成新旧算法同时运行
• 与注册中心紧密耦合，如果要换注册中心，需要去修改代码，重新上线。微服务的规模越大，服务更新越困难，这在一定程度上违背了微服务架构提倡的技术独立性。

目前来说，大部分服务发现的实现都采取了客户端模式。

服务端发现模式

在服务端模式下，调用方直接向服务注册中心进行请求，服务注册中心再通过自身负载均衡策略，对微服务进行调用。这个模式下，调用方不需要在自身节点维护服务发现逻辑以及服务注册信息。

在服务端模式下：1、 服务提供者向注册中心进行服务注册 2、 注册中心提供负载均衡功能，3、 服务消费者去请求注册中心，由注册中心根据服务提供列表的健康情况，选择合适的服务提供者供服务消费者调用

现代容器化部署平台（如 Docker 和 Kubernetes）就是服务端服务发现模式的一个例子，这些部署平台都具有内置的服务注册表和服务发现机制。容器化部署平台为每个服务提供路由请求的能力。服务客户端向路由器（或者负载均衡器）发出请求，容器化部署平台自动将请求路由到目标服务一个可用的服务实例。因此，服务注册，服务发现和请求路由完全由容器化部署平台处理。

服务端发现模式的特点如下：

• 优点：
• 服务消费者不需要关心服务提供者的列表，以及其采取何种负载均衡策略
• 负载均衡策略的改变，只需要注册中心修改就行，不会出现新老算法同时存在的现象
• 服务提供者上下线，对于服务消费者来说无感知
• 缺点：
• rt 增加，因为每次请求都要请求注