微服务架构下多服务间通信，需要解决的一个问题就是如何实现服务发现。本文将从为什么需要服务发现、什么是服务发现、如何实现服务发现等四个方面对其进行简要介绍。
为什么需要服务发现在进行服务间调用时，一个服务需要知道另一个服务的网络位置(IP地址和端口)。在物理硬件上运行的应用来书，服务实例的网络位置通常是静态的。但在云原生时代，通常不那么简单。在基于云构建的服务实例，其网络位置更具动态性。示例如下图：
以上图为例，在基于云创建服务实例时，服务实例具有动态分配的IP地址。因为服务实例可以在任一时刻创建或销毁，所以无法让某一服务实例占用固定IP，而是每次服务创建时随机使用一个IP，服务销毁时回收这个IP。
服务调用方无法通过配置IP地址的方式访问服务提供方的接口。相反，应用或基础设施需提供动态服务发现机制。服务发现在概念上非常简单：服务发现的关键组件是服务注册表，它是包含服务实例网络位置信息的一个数据库。
服务实例启动或停止时，服务发现机制会更新服务注册表。当客户端调用服务器时，服务发现机制会查询服务注册表，以获取可用服务实例的列表，并将请求路由到其中一个服务实例。细心的同学可以发现，这块原理与DNS类似。其实，服务发现原理就是借鉴DNS原理实现。
实现服务发现有以下两种主要方式：
(1) 服务调用方和服务提供方直接与服务注册表交互，也即应用层服务发现模式。
(2) 通过部署基础设施来处理服务发现，也即平台层服务发现模式。
实现服务发现的一种方法是服务调用方和服务提供方直接与服务注册表交互。服务提供方使用服务注册表注册其网络位置。服务调用方首先通过查询服务注册表获取服务实例列表来调用服务，然后向其中一个实例发送请求。示例如下：
从上图可知，服务实例在初始化时，会调用注册API向服务注册表来注册其网络位置。另外，服务注册表还可能要求服务实例定期调用心跳API以防止其注册过期。当服务调用方需要调用服务接口时，它会查询服务注册表以获取服务实例的列表。然后服务调用方使用负载均衡算法来选择服务实例。接着它向已选择的服务实例发出请求。
在微服务架构发展的早期，应用层服务发现模式获得极大推广。主流的应用层服务发现组件有Netflix的Eureka。这也是Spring Cloud框架之前默认的服务发现组件(Eureka现在已停止维护)。
应用层服务发现的一个优势是它可以处理多平台部署的问题(服务发现机制与底层部署的平台无关)。
应用层服务发现的一个劣势是每个服务发现库都是语言或框架相关的。如Eureka只能帮助基于Java开发人员。如果需要使用GoLang或其他语言，则必须使用其他服务发现组件。
实现服务发现的另一种方法是通过部署基础设施来处理服务发现。许多现代部署平台(如Docker和Kubernetes)都具有内置的服务注册表和服务发现机制。部署平台为每个服务提供DNS名称、虚拟IP(VIP)和解析为VIP地址的DNS名称。服务调用方向DNS名称和VIP发出请求，部署平台自动将请求路由到其中一个可用服务实例。因此，服务注册、服务发现和请求路由完全由部署平台处理。示例如下：
部署平台包括一个服务注册表，用于跟踪已部署服务的IP地址。当服务启动后，部署平台的注册器将服务实例的地址写入注册表。每个服务都有一个网络位置、一个DNS名称和虚拟IP地址。服务调用方向部署平台的路由器请求服务提供方的网络位置。然后部署平台的路由器查询注册表并在可用服务实例之间负载均衡请求。
由平台提供服务发现机制的主要好处是服务发现的所有方面都完全由部署平台处理。服务提供方和服务调用方都不包含任何服务发现代码。因此，无论使用哪种语言或框架，服务发现机制都可供所有服务提供方和服务调用方使用。
平台提供服务发现机制的一个劣处是它仅限于支持使用该平台部署的服务。如基于Kubernets的发现仅适用于在Kubernets上运行的服务。
从微服务架构的发展来看，平台层服务发现模式已经成功业内主流，笔者参与的云服务开发，就是基于平台层服务发现模式。
微服务设计 Sam Newman 著, 崔力强 等 译
微服务架构设计模式 Chris Richardson 著, 陈斌 等 译
https://itdks.su.bcebos.com/307ea09e7ef34bbfa58b845bf0f3d74b.pdf 微服务架构开发及平台演进
