🔍
📢

Nacos vs Apollo 阿里携程开源配置中心的对比和区别

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

 

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

 

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

 

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

 

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

 

  1. 不同环境使用不同的配置中心。apollo 用的就是这一种,当客户端需要获取生产配置时,运维需要在项目的启动参数中指定生产环境的配置中心。这种方案要想可靠,生产环境的 config server 地址绝对不能泄露。可怕的是,我曾经就遇到过直接把 config server 注册到公用 eureka 上面的。
  2. 不同环境使用同一的配置中心,但要做好环境隔离。nacos 则采用这一种,隔离的方案就是命名空间 + 鉴权。和 apollo 不同,客户端去读 nacos 是需要账号密码的,当客户端需要获取生产配置时,运维需要在项目的启动参数中指定生产环境的 namespace 以及对应的账号密码。
 
 
上面说到了 namespace。apollo 和 nacos 都有这个概念,不过,在 apollo 里,namespace 可以看成是一个具体的配置文件,而 nacos 里,namespace 表示具体的环境。它们的数据模型如下图。使用 apollo 是通过连接不同的 config server 来区分环境,而 nacos 则通过指定 namespace 来区分。

 

 
综上,我们知道,要想确保安全,使用 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 打包在一起部署。
 
我们来看看 nacos,首先,它没有将配置中心拆成很多个服务,其次,它的负载均衡方案也比较简单,一个 SLB 就可以搞定。要知道 nacos 同样也维护着与客户端的长连接。
 
 
那么,这两种架构哪种更好呢?我会更倾向于使用 nacos,至少中小型系统我会这么选择,因为它更简单。不过,apollo 考虑到长连接对 SLB 的负担而增加了那么多组件,按理是经过了深思熟虑,所以,我很想知道,在大型系统中使用 nacos,是否有遇到过 SLB 瓶颈的案例,希望有大佬指点。

 

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

 

最后,感谢阅读。