摘要

在实际业务场景中服务部署有不同的需求，服务的注册发现机制的实现也有不同的实现方式。文章尝试探讨不同层次的服务注册发现的适用场景和优缺点，理解不同方案的优缺点和适用性，指导在实际的业务中根据实际场景选择适合的服务部署方案。

在传统服务化开发 、 容器云 平台实施和微服务开发过程中，都会遇到服务注册和发现的问题。 服务 注册发现组件 和 实现方式及实现的层次也各 不 相同，比如传统 ESB可以 使用 UDDI实现 注册发现 ； 容器云平台本身 实现了 注册发现机制 ；微服务 注册发现组件则很多，比如 E u reka、Consul、 Z ookeeper等；SpringCloud、Dubbo等都 有自己的实现或支持的注册发现组件 ；ServiceMesh服务网格 也 有 流量代理、注册发现机制 ； 而 传统API Gateway API 管理 工具也有注册发现机制 ；怎么 看待这些不同的 注册 发现机制和组件 ，特别是 目前微服务部署在容器云平台，该怎么选择部署注册发现中心组件，微服务 选择在 哪个层次注册 ，分别适用于 什么样的场景， 这是 我们今天讨论的 内容 。

一、 服务注册发现机制

不同 服务之间 在 需要 相互 调用的时候，需要 知道 对方的调用地址。当然 我们 可以直接告诉对方我的服务的地址，但 不同 团队开发众多的服务的情况下，是需要维护一个服务列表的，而服务总是 在 持续改进中，版本可能不断变化，要维护 不断 变化的整个服务列表， 这样 的效率明显比较 低。 特别 是 微服务 的 快速应用，需要有个第三方工具来 自动化 协助维护这个服务列表， 这就 是服务注册发现中心组件的价值。

开发 的服务要让其他人 知道 ，需要首先 把 这个服务注册到服务注册中心 ， 这就需要遵循 服务 注册的协议和规范 ，像Eureka、Consul等 都提供了 服务 自动注册机制， 在 服务代码中加入服务注册 注解语句 就可以自动实现 注册 。 注册 的服务可以通过注册中心进行查询，查看所有注册的服务，服务消费者就可以选择需要的服务进行调用 。

在理解 服务注册发现机制之后，我们 将 微服务部署于容器云时， 需要 考虑服务注册发现组件该如何选择如何部署 ？

二、 服务注册发现实现层次

在 容器云上部署微服务，服务的注册发现可以直接使用容器云平台 自身 提供的注册发现机制，或者使用 服务 网格机制的流量代理，或者使用独立部署于容器平台或容器云平台的注册发现中心 组件 ，不同的方式有不同的优缺点，通常要根据实际的需要和场景选择合适的方式。

（一） 容器平台的注册发现机制

容器平台 调度 管理 框架 本身提供注册发现能力，比如Kubernetes 。 镜像部署到容器平台之后，生成的服务会在容器平台实现自动注册，通过service访问。可以发布为Clusterip, Nodeport, Loadbalancer, External name等 服务类型 。 通常 对外服务使用N odeport或者实现Ingress 负载 均衡器方式 。 OpenShift 基于Kuber n etes之上封装 了 Route组件， 。

1. 优点

容器云 平台 注册 发现 机制 的 优点 是在开发服务时不用考虑引用服务注册发现组件的包，只考虑实现自己的业务逻辑代码 ； 或者一些根本无法修改的应用或组件 可以 直接部署到容器平台提供服务 ，比如Tomcat。 这样使服务的开发和部署相对简单。

另外 在多集群的情况下， 服务 的注册发现也不受影响，无论 多集群 采用 主备 模式或是双活模式，在一个集群出现不可用，另外一个集群 的 服务注册机制不受影响 。

2. 缺点

