服务注册与发现

微服务

为什么需要服务注册与发现？

微服务架构下，一个系统通常由多个微服务组成(比如电商系统可能分为用户服务、商品服务、订单服务等服务)，一个用户请求可能会需要多个服务参与，这些服务之间互相配合以维持系统的正常运行。

在没有服务注册与发现机制之前，每个服务会将其依赖的其他服务的地址信息写死在配置文件里(参考单体架构)。假设我们系统中的订单服务访问量突然变大，我们需要对订单服务进行扩容，也就是多部署些订单服务来分担处理请求的压力。这个时候，我们需要手动更新所有依赖订单服务的服务节点的地址配置信息。同理，假设某个订单服务节点突然宕机，我们又要手动更新对应的服务节点信息。更新完成之后，还要手动重启这些服务，整个过程非常麻烦且容易出错，

有了服务注册与发现机制之后，就不需要这么麻烦了，由注册中心负责维护可用服务的列表，通过注册中心动态获取可用服务的地址信息。如果服务信息发生变更，注册中心会将变更推送给相关联的服务，更新服务地址信息，无需手动更新，也不需要重启服务，这些对开发者来说完全是无感的。

服务注册与发现可以帮助我们实现服务的优雅上下线，从而实现服务的弹性扩缩容。除此之外，服务注册与发现机制还有一个非常重要的功能:不可用服务剔除。简单来说，注册中心会通过心跳机制来检测服务是否可用，如果服务不可用的话，注册中心会主动剔除该服务并将变更推送给相关联的服务，更新服务地址信息。

最后，我们再来总结补充一下，一个完备的服务注册与发现应该具备的功能

• 服务注册以及服务查询(最基本的)
• 服务状态变更通知、服务健康检查、不可用服务剔除
• 服务权重配置(权重越高被访问的频率越高)

服务注册与发现的基本流程

服务注册

每个服务节点在启动运行的时候，会向注册中心注册服务，也就是将自己的地址信息(ip、端口以及服务名字等信息的组合)上报给注册中心，注册中心负责将地址信息保存起来，这就是服务注册。

服务发现

一个服务节点如果要调用另外一个服务节点，会直接拿着服务的信息找注册中心要对方的地址信息，这就是服务发现。通常情况下，服务节点拿到地址信息之后，还会在本地缓存一份，保证在注册中心宕机时仍然可以正常调用服务。

服务变更通知

如果服务信息发生变更，注册中心会将变更推送给相关联的服务，更新服务地址信息。

为了保证服务地址列表中都是可用服务的地址信息，注册中心通常会通过心跳机制来检测服务是否可用如果服务不可用的话，注册中心会主动剔除该服务并将变更推送给相关联的服务，更新服务地址信息。

最后，再来一张图简单总结一下服务注册与发现(一个服务既可能是服务提供者也可能是服务消费者)。

常见的注册中心有哪些?

比较常用的注册中心有 ZooKeeper、Eureka、Nacos，这三个都是使用 Java 语言开发，相对来说，更适合 Java 技术栈一些。其他的还有像 ETCD、Consu，这里就不做介绍了。

ZooKeeper

首先，咱们来看ZooKeeper，大部分同学应该对它不陌生。严格意义上来说，ZooKeeper 设计之初并不是未来做注册中心的，只是前几年国内使用 Dubbo 的场景下比较喜欢使用它来做注册中心。

对于 CAP理论来说，ZooKeeper 保证的是 CP。任何时刻对 ZooKeeper 的读请求都能得到一致性的结果，但是，ZooKeeper 不保证每次请求的可用性，比如在 Leader 选举过程中或者半数以上的机器不可用的时候服务就是不可用的。
针对注册中心这个场景来说，重要的是可用性，AP会更合适一些。ZooKeeper 更适合做分布式协调服注册中心就交给专业的来做吧

Eureka

