nacos启动不能发现服务_微服务注册与发现我为什么选择 Nacos server-[零起点微服务教程2]...

给鹏哥5分钟，你讲学到为什么会出现服务注册与发现，目前流行的服务注册与发现框架有那些？最后 结合一个例子，来实战Nacos的使用方法。

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

我们知道微服务是根据业务不同将系统分割成很多个不同的小系统，为了实现高可用，又讲每个每个小系统部署很多个节点。那么问题来了，如果各个微服务之间需要互相调用，我们怎么能掉到对方的服务呢？ 为了能找到对应的服务地址和IP，我们来一个粗暴的办法，将所有的服务信息都写到一个表格里面，在调用的时候就在这个表格里面匹配，当匹配到一个服务的时候，就使用他对应的IP+端口，调用到对应的服务，在不使用框架的情况这估计是大部分都能想到的方法，那这样有什么缺点呢？ 可以维护性差：如果其中的微服务信息(如IP，端口等)发生了改变，这个表格需要同步修改。 可扩展性差：如果某个微服务新加或者增加了节点，需要同步修改这个表格。 无法动态感知服务的变化：如果某个微服务的某个节点宕机或者负载太高，其他服务无法感知并动态调整。 各微服务之间耦合度高：所有的微服务都要维护其他服务的IP+端口，导致服务间耦合度太高。

你会发现，我们辛辛苦苦升级了微服务架构带来的好处，都被这个表格吞噬掉了。难道真的就这样了么？答案当然是否定的，下边就该我们框架登场了。

我们来设想一下微服务的注册与发现需要具备那些能力才能解决上边我们列出来的问题： 服务注册：微服务在自身具备提供服务能力的时候，需要有能力将自身的信息上报给框架 服务发现：在微服务发起对其他服务调用的时候，框架需要有能力将这个请求路由到对应的微服务节点上去 监控：框架需要实时监控各个微服务各个节点的可用状态 动态调整：框架需要能根据监控的结果动态的调整

带着这些猜想，我们来看一下目前市面上有那些流行的服务注册与发现的框架。

目前流行的服务注册与发现的框架

在讨论流行的框架之前，我们考虑一个事务一致性的问题。说到的事务的一致性，其实就是说的CAP原则：CAP原则，指的是在一个分布式系统中不能同时成立。 Consistency(一致性)：它要求在同一时刻点，分布式系统中的所有数据备份都处于同一状态。 Availability(可用性)：在系统集群的一部分节点宕机后，系统依然能够响应用户的请求。 * Partition Tolerance(分区容错性)：在网络区间通信出现失败，系统能够容忍。

一般来讲，基于网络的不稳定性，分布容错是不可避免的，所以我们默认CAP中的P总是成立的。 一致性的强制数据统一要求，必然会导致在更新数据时部分节点处于被锁定状态，此时不可对外提供服务，影响了服务的可用性，反之亦然。因此一致性和可用性不能同时满足。

对于服务发现和注册中心集群来说，如果选择一致性而牺牲可用性（选择CP）的话，那么为了保证多点服务中心上的数据一致，一旦某个点的服务中心宕机，服务中心集群都需要暂停对外提供数据写入服务。在保证服务中心集群的数据一致的同时，牺牲了写入服务的可用性。 如果选择可用性而牺牲一致性（选择AP）的话，那么为了保证服务不中断，当某个点的服务中心宕机时，仍然存活的服务中心节点可以选择先将数据写入本地存储然后直接返回客户端，但这样又将导致多个节点之间的数据不一致。 为什么我们在聊这些框架前要先聊CAP呢？那是因为不同的框架采用的取舍不一样，而这个差异决定框架的整体设计。我们接下来介绍的服务注册和发现组件中，Eureka满足了其中的AP，Consul和Zookeeper满足了其中的CP。

ZooKeeper

Zookeeper是由Google开源的在Java语言上实现的分布式协调服务，是Hadoop和Hbase的重要组件，提供了数据/发布订阅、负载均衡、分布式同步等功能。基于Zab协议，Zookeeper可以用于构建具备数据强一致性的服务注册与发现中心，而与此相对地牺牲了服务的可用性和提高了注册需要的时间。

Consul

Consul是由HashiCorp基于Go语言开发的支持多数据中心分布式高可用的服务发布和注册服务软件，采用Raft算法保证服务的一致性，且支持健康检查。基于Raft算法，Consul提供强一致性的注册中心服务，但是由于Leader节点承担了所有的处理工作，势必加大了注册和发现的代价，降低了服务的可用性。通过Gossip协议，Consul可以很好地监控Consul集群的运行，同时可以方便通知各类事件，如Leader选择发生、Server地址变更等。

