在 微服务的基建工作 中提到过，在云原生、微服务时代，如果还是手动修改服务地址，是几乎不可完成的工作，需要一种机制完成自动上报和获取服务地址的支撑组件，可以保障服务的快速上线和下线，这就是服务注册/发现组件。
为了表述方便，从系统规模定义几个阶段：
- 巨型应用架构时期：很多应用都是一个巨型服务，一个应用包含所有功能，部署在小型机和大型机上，或者直接部署在物理服务器上。
- 单体架构时期：应用体量缩小，服务增多，而且出现虚拟化技术，物理服务器被连接成虚拟化平台，应用部署在虚拟机中。
- SOA架构时期：应用通用功能逐渐沉淀，业务应用借助沉淀的通用组件逐渐解耦，微服务的很多组件也是从这个时期开始成型。
- 微服务架构时期：这个时期承接模块化时期，甚至有一种说法是微服务只是SOA的一种特殊形式。系统进一步解耦，根据业务角色不同，应用以业务为分界，缩小为业务单元。
- 函数架构时期：应用进一步分割为函数，实现serverless架构，不需要具体的服务器概念，只需要执行函数的服务即可。目前来看，这个时期是比较理想的时期，因为不同人相互协作定义的函数，可能重复或者冲突，不利于架构的演进。
随着大家对在微服务或者函数架构中趟坑，很多人开始提出回归单体应用架构，这应该也是架构螺旋进步的一种方式。
在微服务中，还有一种角色是根据调用关系定义的：
- 客户端服务（简称客户端）：调用其他服务的实例
- 服务端服务（简称服务端）：被其他服务实例调用的实例
微服务中客户端和服务端只对一个调用定义的，客户端在其他调用关系中，角色可能会转变为服务端。
服务注册表
说到服务发现时，必须要说一个重要组件：服务注册表，它是服务发现的核心，是一个包含了所有服务实例的网络位置和监控状态的数据库，通过服务注册组件将信息写入服务注册表，通过服务发现组件获取有效的服务实例的网络位置信息。目前常用的服务注册表有：Eureka、etcd、Consul、Zookeeper，Kibernetes等镜像调度服务没有明确的服务注册表组件，是通过内置的服务注册功能实现。对于比如F5和Nginx这种代理器，其中的upstream配置也属于服务注册表。
服务发现
在微服务架构中，服务之间通过轻量级协议互相调用，一般是HTTP请求，为了完成一次请求，服务需要知道目标服务实例的网络位置（IP和端口）。
在巨型应用架构时期，配置一个符合要求的服务器环境需要花费大量的时间，也就意味着服务地址发生变动的概率和频率都非常低，而且很多应用部署在一台小型机或者大型机上。到了单体架构时期，应用体量大数量少，发生地址变动所需要修改的地方就比较少，所以对于服务发现也就没有那么强的需求。换句话说，在单体架构之前，服务实例的相对位置固定，变动频率低，可以通过硬编码到代码中。
但是到了云时代，服务器环境配置变得简单，数量逐渐增多，扩展和迁移逐渐频繁。而且，随着虚拟化和容器的应用，服务器地址都是根据规则动态分配，由于服务升级、扩展、失败回滚等情况增多，服务的网络位置甚至不可预知。这个时候必须使用服务发现机制保证客户端服务能够自动获取服务端服务的地址。
通常，服务发现有两种模式：客户端发现模式、服务端发现模式。
客户端发现模式
客户端发现模式通过客户端组件根据负载均衡算法决定相应服务实例的网络位置，也就是说，客户端组件保存有服务端所有实例的服务注册表，调用发生时，根据负载均衡算法，从服务注册表中选择一个网络位置，向服务端发起请求，完成调用。由于网络的不可靠性，有的客户端组件还会实现访问失败重试、访问超时时间设定等功能。
这种模式的架构如图：
具体的过程为：
- 服务实例向服务注册器上报网络位置，即注册
- 客户端服务发现组件定时拉取服务注册器中服务实例的网络位置信息及健康状态，保存在服务注册表中
- 客户端服务调用服务端服务时，通过客户端服务发现组件，根据负载均衡算法，选取可用一个服务实例，发起调用
在Spring Cloud（或者说是Netflix开源组件）中，组件Eureka Server组件相当于服务注册器，Eureka Client组件实现了服务注册表，Ribbon实现了负载均衡算法和重试策略。
客户端发现模式优缺点兼备。优点是对已有服务友好，除了客户端组件外，其他部分无需改动。而且，客户端存有所有服务实例信息，可以有针对性的定义负载均衡算法。缺点是客户端与服务注册器绑定，需要针对每种语言实现不同的客户端组件。
服务端发现模式
服务端发现模式是有一个单独的服务发现组件，这个实例持有服务注册表，同时也起到负载均衡器的作用，客户端调用服务端时，直接调用服务发现实例，通过服务实例代理到后端服务实例中，所以服务端发现模式也被称为代理模式。
这种模式的架构如图：
具体的过程为：
- 服务实例向服务注册器上报网络位置，即注册
- 服务发现实例定时通过某种机制获取服务注册器中服务实例的网络位置信息及健康状态，保存在服务注册表中
- 客户端服务调用服务端服务时，直接调用服务发现实例，服务发现实例根据内部实现，查询服务注册表，将请求代理到后端服务实例
服务端发现模式中的服务发现组件有两种实现方式：
- 第一种，集中式代理，服务发现组件是单独的服务实例，这个实例是高可用高吞吐的系统组件，代理后端服务实例，代表性的是F5和Nginx。
- 第二种，主机进程代理，服务发现组件由系统环境提供，集成在主机上或者集成在操作系统中，代表性的是Istio ServiceMesh。
两种实现方式的优点是语言无关，客户端不需要关心任何服务发现的细节，只需要将原有的调用实例的请求修改为向服务发现实例发送请求。集中式代理的缺点是，存在单点问题，需要单独部署一个高可用、高吞吐的系统服务，由原来的一次调用增加为两次调用，有性能开销。主机进程代理的缺点是运维复杂，需要能力强的运维团队做支持。
服务注册
服务注册是将服务实例的网络信息和健康状态写入服务注册表中，有两种方式：自注册模式、第三方注册模式。
自注册模式
这种模式是服务实例主动向服务注册表上报网络位置和健康状态，有的实现中，服务实例还会通过心跳保障注册信息不会过期。
Eureka就是采用的这种方式，服务实例通过Eureka Client组件主动上报自己的网络位置信息和健康状态。
这种模式实现相对简单，但是把服务实例和服务注册表耦合，优缺点明显。
第三方注册模式
第三方注册模式是服务实例不需要直接向服务注册表注册信息，而是借助被称为注册器的组件进行注册。服务注册器是通过扫描部署环境或者订阅事件的方式，跟踪服务实例的变更。当监测到服务实例有变化，会向服务注册表上报变化信息。
这种方式可以将服务实例与服务注册表解耦，同时也引入另外的问题。即注册器需要内置在部署环境中，增加了运维复杂性。或者注册器需要部署一个集中式的管理组件，成为系统约束点。
未完待续
在微服务中，服务实例的运行环境会动态变化，实例网络位置也是如此，因此，客户端为了访问服务必须要使用服务发现机制。
服务发现有客户端发现模式和服务端发现模式，服务注册有自注册模式和第三方注册模式。服务发现和服务注册通过服务注册表链接在一起。
后面有时间，会再补充目前比较常用的服务发现、服务注册的相关组件。
