Apollo太重了，我选Nacos

目录

 • 简介
 • 安全性的差异
 • 系统复杂度的差异

 

简介

 

前面我们分析了携程的 apollo，现在再来看看阿里的 nacos。和 apollo 一样，nacos 也是一款配置中心，同样可以实现配置的集中管理、分环境管理、即时生效等等。不过，nacos 还具备了服务发现的功能。

 

分析 apollo 时，我们通过四个问题展开：

 • 为什么使用配置中心
 • 如何设计一个配置中心
 • apollo 是如何设计的
 • 如何使用 apollo

 

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

 

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

 

安全性的差异

 

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

 

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

为了解决这个问题，一般有两个方案：

 

①不同环境使用不同的配置中心。apollo 用的就是这一种，当客户端需要获取生产配置时，运维需要在项目的启动参数中指定生产环境的配置中心。

 

这种方案要想可靠，生产环境的 config server 地址绝对不能泄露。可怕的是，我曾经就遇到过直接把 config server 注册到公用 eureka 上面的。

②不同环境使用同一的配置中心，但要做好环境隔离。nacos 则采用这一种，隔离的方案就是命名空间 + 鉴权。

 

和 apollo 不同，客户端去读 nacos 是需要账号密码的，当客户端需要获取生产配置时，运维需要在项目的启动参数中指定生产环境的 namespace 以及对应的账号密码。

上面说到了 namespace。apollo 和 nacos 都有这个概念，不过，在 apollo 里，namespace 可以看成是一个具体的配置文件，而 nacos 里，namespace 表示具体的环境。

 

它们的数据模型如下图：

使用 apollo 是通过连接不同的 config server 来区分环境，而 nacos 则通过指定 namespace 来区分。

 

综上，我们知道，要想确保安全，使用 apollo 时不能泄露 config server 生产环境的地址，使用 nacos 时不能泄露对应生产环境 namespace 的账号密码。

 

如果要说哪种方案更安全，我会更倾向于 nacos，因为相比账号密码，服务器地址会更容易泄露。

 

系统复杂度的差异

 

在讲 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 的结构和使用，如有错误，欢迎指正。