今天，本文将重点分析nacos和apollo的设计差异；以下分析基于apollo1.8.0和nacos2.1.0。安全性的区别这里说的安全性并不是说控制台读取配置中心，而是客户端读取配置中心。前面说过，如果所有环境共享一个配置中心，就会出现安全问题。因为开发者可以获得测试环境的配置，也可以获得生产环境的配置。为了解决这个问题，一般有两种解决方案：①不同的环境使用不同的配置中心。阿波罗使用这种类型。当客户端需要获取生产配置时，运维需要在项目的启动参数中指定生产环境的配置中心。如果这个方案要靠谱，生产环境的configserver地址一定不能泄露。可怕的是我遇到过直接注册configserver到publiceureka。②不同的环境使用同一个配置中心，但是环境之间要做好隔离。nacos就采用了这种方式，隔离方案是namespace+authentication。与Apollo不同，客户端读取nacos需要账号密码。当客户端需要获取生产配置时，运维需要在项目启动参数中指定生产环境的命名空间和对应的账号密码。上面提到的命名空间。apollo和nacos都有这个概念。但是在apollo中，namespace可以看作是一个具体的配置文件，而在nacos中，namespace代表的是一个具体的环境。它们的数据模型如下图所示：apollo通过连接不同的configserver来区分环境，而nacos通过指定命名空间来区分。综上所述，我们知道为了保证安全，使用apollo时不能泄露configserver生产环境的地址，使用nacos时不能泄露生产环境namespace对应的账号密码。如果要说哪种方案更安全的话，我更喜欢nacos，因为服务器地址会比账号密码更容易被泄露。系统复杂度的差异在谈到apollo的设计时，我抱怨apollo的架构太笨重。首先，它把配置中心拆分成了configservice、adminservice和portal，这个我可以接受。不能接受的是apollo为了实现客户端到config服务的负载均衡，引入了太多的组件。如图所示，添加了SLB、metaserver、eureka等组件。我真的觉得没必要直接用SLB做负载均衡。但官方表示，之所以这样设计，是为了避免client和configservice之间的长连接给SLB增加过多的负担。这么说也不无道理。但是，更好的一点是，apollo将configservice、eureka和metaserver打包部署在一起。我们来看看nacos。首先，它没有把配置中心拆分成很多服务。其次，它的负载均衡方案比较简单，一个SLB就可以搞定。要知道nacos也是和客户端保持着长连接的。那么，这两种架构哪个更好呢？我会更倾向于使用nacos，至少中小型系统是这样，因为它更简单。
