目录

常见配置模式：

一句话：Apollo集成了数据库+Eureka+版本控制+权限管理等

nacos和apollo和eureka的比较

首先说下部署方式吧：

然后说下CAP定理：

说说Eureka的架构：

nacos架构

然后说说阈值保护的区别：

和apollo的比较 

简介

安装

特点

介绍 ：

1.统一管理不同环境，不同集群的配置

2.配置修改实时生效（热发布） 

3.支持配置版本的管理

4.支持灰度发布

5.权限管理，发布审核

实操（顺序）

 1.创建项目

 2.添加公共Namespace

3.然后我们打开之前的服务，关联公共Namespace

4.集群配置 

 实操

---

常见配置模式：

1.环境变量

2.启动参数配置

3.配置文件

4.运行脚本配置

5.基于数据库配置，将数据信息存在数据库中

一句话：Apollo集成了数据库+Eureka+版本控制+权限管理等

配置中心保存到数据库中（两套数据库），Eureka作注册中心，版本控制可以作灰度发布

 

nacos和apollo和eureka的比较

首先说下部署方式吧：

 nacos的部署方式与springcloud eureka不太一样，euraka是需要创建springboot项目，然后将euraka服务端通过gav的方式加载进来，然后部署项目。nacos是直接从阿里巴巴nacos的官网下载jar包，启动服务

然后说下CAP定理：

eureka支持AP模式，也就是说服务宕机不会被心跳剔除，client会缓存，利用缓存的信息来给到消费者，保证了高可用

Nacos的话支持CP和AP，服务宕机会被踢出，有临时和非临时两种；临时实例：采用心跳检测，服务主动向注册中心汇报情况；非临时实例：nacos会作为压力的承担者去主动轮询实例是否存在，然后nacos主动推送变更信息（nacos压力会变大）

共同：都用到了缓存，client会缓存服务信息，支持拉取和注册服务

说说Eureka的架构：

1.服务注册：client会通过发送Rest请求，向Eureka server注册自己的服务，比如ip地址、端口、运行状况指标、主页地址等信息。Eureka Server接收到注册请求后，就会把这些元数据信息存储在一个双层的Map中。什么时候注册？在启动微服务的时候；

2.服务续约（renew）：在服务注册后，Eureka Client会维护一个心跳来持续通知Eureka Server，说明服务一直处于可用状态，防止被剔除。默认每隔30秒eureka.instance.lease-renewal-interval-in-seconds 发送一次心跳来进行服务续约。

3.服务调用：服务消费者在获取到服务清单后，可以根据清单中的服务信息，查找到该服务的地址，从而进行访问(远程调用)

4.失效剔除（evict）：服务实例可能会因为网络故障等原因，导致不能提供服务，而此时该实例也没有发送请求给Eureka Server来进行服务下线。所以，还需要有服务剔除的机制。Eureka Server在启动的时候会创建一个定时任务，每隔一段时间（默认60秒），从当前服务清单中把超时没有续约（默认90秒eureka.instance.lease-expiration-duration-inseconds）的服务剔除

nacos架构

临时实例：如果实例宕机超过一定时间，会从服务列表剔除，默认的类型（client发送通知给server）。

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

另外范围不同：nacos支持长连接，一次请求一直占一个连接（一次连接可以处理多个请求），eureka时短连接发送完就完了（处理一次请求自动释放连接）

然后说说阈值保护的区别：

1.都可以设置比例值（健康/当前服务总实例数）

2.如果服务A有100个实例， 98个实例都不健康了，只有2个实例是健康的，如果nacos只返回这两个健康实例的信息的话，那么后续消费者的请求将全部被分配到这两个实例，流量洪峰到来， 2个健康的实例也扛不住了，整个服务A 就扛不住，上游的微服务也会导致崩溃，产⽣雪崩效应

nacos保护处理：健康/总数<阈值，说明健康实例不多，nacos会把所有实例（健康+不健康：心跳检测）提供给消费者，缓解了雪崩，牺牲了⼀些请求，保证了整个系统的⼀个可⽤——>sentinel流控遏制雪崩

Eureka保护方式：在短时间内，统计续约失败的比例，如果达到一定阈值，则会触发自我保护的机制，在该机制下，Eureka Server不会剔除任何的微服务，等到正常后，再退出自我保护机制。自我保护开关

和apollo的比较 

安全系的差异：如果所有的环境都共有一个配置中心会产生安全问题，比如开发拿到测试的配置，生产的配置

解决：

