微服务架构的服务发现机制

本文作者：IMWeb Jianglinyuan 原文出处：IMWeb社区 未经同意，禁止转载

微服务架构的服务发现机制

分布式微服务系统架构其最大一个特性即分布式，所以如何知道每个独立的微服务的服务器地址、端口、以及其他相关信息呢？同时，相对于传统分布式系统的部署：相关独立业务逻辑系统的部署都是在固定并且已知的位置（服务器地址与端口），现代分布式微服务的应用程序通常部署在虚拟化或者容器化环境当中。在这样的前提下，每个独立微服务的实例数量以及其位置都是动态变化的。所以服务发现机制在一套分布式微服务系统架构中显得尤为重要。

常用的服务发现机制分为两种：客户端服务发现与服务端服务发现。

简而言之客户端服务发现即由客户端负责决定可用的服务实例的"位置"以及与其相关的负载均衡策略。

无论使用客户端服务发现或者服务端服务发现都需要拥有一个服务注册中心，客户端对微服务的"位置"的获取就是通过与服务注册中心。服务注册中心作为微服务架构最基础也是最重要的组件之一，服务注册中心的本质上市为了解耦服务提供者和服务消费者之间的关系。在客户端服务发现的模式下，客户端首先会跟服务注册中心交互，然在客户端使用一个相关的负载均衡算法决定去选择哪一个微服务实例。

客户端服务发现模式的主要优点是其相对直接，除了服务注册表并没有其他动态管理的部分了。而且，由于客户端知道可用的服务实例，所以可以做到智能的、应用明确的负载均衡策略，比如Hash算法。而其主要的弊端在于客户端与服务注册中心的注册表是一一对应的，必须要为服务客户端用到的每一种编程语言和框架实现客户端服务发现的逻辑。

服务端服务发现相对于客户端服务发现最大的不同是：其将客户端的与服务发现相关的逻辑搬离到了负载均衡层来做。客户端所有的请求只会通过负载均衡模块，其并不需要知会微服务实例在哪里，地址是多少。负载均衡模块会查询服务注册中心，并将客户端的请求路由到相关可用的微服务实例上。

服务端服务发现主要的优势是在这种设计模式下，服务发现的相关逻辑和细节可以从客户端完全抽离出来，客户端只需要向负载均衡模块发送请求，不需要为服务客户端使用的每一种语言和框架来实现相关逻辑。同时，这样做对前后端逻辑分离是非常友好的，前端还是关注整套业务系统的相关逻辑，而不用考虑太多后端的东西。这对一套业务系统的维护和开发都是有优势的。服务端服务发现的主要缺点是在这种模式下，相对于客户端服务发现，它需要另一个高可用、高性能的系统组件。

API网关Kong就是与服务端服务发现机制相呼应的。Kong就包含了负载均衡模块用来接收来自客户端的请求，Kong和服务注册中心交互得到相应的具体的微服务实例的"位置"。设计或者选型一个服务注册中心，首先要考虑的就是服务注册和发现机制。纵观当下各种主流的服务注册中心的解决方案，大致可以归为一下三类：

• 应用内：直接集成到应用中，依赖于应用自身完成服务的注册和发现，最典型的就是Netflix提供的Eureka。
• 应用外：把应用当成黑盒，通过应用外的某种机制将服务注册到注册中心，最小化对应用的侵入性，比如Airbnb的Smartstack，HashiCorp的Consul。
• DNS：将服务注册为DNS的SRV记录，严格的来说，是一种特殊的应用外注册方式，SkyDNS就是其中最具有代表性的杰作。