今天这篇文章将重点分析 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，至少中小型系统我会这么选择，因为它更简单。
