在【微服务的基础设施】(https://www . howardliu . cn/the-base-of-Microservice/)中提到，在云原生和微服务时代，手动修改服务地址几乎是不可能的，需要一种机制来完成自动上报和获取服务地址的支撑组件，能够保证线上线下的快速服务，即服务注册。

为了便于表达，从系统规模定义了几个阶段:

-Mega-application architecture时期:很多应用是一个巨型服务，一个应用包含所有功能，部署在小型机和大型机上，或者直接部署在物理服务器上。

-单一架构时期:应用数量减少，服务数量增加，虚拟化技术出现。物理服务器连接到虚拟化平台，应用程序部署在虚拟机中。

-SOA架构时期:应用常用功能逐渐沉淀，业务应用借助沉淀的常用组件逐渐解耦，微服务的很多组件也是从这个时期开始成型的。

-微服务架构时期:这个时期继承了模块化时期，甚至有一种说法认为微服务只是SOA的一种特殊形式。系统进一步解耦。根据不同的业务角色，应用以业务为边界，还原为业务单元。

-功能架构期:应用进一步划分功能实现无服务器架构，没有具体的服务器概念，只需要执行功能的服务。目前，这个时期是一个理想的时期，因为不同的人在相互合作中定义的功能可能会重复或冲突，这不利于架构的演进。

随着大家对微服务或者功能架构的关注，很多人开始提出回归单一应用架构，这应该也是架构螺旋式进步的一种方式。

在微服务中，还有一个根据调用关系定义的角色:

微服务中，客户端和服务端只定义一个调用，其他调用关系中客户端的角色可能会改为服务端。

说到服务发现，必须要说一个重要的组件: Service Registry ，它是服务发现的核心，是包含所有服务实例的网络位置和监控状态的数据库。通过服务注册组件将信息写入服务注册表，通过服务发现组件获取服务实例的有效网络位置信息。目前常用的服务注册中心有:Eureka、etcd、Consul、Zookeeper、Kibernetes等镜像调度服务，没有明确的服务注册中心组件，通过内置的服务注册功能实现。对于F5和Nginx这样的代理，上游配置也属于服务注册中心。

在微服务架构中，服务通过轻量级协议相互调用，通常是HTTP请求。为了完成请求，服务需要知道目标服务实例的网络位置(IP和端口)。

在巨型应用架构时代，配置一个符合要求的服务器环境需要花费大量的时间，这意味着服务地址变化的概率和频率非常低，很多应用部署在小型机或大型机上。单一架构时期，应用数量多，地址变化时修改的地方少，对服务发现没有强烈需求。换句话说，在单一架构之前，服务实例的相对位置是固定的，变化频率低，可以硬编码到代码中。

然而，在云时代，服务器环境的配置变得简单，服务器的数量逐渐增加，扩展和迁移变得更加频繁。而且随着虚拟化和容器的应用，服务器地址按照规则动态分配，服务的网络位置甚至由于服务升级、扩展和故障回滚的增加而不可预测。此时，必须使用服务发现机制来确保客户端服务可以自动获取服务器服务的地址。

通常，服务发现有两种模式:客户端发现模式和服务器发现模式。

客户端发现模式

客户端发现模式根据负载均衡算法通过客户端组件确定相应服务实例的网络位置，也就是说，客户端组件存储服务器所有实例的服务注册表，当调用发生时，根据负载均衡算法，从服务注册表中选择一个网络位置，向服务器发出请求完成调用。由于网络的不可靠性，一些客户端组件还可以实现访问失败重试、设置访问超时等功能。

该模式的架构如下:

具体流程如下:

在Spring Cloud(或网飞开源组件)中，Eureka服务器组件相当于服务注册器，Eureka客户端组件实现服务注册，Ribbon实现负载平衡算法和重试策略。

客户端发现模式既有优点也有缺点。优点是对现有服务友好，除了客户端组件，其他部分不需要更改。此外，客户端存储所有服务实例信息，因此可以有针对性地定义负载平衡算法。缺点是客户端被绑定到服务注册器，并且需要为每种语言实现不同的客户端组件。

服务器发现模式

服务器发现模式是有一个单独的服务发现组件，它保存服务注册表，还充当负载平衡器。客户端调用服务器时，直接调用服务发现实例，并通过服务实例代理给后端服务实例，所以服务器发现模式也叫代理模式。

该模式的架构如下:

具体流程如下:

有两种方法可以在服务器发现模式下实现服务发现组件:

两种实现的优点是语言无关，客户端不需要关心服务发现的任何细节，只需要修改调用实例的原始请求就可以向服务发现实例发送请求。集中式代理的缺点是存在单点问题，一个高可用高吞吐量的系统服务需要单独部署，从一个调用增加到两个调用，有性能开销。主机流程代理的缺点是运维复杂，需要一个称职的运维团队的支持。

服务注册是将服务实例的网络信息和健康状态写入服务注册表。有两种方式:自助注册模式和第三方注册模式。

自注册模式

在这种模式下，服务实例主动向服务注册中心报告网络位置和健康状态，在一些实现中，服务实例还通过心跳保证注册信息不会过期。

尤里卡采用这种方法。服务实例通过Eureka客户端组件主动报告它们的网络位置信息和健康状态。

这种模式实现起来相对简单，但是将服务实例与服务注册中心耦合起来有明显的优点和缺点。

第三方注册模式

第三方注册模式是服务实例不需要直接向服务注册中心注册信息，而是借助一个叫做注册器的组件进行注册。服务注册器通过扫描部署环境或订阅事件来跟踪服务实例的变化。当检测到服务实例变化时，变化信息将被报告给服务注册中心。

这种方法可以将服务实例与服务注册中心解耦，同时也引入了其他问题。也就是说，注册器需要内置到部署环境中，这增加了操作和维护的复杂性。或者注册商需要部署集中式管理组件，成为系统约束点。

在微服务中，服务实例的运行环境会动态变化，实例的网络位置也会动态变化。因此，客户端必须使用服务发现机制来访问服务。

服务发现有客户端发现模式和服务器端发现模式，服务注册有自注册模式和第三方注册模式。服务发现和服务注册通过服务注册中心联系在一起。

后面我会补充目前常用的服务发现和服务注册的相关组件。

个人博文:https://www.howardliu.cn/service-registry-and-discovery/