Eureka

Eureka是在Java语言上，基于Restful Api开发的服务注册与发现组件，由Netflix开源。朋友圈闹的沸沸扬扬的闭源事件，其实是胎死腹中的Eureka 2.X版本，其实Spring Cloud集成Eureka，是Spring Cloud自身深度定制Eureka的版本，所以闭源对其一点影响都不会有。Eureka中没有使用任何的数据强一致性算法保证不同集群间的Server的数据一致，仅通过数据拷贝的方式争取注册中心数据的最终一致性，虽然放弃数据强一致性但是换来了Server的可用性，降低了注册的代价，提高了集群运行的健壮性。

Nacos

终于说到我们今天主角。Nacos是阿里开源的，Nacos 支持基于 DNS 和基于 RPC 的服务发现。Nacos同时整合了配置中心和服务发现，和cloud，dubbo天然结合，代码也没啥侵入性。 Nacos除了服务的注册发现之外，还支持动态配置服务。动态配置服务可以让您以中心化、外部化和动态化的方式管理所有环境的应用配置和服务配置。动态配置消除了配置变更时重新部署应用和服务的需要，让配置管理变得更加高效和敏捷。配置中心化管理让实现无状态服务变得更简单，让服务按需弹性扩展变得更容易。 所以在鹏哥的规划中就是使用Nacos 来替代Spring Cloud Configuationg组件。

下边一个表格从各个方面比较了几个框架的特性。

这个教程定义为入门级别，以上的了解足矣我们在别人面前吹牛了。如果这个教程反应不错的化，鹏哥会在第二阶段更深入的介绍其中的原理。

一个例子

• Nacos 官网：https://nacos.io/zh-cn/
• NAcos Docker 教程：https://nacos.io/zh-cn/docs/quick-start-docker.html

下边鹏哥就跟大家演示一个使用Eacos作为服务注册与发现的例子，关于Eacos 作为配置中心的例子，我们会在后边做动态路由的时候讨论。

在Docker中启动Nacos server

1. 搜索nacos镜像 ：docker search nacos

2. 下载镜像 ：docker pull nacos/nacos-server

3. 启动镜像：docker run --name nacos-standalone -e MODE=standalone -p 8848:8848 -d nacos/nacos-server:latest

4. 打开：http://127.0.0.1:8848/nacos/

5. 使用用户名密码：nacos/nacos 登录

在代码中配置Nacos Client

首先我们需要引入一下Nacos的客户端依赖：

添加配置文件bootstrap.yaml，配置服务在Nacos 显示服务名称：

添加配置文件application.yaml，配置端口以及在Nacos 的服务器地址:

bootstrap是在服务启动前加载，application是在服务启动的时候加载。 所以一般情况下，用于启动的参数是需要配置在bootstrap里面，服务相关的参数配置在application里面。具体那些参数需要配置在application里面，那些需要配置在bootstarap里面，我们会在后续章节探讨。

添加启动类，并添加 @SpringBootApplication 和 @EnableDiscoveryClient注解：

启动项目：

打开Nacos 服务列表页面，查看我们注册的服务是否已经注册上去：

至此Nacos作为服务注册与发现的例子就算完成了，具体里面的参数什么含义，怎么更高雅的配置，怎么调整性能，鹏哥会在后续的章节介绍。本章的相关的代码，鹏哥已经checkin到了github.

github地址：

linghuxiong/pengge-cloud​github.com

下节预告

下一节我们讨论微服务为什么需要网关？目前流行的网关框架有哪些？我们选择的Spring Cloud Gateway 有什么特点等。

写在最后

这套教程在昨天开天篇之后，已经算是正式开始了。鹏哥规划这套教程分为三部分：第一是搭建一个简易版的Spring Cloud 脚手架; 第二是：集成前端UI，并添加常见的功能如用户权限管理等。目前规划前端架构是使用Ant Design Pro; 第三是深入了解使用的技术和架构，优化配置。以上所有的步骤，每一布都会有文章介绍，并从零开始，一步一个脚印的走下去。 对于微服务鹏哥也是一个小学生，欢迎各位微服务的初学者，使用者来吐糟。同时如果各位有什么好的建议也挺提出来，我们一起来探讨。如果各位喜欢这部教程，觉得这个部教程还不错，可以转发，收藏会推荐给身边的朋友，你的支持将是鹏哥最大的动力。