目录 　　

　　

　　介绍安全性的差异，系统复杂性的差异 　　

　　

　　简介 　　

　　

　　分析完携程的apollo，现在来看看阿里的nacos。和apollo一样，nacos也是一个配置中心，同样可以实现集中管理、分环境管理、即时生效等等。但是，nacos也有服务发现的功能。 　　

　　

　　在分析阿波罗时，我们通过四个问题展开： 　　

　　

　　为什么使用配置中心，如何设计配置中心，如何设计apollo以及如何使用apollo 　　

　　

　　当然，我们也可以用同样的套路来分析nacos。不过第一个和第二个问题是一样的，没必要重复。至于第四个问题，我认为官网的文件足够详细。因此，本文将着重分析nacos和apollo的设计差异。 　　

　　

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

　　

　　安全性的差异 　　

　　

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

　　

　　前面说过，如果所有环境共用一个配置中心，会有安全问题。因为开发人员可以获得测试环境的配置，所以他们也可以获得生产环境的配置。 　　

　　

　　 　　

　　

　　为了解决这个问题，通常有两种方案： 　　

　　

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

　　

　　如果这个方案是可靠的，生产环境的配置服务器地址就不能泄露。可怕的是，我遇到过一个直接在公共eureka上注册配置服务器的。 　　

　　

　　 　　

　　

　　不同环境使用同一的配置中心，但要做好环境隔离。的NACOS采用了这种方法，隔离的方案是名称空间认证。 　　

　　

　　与apollo不同，客户端需要一个帐户密码来读取nacos。当客户端需要获取生产配置时，运维需要在项目的启动参数中指定生产环境的命名空间和对应的账户密码。 　　

　　

　　 　　

　　

　　上面写着命名空间。阿波罗和nacos都有这个概念。但是，在apollo中，namespace可以看作是一个特定的配置文件，而在nacos中，namespace代表一个特定的环境。 　　

　　

　　他们的数据模型如下： 　　

　　

　　 　　

　　

　　Apollo用于通过连接不同的配置服务器来区分环境，而nacos用于通过指定名称空间来区分环境。 　　

　　

　　综上所述，我们知道为了保证安全，在使用apollo的时候不应该公开config server生产环境的地址，在使用nacos的时候也不应该公开相应生产环境命名空间的账号密码。 　　

　　

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

　　

　　系统复杂度的差异 　　

　　

　　再次谈到阿波罗的设计时，我抱怨阿波罗的建筑太重了。 　　

　　

　　首先，它把配置中心拆分为配置服务、管理服务和门户，这一点我可以接受。 　　

　　

　　我不能接受的是，为了实现从客户端到配置服务的负载均衡，apollo引入了太多组件。 　　

　　

　　如图所示，添加了SLB、元服务器、eureka和其他组件。我真的觉得没这个必要。直接使用SLB进行负载平衡即可。 　　

　　

　　 　　

　　

　　但该官员表示，这是为了避免客户端和配置服务之间的长时间连接给SLB增加太多负担，这是有道理的。 　　

　　

　　不过，有一点很好，那就是apollo将配置服务、eureka和元服务器打包在一起进行部署。 　　

　　

　　我们来看看nacos。首先，它没有将配置中心拆分成许多服务。其次，它的负载均衡方案比较简单，一个SLB就可以完成。要知道nacos也和客户端保持着很长的联系。 　　

　　

　　 　　

　　

　　那么，这两种架构哪个更好呢？我更倾向于使用nacos，至少对于中小型系统是这样，因为它更简单。 　　

　　

　　但是，阿波罗考虑到长时间连接对SLB的负担，增加了这么多组件，应该是经过深思熟虑的。因此，我想知道在大型系统中使用nacos时，是否存在SLB瓶颈的情况。 　　

　　

　　以上基本完成了nacos的结构和用途。如有错误，请指正。 　　

　　

　　欢迎讨论，在评论区留下你的看法。 　　

　　

　　原文链接：https://mp.weixin.qq.com/s/hKKAI7BWpkf9jhC2qKqRbA