本篇主要记录Nacos环境隔离的知识以及Naocs与Eureka服务注册中心的区别。希望能加深自己的印象以及帮助到大家😉

Nacos环境隔离

通常，企业研发的流程是这样的：先在测试环境开发和测试功能，然后灰度，最后发布到⽣产环境。并且，为了⽣产环境的稳定，需要将测试环境和⽣产环境进⾏隔离，此时，必然会遇到问题是多环境问题，即：

多个环境的数据如何隔离？

如何优雅的隔离？（不需要⽤户做任何改动）

本⽂将就 Nacos 环境隔离，向⼤家介绍阿⾥在这⽅⾯的实践经验。

什么是环境？

说到环境隔离，⾸先应该定义好什么是环境。

环境这个词⽬前还没有⼀个⽐较统⼀的定义，有些公司叫环境，在阿⾥云上叫 region，在 Kubernetes 架构中叫 namespace。本⽂认为，环境是逻辑上或物理上独⽴的⼀整套系统，这套系统中包含了处理⽤户请求的全部组件，例如⽹关、服务框架、微服务注册中⼼、配置中⼼、消息系统、缓存、数据库等，可以处理指定类别的请求。

举个例⼦，很多⽹站都会有⽤户 ID 的概念，可以按照⽤户 ID 划分，⽤户 ID 以偶数结尾的请求全部由⼀套系统处理，⽽奇数结尾的请求由另⼀套系统处理。如下图所⽰。 我们这⾥说的环境隔离是指物理隔离，即不同环境是指不同的机器集群。

环境隔离有什么⽤

本节跟⼤家讨论⼀下环境隔离有哪些好处。从概念的定义可以看出，环境隔离⾄少有三个⽅⾯的好处：故障隔离、故障恢复、灰度测试；

故障隔离

⾸先，因为环境是能够处理⽤户请求的独⽴组件单元，也就是说⽤户请求的处理链路有多长，都不会跳出指定的机器集群。即使这部分机器故障了，也只是会影响部分⽤户，从⽽把故障隔离在指定的范围内。如果我们按照⽤户id把全部机器分为⼗个环境，那么⼀个环境出问题，对⽤户的影响会降低为⼗分之⼀，⼤⼤提⾼系统可⽤性。

故障恢复

环境隔离的另⼀个重要优势是可以快速恢复故障。当某个环境的服务出现问题之后，可以快速通过下发配置，改变⽤户请求的路由⽅向，把请求路由到另⼀套环境，实现秒级故障恢复。当然，这需要⼀个强⼤的分布式系统⽀持，尤其是⼀个强⼤的配置中⼼（如Nacos），需要快速把路由规则配置数据推送到全⽹的应⽤进程。

灰度测试

灰度测试是研发流程中不可或缺的⼀个环节。传统的研发流程中，测试和灰度环节，需要测试同学做各种各样的配置，如绑定host、配置jvm参数、环境变量等等，⽐较⿇烦。经过多年的实践，阿⾥巴巴内部的测试和灰度对开发和测试⾮常友好，通过环境隔离功能来保证请求在指定的机器集群处理，开发和测试不需要做任何做任何配置，⼤⼤提⾼了研发效率。

Nacos提供了namespace来实现环境隔离功能。

• nacos中可以有多个namespace
• namespace下可以有group、service等
• 不同namespace之间相互隔离，例如不同namespace的服务互相不可见

创建namespace

默认情况下，所有service、data、group都在同一个namespace，名为public：

我们可以点击页面新增按钮，添加一个namespace：

然后，填写表单：

就能在页面看到一个新的namespace：

配置namespace

给微服务配置namespace只能通过修改配置来实现。

例如，修改order-service的application.yml文件：

spring:
  cloud:
    nacos:
      server-addr: localhost:8848
      discovery:
        cluster-name: HZ
        namespace: 492a7d5d-237b-46a1-a99a-fa8e98e4b0f9 
        
1
2
3
4
5
6
7
8

重启order-service后，访问控制台，可以看到下面的结果：

Nacos与Eureka的区别

Nacos的服务实例分为两种类型：

• 临时实例：如果实例宕机超过一定时间，会从服务列表剔除，默认的类型。

• 非临时实例：如果实例宕机，不会从服务列表剔除，也可以叫永久实例。

Nacos与eureka的共同点：
都支持服务注册和服务拉取
都支持服务提供者心跳方式做健康检测

Nacos与Eureka的不同点 ：
Nacos支持服务端主动检测提供者状态：临时实例采用心跳模式，非临时实例采用主动检测模式
临时实例心跳不正常会被剔除，非临时实例则不会被剔除 Nacos支持服务列表变更的消息推送模式，服务列表更新更及时
Nacos集群默认采用AP方式，当集群中存在非临时实例时，采用CP模式；Eureka采用AP方式

本篇文章到这里就结束了，感谢各位小伙伴儿们的支持😉