前面我们分析了携程的 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。

安全性的差异

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

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

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

1. 不同环境使用不同的配置中心。apollo 用的就是这一种，当客户端需要获取生产配置时，运维需要在项目的启动参数中指定生产环境的配置中心。这种方案要想可靠，生产环境的 config server 地址绝对不能泄露。可怕的是，我曾经就遇到过直接把 config server 注册到公用 eureka 上面的。

1. 不同环境使用同一的配置中心，但要做好环境隔离。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 的结构和使用。如有错误，欢迎指正。

最后，感谢阅读。

参考资料

Nacos 官方文档
本文为原创文章，转载请附上原文出处链接：https://www.cnblogs.com/ZhangZiSheng001/p/16344519.html
分层，抽象，高内聚，低耦合