(43条消息) Nacos注册中心_Fairy要carry的博客-CSDN博客_nacos注册中心

(43条消息) nacos实战项目中的配置_Fairy要carry的博客-CSDN博客_nacos配置内容

(43条消息) 面试-SpringCloud常见组件和注册表结构+nacos_Fairy要carry的博客-CSDN博客_nacos注册表结构

1.不同环境采用不同的配置中心，当客户端获取生产配置，运维需要在项目启动参数指定生产环境的配置中心（apollo）

2.不同环境使用同一配置中心，但是做环境隔离（nacos）——>隔离的方案就是命名空间 + 鉴权。和 apollo 不同，客户端去读 nacos 是需要账号密码的，当客户端需要获取生产配置时，运维需要在项目的启动参数中指定生产环境的 namespace 以及对应的账号密码

namespace在nacos和apollo中概念不一样，nacos：指的时具体的环境；而apollo：相当于是一个类一种配置

 系统复杂度：

apollo 的架构太重了，配置中心拆成了 config service、admin service、portal

apollo 为了实现客户端到 config service 的负载均衡而引入了过多的组件。如图，增加了 SLB、meta server、eureka 等组件，这个我真的觉得没必要，直接使用 SLB 来做负载均衡就行。但官方说之所以这么设计是为了避免客户端client和 config service 之间的长连接给 SLB 增加过多的负担，这么说的话，也不无道理，但是config service eureka这些全部一起打包部署了

而nacos架构相对没那么复杂，负载均衡一个SLB就搞定了，并且我们nacos也是维护的长连接

简介

1.本地应用会去Apollo的server去拉取配置文件，给到我们的应用程序并且会异步的将配置信息给到本地文件缓存

2.当Apollo中配置文件改了之后会主动将消息给到我们的客户端，然后进行消息更新传递（哪个配置改了）

安装

1.搭建数据库环境

 (43条消息) apollo安装配置_平凡似水的人生的博客-CSDN博客_apollo数据库配置

特点

介绍 ：

 1.项目：将微服务工程引入Apollo客户端，在运行时去配置中心Apollo server获取对应配置（appId）

 2.环境：apollo客户端运行时需要知道处于哪个环境根据具体环境获取对应的配置（env）

 3.集群：根据不同实例进行分组，shanghai，beijing

 4.namespace：将一个配置类比为一个类进行管理（比如数据库管理配置，eureka配置）

(42条消息) Nacos中namespace,groupId,dataId使用_黑暗中的星星的博客-CSDN博客_nacos的groupid

1.统一管理不同环境，不同集群的配置

1.Apollo提供了不同环境（environment），不同集群（cluster），不同命名空间（namespace）的配置

2.同一份代码可以部署子不同的集群，不同的配置

3.我们可以通过命名空间完成多个不同的应用共享一份配置

2.配置修改实时生效（热发布） 

用户修改配置文件直接Apollo上修改，不需要在应用中重启了，并且我们的客户端能够接收到实时的最新配置（Apollo server会主动poll消息给到我们的client，然后通知到程序）

3.支持配置版本的管理

个人觉得功能类似于mysql中的undolog，能够进行配置回滚

4.支持灰度发布

nacos1.2后也支持，能够设置不同版本的权重，场景：更新游戏功能，让部分玩家先体验

5.权限管理，发布审核

应用和配置的管理都有完整的权限机制，并且所有的操作都有日志

实操（顺序）

 1.创建项目

 部门：属于哪个微服务组

 应用id：用来标识服务的身份，需要和application.properties中的appid相对应

 

 2.添加公共Namespace

1.首先新建一个项目common-service，然后添加公共Namespace

 

 2.创建一个namespace（一般我们根据配置文件层次来，比如mysql，eureka，跟类一样）

 3.然后我们根据新增配置项

 

3.然后我们打开之前的服务，关联公共Namespace

4.集群配置 

场景：应用根据不同的集群做不同的配置，比如A机房的应用地址连接的mqip和B机房的不一样，这时候可以用集群配置

 创建集群，并选择集群名称和环境并且发布

 

 实操

 1.修改部门信息配置

需要输入key，然后就可以修改部门信息了

 2.然后在创建项目中可以选择对应部门

 3.用户管理（创建新用户，非管理用户）

 4.添加项目

 修改项目对于用户的权限+修改信息

 5.添加进集群

 6.添加命名空间namespcae

比如这里命名空间专门配置eureka的配置信息

 

 7.对命名空间下进行配置（eureka）

 发布后才能生效

 重复配置全部放在common中