Apollo 太重，最终选择了 Nacos

今天这篇文章将重点分析 nacos 和 apollo 在设计上的差异；以下分析基于 apollo 1.8.0 和 nacos 2.1.0。

安全性的差异

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

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

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

①不同环境使用不同的配置中心。

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

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

②不同环境使用同一的配置中心，但要做好环境隔离。

nacos 则采用这一种，隔离的方案就是命名空间 + 鉴权。

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