[微服务]注册中心优化

环境隔离

企业实际开发中，往往会搭建多个运行环境，例如：

• 开发环境
• 测试环境
• 预发布环境
• 生产环境

这些不同环境之间的服务和数据之间需要隔离。

还有的企业中，会开发多个项目，共享nacos集群。此时，这些项目之间也需要把服务和数据隔离。

因此，Nacos提供了基于namespace的环境隔离功能。具体的隔离层次如图所示：

说明：

• Nacos中可以配置多个namespace，相互之间完全隔离。默认的namespace名为public
• namespace下还可以继续分组，也就是group ，相互隔离。 默认的group是DEFAULT_GROUP
• group之下就是服务和配置了

创建namespace

nacos提供了一个默认的namespace，叫做public：

默认所有的服务和配置都属于这个namespace，当然我们也可以自己创建新的namespace：

然后填写表单：

添加完成后，可以在页面看到我们新建的namespace，并且Nacos为我们自动生成了一个命名空间id：

我们切换到配置列表页，你会发现dev这个命名空间下没有任何配置：

因为之前我们添加的所有配置都在public下：

配置namespace

默认情况下，所有的微服务注册发现、配置管理都是走public这个命名空间。如果要指定命名空间则需要修改application.yml文件。

比如，我们修改item-service服务的bootstrap.yml文件，添加服务发现配置，指定其namespace：

启动item-service，查看服务列表，会发现item-service出现在dev下：

而其它服务则出现在public下：

此时访问http://localhost:8082/doc.html，基于swagger做测试：

会发现查询结果中缺少商品的最新价格信息。

我们查看服务运行日志：

会发现cart-service服务在远程调用item-service时，并没有找到可用的实例。

这证明不同namespace之间确实是相互隔离的，不可访问。

当我们把namespace切换回public，或者统一都是以dev时访问恢复正常。

分级模型

在一些大型应用中，同一个服务可以部署很多实例。而这些实例可能分布在全国各地的不同机房。由于存在地域差异，网络传输的速度会有很大不同，因此在做服务治理时需要区分不同机房的实例。

例如item-service，我们可以部署3个实例：

• 127.0.0.1:8081
• 127.0.0.1:8082
• 127.0.0.1:8083

假如这些实例分布在不同机房，例如：

• 127.0.0.1:8081，在上海机房
• 127.0.0.1:8082，在上海机房
• 127.0.0.1:8083，在杭州机房

Nacos中提供了集群（cluster）的概念，来对应不同机房。也就是说，一个服务（service）下可以有很多集群（cluster），而一个集群（cluster）中下又可以包含很多实例（instance）。

如图：

因此，结合我们上一节学习的namespace命名空间的知识，任何一个微服务的实例在注册到Nacos时，都会生成以下几个信息，用来确认当前实例的身份，从外到内依次是：

• namespace：命名空间
• group：分组
• service：服务名
• cluster：集群
• instance：实例，包含ip和端口

这就是nacos中的服务分级模型。

在Nacos内部会有一个服务实例的注册表，是基于Map实现的，其结构与分级模型的对应关系如下：

查看nacos控制台，会发现默认情况下所有服务的集群都是default：

如果我们要修改服务所在集群，只需要修改bootstrap.yml即可：

spring:cloud:nacos:discovery:cluster-name: BJ # 集群名称，自定义

我们修改item-service的bootstrap.yml，然后重新创建一个实例：

再次查看nacos：

发现8084这个新的实例确实属于BJ这个集群了。

Eureka

Eureka是Netflix公司开源的一个服务注册中心组件，早期版本的SpringCloud都是使用Eureka作为注册中心。由于Eureka和Nacos的starter中提供的功能都是基于SpringCloudCommon规范，因此两者使用起来差别不大。

课前资料中提供了一个Eureka的demo：

我们可以用idea打开查看一下：

结构说明：

• eureka-server：Eureka的服务端，也就是注册中心。没错，Eureka服务端要自己创建项目
• order-service：订单服务，是一个服务调用者，查询订单的时候要查询用户
• user-service：用户服务，是一个服务提供者，对外暴露查询用户的接口

启动以后，访问localhost:10086即可查看到Eureka的控制台，相对于Nacos来说简陋了很多：

微服务引入Eureka的方式也极其简单，分两步：

• 引入eureka-client依赖

• 配置eureka地址

接下来就是编写OpenFeign的客户端了，跟Nacos用起来基本一致。

Eureka和Nacos对比

Eureka和Nacos都能起到注册中心的作用，用法基本类似。但还是有一些区别的

Eureka和Nacos的相似点有：

• 都支持服务注册发现功能
• 都有基于心跳的健康监测功能
• 都支持集群，集群间数据同步默认是AP模式，即最全高可用性

Eureka和Nacos的区别有：

• Eureka的心跳是30秒一次，Nacos则是5秒一次
• Eureka如果90秒未收到心跳，则认为服务疑似故障，可能被剔除。Nacos中则是15秒超时，30秒剔除。
• Eureka每隔60秒执行一次服务检测和清理任务；Nacos是每隔5秒执行一次。
• Eureka只能等微服务自己每隔30秒更新一次服务列表；Nacos即有定时更新，也有在服务变更时的广播推送
• Eureka仅有注册中心功能，而Nacos同时支持注册中心、配置管理
• Eureka和Nacos都支持集群，而且默认都是AP模式