其次，我们再来看看 Eureka，一款非常值得研究的注册中心。Eureka 是 Netflix 公司开源的一个注册中心，配套的还有 Feign、Ribbon、Zuul、Hystrix 等知名的微服务系统构建所必须的组件。对于 CAP 理论来说，Eureka 保证的是 AP，Eureka 集群只要有一台 Eureka 正常服务，整个注册中心就是可用的，只是查询到的数据可能是过期的(集群中的各个节点异步方式同步数据，不保证强一致性)。

不过，可惜的是，Spring Cloud 2020.0.0 版本移除了 Netflix 除 Eureka 外的所有组件。那为什么 Spring Cloud 这么急着移除 Netflix 的组件呢? 主要是因为在 2018年的时候，Netfix 宣布其开源的核心组件 Hystrix、Ribbon、Zuul、Eureka 等进入维护状态，不再进行新特性开发，只修 BUG.于是，Spring 官方不得不考虑移除 Netflix 的组件。

Dubbo

我这里也不推荐使用 Eureka 作为注册中心，阿里开源的 Nacos 或许是更好的选择。

最后，我们再来看看 Nacos，一款即可以用来做注册中心，又可以用来做配置中心的优秀项目。

Nacos 属实是后起之秀，借鉴吸收了其他注册中心的优点，与Spring Boot、Dubbo、Spring Cloud、Kubernetes 无缝对接，兼容性很好。并且Nacos 不仅支持CP也支持 AP，Nacos 性能强悍(比 Eureka 能支持更多的服务实例)，易用性较强(文档丰富、数据模型简单且自带后台管理界面)，支持 99.9% 高可用。

对于 Java 技术栈来说，个人是比较推荐使用 Nacos 来做注册中心。

为什么要用配置中心?

微服务下，业务的发展一般会导致服务数量的增加，进而导致程序配置(服务地址、数据库参数等等)增多。传统的配置文件的方式已经无法满足当前需求，主要有下面几点原因:

• 安全性得不到保障：配置放在代码库中容易泄露。
• 时效性不行：修改配置需要重启服务才能生效。
• 不支持权限控制：没有对配置的修改、发布等操作进行严格的权限控制。
• 不支持配置集中管理：配置文件过于分散，不方便管理。

另外，配置中心通常会自带版本跟踪，会记录配置的修改记录，记录的内容包括修改人、修改时间、修改内容等等。
虽然通过 Git 版本管理我们也能追溯配置的修改记录，但是配置中心提供的配置版本管理功能更全面。并且，配置中心通常会在配置版本管理的基础上支持配置一键回滚。

常见的配置中心有哪些?

Spring Cloud Config、Nacos 、Apollo、K8s ConfigMap 、Disconf、Qconf 都可以用来做配置中心。

Disconf和 Qconf 已经没有维护，生态也并不活跃，并不建议使用，在做配置中心技术选型的时候可以跳过。

如果你的技术选型是 Kubernetes 的话，可以考虑使用 K8s ConfigMap 来作为配置中心。

Apollo 和 Nacos 我个人更喜欢，两者都是国内公司开源的知名项目，项目社区都比较活跃旦都还在维护中。Nacos 是阿里开源的，Apolo 是携程开源的。Nacos 使用起来比较简单，并且还可以直接用来做服务发现及管理。Apolo 只能用来做配置管理，使用相对复杂一些，

如果你的项目仅仅需要配置中心的话，建议使用 Apollo。如果你的项目需要配置中心的同时还需要服务发现及管理的话，那就更建议使用 Nacos。

Spring Cloud Config 属于 Spring Cloud 生态组件，可以和 Spring Cloud 体系无缝整合。由于基于 Git 存储配置，因此 Spring Cloud Config 的整体设计很简单。

Apollo 和 Nacos 提供了更多开箱即用的功能，更适合用来作为配置中心。

Nacos 使用起来比较简单，并且还可以直接用来做服务发现及管理。Apollo 只能用来做配置管理，使用相对复杂一些。

Apollo 在配置管理方面做的更加全面，就比如说虽然 Nacos 在 1.1.0 版本开始支持灰度配置，但 Nacos 的灰度配置功能实现的比较简单，Apollo 实现的灰度配置功能就相对更完善一些。不过，Nacos 提供的配置中心功能已经可以满足绝大部分项目的需求了。