由于 容器的注册发现是内置的， 和 容器平台紧耦合， 容器 的注册发现机制和 SpringCloud等 的注册发现机制不一样， 因此服务 的 可移植性会 受 平台 限制。 不过用 SpringCloud 等 开发的微服务可以同时支持 Spring微服务 注册和容器平台层注册， 充分利用 容器和微服务层实现机制的便利性。

另外容器 中注册的地址是容器地址，外部难以访问， 需要 通过容器平台发布为 NodePort、LoadBalancer等 类型的服务 才能 为 外部 访问。

（二） 独立的注册发现中心

首先 不管用不用容器云平台，在微服务框架中 会 有服务注册发现组件，比如 SpringCloud中的Eureka， 或者 使用Consul等实现 微服务的注册和查找。 这些 组件可以部署为独立的注册 发现 中心 ， 和 服务、 平台是分开的。

这种独立 的注册中心部署方式适合多种场景，比如以前的 ESB服务 ， 或者 当前部署的微服务， 或者 部署在容器云平台的微服务， 甚至不是微服务只要遵循注册发现机制 都可以注册到独立的注册中心。注册中心组件也很多， Eureka，Consul、etcd、Zookeeper等。Eureka2.0虽然 停止更新，但 1. x 是 Netflix 服务 发现系统的核心部分，所以仍然是 活动 的项目。 Consul支持 多数据中心多集群部署，功能强大，也支持了和 SpringCloud的 集成 。当 选择 独立 的微服务注册中心 时 ， Consul是个比较 好的选 项 。

1. 优点

可以 构建一个服务注册中心集群，所 有 的服务都 可以 注册到这里，不受平台限制，独立提供服务注册发现能力。 另外注册 发现中心通常是稳定的组件，不需要 经常 重启或者 切换 ，因此比 注册 到容器更能提供持续稳定的服务。

2. 缺点

独立 维护一个服务注册中心 或者 一个服务注册中心集群。在多集群或者多数据中心架构下，可能需要 部署 维护多个 服务 注册中心集群 ， 以实现容灾和备份。 运维 工作量相对较大。

（三） ServiceMesh代理注册发现

ServiceMesh提供了服务注册发现的接口，没有实现，通过adapter方式实现和Kubernetes等的集成。 目前ServiceMesh实现 如 Istio等 在性能方面还不是很 完善 ，可能还有一段路走。

（四） API管理实现服务注册发现

A PI 管理 通常包含 API网关 、 API管理 和 API Portal 等 组件。 我们 之所以把 API管理 列出来是因为这是采用微服务和容器平台 相关 很重要的一个 组件 。 它 独立于容器平台，是面向内外部提供标准 API的 关键组件。对外 提供OpenAPI， 对内实现稳定的 可 重用的接口层， 服务 或微服务通过 API管理 注册为 标准API。

SpringCloud等有Zuul， Geteway 组件 ，但 从 企业 级 架构上来说不足以支撑 服务 网关的需求， 比如 多开发语言支持 。 不同框架、不同开发语言的微服务需要通过统一的网关注册提供 API服务 。

1. 优点

A PI 管理层 主要为了提供标准化的 API， 微服务或者其他内部服务，不管是否部署在容器上，都可以通过API 管理 组件暴露 标准API 接口， 实现自助 服务、访问控制、流量控制 及 计量计费 等。

适合 企业级生态化建设架构。

2. 缺点

API 管理 实现服务注册发现在原有架构下 又 增加一层，增加 了 组件和运维工作量，不适合小型项目和小的公司。

三、 层次划分和适用场景

现在很多人都把容器、微服务、 ServiceMesh 等混在一起讨论，甚至很多人混淆概念说 ServiceMesh 是第二代微服务，不知道是为了 宣传 故意为之还是不懂装懂。这其实是我们一直不赞成的。在我们使用某种技术的时候首先必须弄明白其概念、来源和适用场景。不能眉毛胡子一把抓，不分青红皂白，拿来就用，一定要考虑清楚了，选择合适的工具，才能事半功倍。

