当前位置 : 主页 > 编程语言 > 其它开发 >

配置中心的设计-nacos vs apollo

来源:互联网 收集:自由互联 发布时间:2022-06-06
前面我们分析了携程的 apollo(见 详解apollo的设计与使用),现在再来看看阿里的 nacos。和 apollo 一样,nacos 也是一款配置中心,同样可以实现配置的集中管理、分环境管理、即时生效等
配置中心的设计-nacos vs apollo 前面我们分析了携程的 apollo(见 详解apollo的设计与使用),现在再来看看阿里的 nacos。和 apollo 一样,nacos 也是一款配置中心,同样可以实现配置的集中管理、分环境管理、即时生效等等。不过,nacos 还具备了服务发现的功能。这篇博客将重点分析 nacos 和 apollo 在设计上的差异。 简介

前面我们分析了携程的 apollo(见 详解apollo的设计与使用),现在再来看看阿里的 nacos。

和 apollo 一样,nacos 也是一款配置中心,同样可以实现配置的集中管理、分环境管理、即时生效等等。不过,nacos 还具备了服务发现的功能。

分析 apollo 时,我们通过四个问题展开:

  1. 为什么使用配置中心
  2. 如何设计一个配置中心
  3. apollo 是如何设计的
  4. 如何使用 apollo

当然,我们也可以用同样的套路来分析 nacos,不过,第 1、2 个问题是一样的,没必要再讲一遍,而第 4 个问题嘛,我看官网的文档已经足够详细。所以,这篇博客将重点分析 nacos 和 apollo 在设计上的差异。

以下分析基于 apollo 1.8.0 和 nacos 2.1.0。

安全性的差异

这里说的安全性,不是指控制台读配置中心,而是客户端读配置中心。

之前我说过,如果所有环境都共用一个配置中心,会存在安全问题。因为开发人员能拿到测试环境的配置,按理也能拿到生产环境的配置。

zzs_apollo_02

为了解决这个问题,一般有两个方案:

  1. 不同环境使用不同的配置中心。apollo 用的就是这一种,当客户端需要获取生产配置时,运维需要在项目的启动参数中指定生产环境的配置中心。这种方案要想可靠,生产环境的 config server 地址绝对不能泄露。可怕的是,我曾经就遇到过直接把 config server 注册到公用 eureka 上面的。
zzs_apollo_19
  1. 不同环境使用同一的配置中心,但要做好环境隔离。nacos 则采用这一种,隔离的方案就是命名空间 + 鉴权。和 apollo 不同,客户端去读 nacos 是需要账号密码的,当客户端需要获取生产配置时,运维需要在项目的启动参数中指定生产环境的 namespace 以及对应的账号密码。
zzs_apollo_20

上面说到了 namespace。apollo 和 nacos 都有这个概念,不过,在 apollo 里,namespace 可以看成是一个具体的配置文件,而 nacos 里,namespace 表示具体的环境。它们的数据模型如下图。使用 apollo 是通过连接不同的 config server 来区分环境,而 nacos 则通过指定 namespace 来区分

zzs_apollo_21

综上,我们知道,要想确保安全,使用 apollo 时不能泄露 config server 生产环境的地址,使用 nacos 时不能泄露对应生产环境 namespace 的账号密码。如果要说哪种方案更安全,我会更倾向于 nacos,因为相比账号密码,服务器地址会更容易泄露。// zzs001

系统复杂度的差异

在讲 apollo 的设计时,我吐槽过,apollo 的架构太重了。

首先,它把配置中心拆成了 config service、admin service、portal,这一点我倒是可以接受。

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

不过,有一点比较好的就是,apollo 把 config service、eureka 和 meta server 打包在一起部署。

zzs_apollo_05

我们来看看 nacos,首先,它没有将配置中心拆成很多个服务,其次,它的负载均衡方案也比较简单,一个 SLB 就可以搞定。要知道 nacos 同样也维护着与客户端的长连接。

zzs_apollo_22

那么,这两种架构哪种更好呢?我会更倾向于使用 nacos,至少中小型系统我会这么选择,因为它更简单。不过,apollo 考虑到长连接对 SLB 的负担而增加了那么多组件,按理是经过了深思熟虑,所以,我很想知道,在大型系统中使用 nacos,是否有遇到过 SLB 瓶颈的案例,希望有大佬指点。

以上基本讲完了 nacos 的结构和使用。如有错误,欢迎指正。

最后,感谢阅读。

参考资料

Nacos 官方文档

本文为原创文章,转载请附上原文出处链接:https://www.cnblogs.com/ZhangZiSheng001/p/16344519.html

分层,抽象,高内聚,低耦合
网友评论