由于应用场景多种多样， 可能 不是某一种方案就能完美解决 所有 问题的。另外也面临着持续扩展、 跨 集群 、 跨数据中心等需求 。 本地 方案 、同城方案、异地方案甚至跨国或 洲际 方案 有 不同的要求 ， 采用不同的技术等也会使 实现 方案有差别 ， 因此适合别人的不见得就适合自己，需要理论联系实际，设计出适合自己的最佳方案 。

（一） 层次划分

以 容器平台 （包括ServiceMesh ）、微服务、 API管理统一 来考虑， 注册 发现基本可以划分为三个层次 ： 容器层、独立微服务注册发现和 企业级API管理层 。

如果所有服务都部署于容器平台， 容器层 的注册发现机制是最合适的 ； 从 稳定性等 角度考虑，非容器化部署目前可能是一个更好的选择； 从 生态 系统 建设角度 来说 ， API管理 是必须的。

（二） 注册发现组件适用场景

1. 互联网类应用快速迭代、无状态场景

这种场景 非常适合 将 服务部署于容器平台，可以利用容器平台的优点， 弹性 、无状态、快速启停、自动恢复等 特性 ，直接利用容器平台服务的注册机制，没必要再部署 额外 的注册发现中心。

2. 高稳定性应用，无频繁改动需求

对于有高稳定性需求的应用，不太适合部署于容器平台，那么注册中心其实也不适合部署在容器平台，非容器化部署可能更合适些。 注册 中心提供持续稳定的注册发现服务。

3. 跨集群注册发现方案选择

多 容器集群环境下，需要选择 主备 或者双活 / 多活模式 ，是 采用全容器注册或是部署独立的注册发现中心 ，或者单一 注册发现中心或 每个 集群 都附属 自己的注册发现中心 ， 或者分层注册机制等。 通常 支持复杂的 高 可用部署 和业务 需求。

4. API Gateway层API注册机制

API 网关层 提供 API的 注册，通过 API Portal提供API集市 ，通常适合 有OpenAPI需求 的场景 ， 安全性方面要求相对比较高。当然 对 内也 可以 通过 API管理 工具提供 API服务 ，特别是集团性公司的 IT、 数据生态 体系 建设 。

在 讨论 Gateway时 ， 很多人 会把 API Gateway和 微服务的 Gateway混为 一谈 。A PI Gateway 和 微服务的Gateway其实是不一样的。 API Gate way 提供 了 API的 管理和注册功能， 其 不限于微服务； 微服务Gateway实现 服务 访问 的访问控制等机制 ， 微服务网关 用在 微服务架构内部。

（三） 独立注册发现组件部署

注册 发现组件的部署可以容器化部署也可以非容器化部署 。 为了获得敏捷的环境准备，在测试环境建议可以考虑容器化部署。 生产 环境建议非容器化部署以获得 稳定 的服务能力。

1. 测试环境容器化部署

开发 测试 环境 通常面临着快速变动、敏捷环境准备需求， 为了测试 不同的 版本 支持，可能需要几分钟构建一个全新的 版本 环境， 测试 完毕后可以迅速回收，用于其他版本或应用的测试。 类似 这样的需求容器化部署就非常简单，互不影响 。在 容器云平台可以提供服务注册发现中心镜像， 不同 租户都可以敏捷的构建自己的开发测试注册中心。

2. 生产环境非容器化部署

基于 我们的实践和 体会 ， 对于 特别是传统的企业，在生产环境 追求 的是稳定和安全。 所以 基础组件的部署建议部署于稳定的物理机或虚拟机上 。 容器 的弹性 和敏捷对于 追求 稳定性 的 企业来说反而是劣势。 因此 生产环境应该有别于测试环境，或者 UAT环境 保持和生产环境 一致 ，区别于开发测试环境。

生产 环境跨集群或跨数据中心等场景， 通常 需要考虑容灾和备份，因此注册和发现中心组件也需要考虑容灾和备份机制 。

作者：汪照辉、王作敬