文章详情

短信预约-IT技能 免费直播动态提醒

请输入下面的图形验证码

提交验证

短信预约提醒成功

分布式配置中心(Nacos、Apollo)选型比较

2024-12-03 10:59

关注

下面对市面比较流行的Naocs和Apollo从各方面进行比较。


1. 配置中心

1.1 什么是配置

应用程序在启动和运行的时候往往需要读取一些配置信息,配置基本上伴随着应用程序的整个生命周期,比如:数 据库连接参数、启动参数等。

配置主要有以下几个特点:

配置对于程序是只读的,程序通过读取配置来改变自己的行为,但是程序不应该去改变配置

配置贯穿于应用的整个生命周期,应用在启动时通过读取配置来初始化,在运行时根据配置调整行为。

比如:启动时需要读取服务的端口号、系统在运行过程中需要读取定时策略执行定时任务等。

常见的有程序内部hard code,配置文件,环境变量,启动参数,基于数据库等

同一份程序在不同的环境(开发,测试,生产)、不同的集群(如不同的数据中心)经常需要有不同的配置,所以需要有完善的环境、集群配置管理

1.2 什么是配置中心

在分布式服务架构中,当系统从一个单体应用,被拆分成分布式系统上一个个服务节点后,配置文件也必须跟着迁移 (分割),这样配置就分散了,不仅如此,分散中还包含着冗余,如下图

而配置中心将配置从各应用中剥离出来,对配置进行统一管理,应用自身不需要自己去管理配置。如下图


配置中心的服务流程如下:

用户在配置中心发布、更新配置信息。

服务A和服务B及时得到配置更新通知,从配置中心获取配置。

总得来说,配置中心就是一种统一管理各种应用配置的基础服务组件。

1.3 为什么需要配置中心

随分布式微服务的发展,服务节点越来越多,配置问题逐渐显现出来:

在这样的大环境下,传统的通过配置文件、数据库等方式已经越来越无法满足开发人员对配置管理的需求。

1.4 配置中心小结

总结一下,在传统巨型单体应用纷纷转向分布式服务架构的历史进程中,配置中心是服务化不可缺少的一个系统组件,在这种背景下中心化的配置服务即配置中心应运而生,一个合格的配置中心需要满足如下特性:

整个配置中心的作用系统运行时能够动态调整程序的行为。

2. 开源配置中心介绍

目前市面流行的配置中心有:

2014年7月,百度开源的配置管理中心,同样具备配置的管理能力,不过目前已经不维护了 。

2014年9月,Spring Cloud 开源生态组件,可以和Spring Cloud体系无缝整合,但依赖Git或SVN 。

2016年5月,携程开源的配置管理中心,具备规范的权限、流程治理等特性。

2018年6月,阿里开源的配置中心,也可以做RPC的服务发现。

因Disconf不再维护,且Spring Cloud Config 需要依赖Git或SVN。所以只介绍下Apollo和Nacos

2.1 Nacos

Nacos包含的注册中心+配置中心,以下只说配置中心。

2.1.1 简介

Nacos 致力于帮助服务发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理。

Nacos 更敏捷和容易地构建、交付和管理微服务平台。Nacos 是构建以“服务”为中心的现代应用架构 (例如微服务范式、云原生范式) 的服务基础设施。

2.1.2 特性

Nacos 支持几乎所有主流类型的服务发现、配置和管理,现只说Nacos的配置中心功能。

2.1.3 架构

Nacos配置中心分为Server与Client,server采用Java编写,为client提供配置服务。

Client可以用多语言实现,Client与服务模块嵌套在一起,Nacos提供SDK和OpenAPI,如果没有SDK也可以根据OpenAPI手动写服务注册与发现和配置拉取的逻辑 。

配置中心架构图:


2.1.4 开发

Nacos配置中心支持与Spring、Spring Boot、Spring Cloud整合,通过xml或注解方式即可轻松实现。演示下与Spring项目进行整合。

服务端

控制台发布配置截图

客户端

  1.  
  2.      com.alibaba.nacos 
  3.      nacos-client 
  4.      1.4.1 
  5.   
  6.   
  7.      com.alibaba.nacos 
  8.      nacos-spring-context 
  9.      1.0.0 
  10.   
  1. --NacosServer地址--> 
  2. global-properties server-addr="192.168.134.128:8848" /> 
  3. --在NacosServer配置的文件--> 
  4. "application.properties"  
  5.                        group-id="redirectpaymentservice"  
  6.                        auto-refreshed="true"/> 

  1. @Service("Tx2101"
  2. public class Tx2101 extends TxBase { 
  3.  
  4.     @NacosValue(value = "${useLocalCacheSwitch}", autoRefreshed = true
  5.     private boolean useLocalCacheSwitch; 
  6.  
  7.     @Override 
  8.     public Document process(Document document) throws CodeException { 
  9.         System.out.println("是否刷新缓存:" + useLocalCacheSwitch); 
  10.         return null
  11.     } 

效果

  1. 是否刷新缓存:false 

  1. 是否刷新缓存:true 

2.1.5 灰度

Nacos服务端修改配置后,勾选Beat发布,指定IP地址,然后选择发布Beta。


2.1.5 部署

在单机模式下,Nacos没有任何依赖,默认使用内嵌的数据库作为存储引擎,也可换成mysql;在集群模式下,Nacos依赖Mysql做存储。

生产环境使用Nacos为了达到高可用不能使用单机模式,需要搭建nacos集群。

下图是官方推荐的集群方案,通过域名 + VIP模式的方式来实现。客户端配置的nacos,当Nacos集群迁移时,客户端配置无需修改。

集群部署架构图:

集群部署架构图

2.1.7 小结

Nacos使用简单、部署方便、性能较高,能够实现基本的配置管理,提供的控制台也非常简洁。

但权限方面控制粒度较粗,且没有审核机制。

2.2 Apollo

2.2.1 简介

Apollo(阿波罗)是携程框架部门研发的分布式配置中心,能够集中化管理应用的不同环境、不同集群的配置,配 置修改后能够实时推送到应用端,并且具备规范的权限、流程治理等特性,适用于微服务配置管理场景。

Apollo包括服务端和客户端两部分:

服务端基于Spring Boot和Spring Cloud开发,打包后可以直接运行,不需要额外安装Tomcat等应用容器。Java客户端不依赖任何框架,能够运行于所有Java运行时环境,同时对Spring/Spring Boot环境也有较好的支持。

2.2.2 特性

基于配置的特殊性,所以Apollo从设计之初就立志于成为一个有治理能力的配置发布平台,目前提供了以下的特性:

2.2.3 架构

Apollo架构从外部和内部进行分析

基础模型

如下即是Apollo的基础模型

  1. 用户在配置中心对配置进行修改并发布
  2. 配置中心通知Apollo客户端有配置更新
  3. Apollo客户端从配置中心拉取最新的配置、更新本地配置并通知到应用

2.2.4 开发

Apollo支持API方式和Spring整合方式 。

API方式灵活,功能完备,配置值实时更新(热发布),支持所有Java环境。

Spring方式接入简单,如

Spring方式也可以结合API方式使用,如注入Apollo的Config对象,就可以照常通过API方式获取配置了

下面只介绍下Spring整合Apollo方式,做一个演示:

服务端


客户端

  1.   
  2.     com.ctrip.framework.apollo   
  3.     apollo-client   
  4.     1.1.0  
  5.  
  1.  

  1. -Dapp.id=RedirectPaymentService -Denv=DEV -Ddev_meta=http://localhost:8080 

  1. @Service("Tx2101"
  2. public class Tx2101 extends TxBase { 
  3.  
  4.     @Value("${useLocalCacheSwitch:false}"
  5.     private boolean useLocalCacheSwitch; 
  6.  
  7.     @Override 
  8.     public Document process(Document document) throws CodeException { 
  9.         System.out.println("是否刷新缓存:" + useLocalCacheSwitch); 
  10.         return null
  11.     } 

效果

  1. 是否刷新缓存:false 

  1. 是否刷新缓存:true 

2.2.5 灰度

Apollo控制台创建灰度版本,配置灰度规则,指定灰度的IP或AppID。


指定的IP节点或AppID模块的配置被更新

2.2.6 部署

Apollo高可用架构模块的概览 :


上图简要描述了Apollo的总体设计,我们可以从下往上看:

2.2.7 小结

Apollo在配置管理流程上比较完善,相应配置的发布审核、权限管理等、配置的继承等,但Apollo需要使用人员进行简单学习,存在学习成本。

Appollo部署较为复杂需要3个模块同时工作,部署一套生产高可用集群至少需要7个节点。

3. 总结

3.1 功能比较

3.2 结论

从配置中心角度来看,性能方面Nacos的读写性能最高,Apollo次之;功能方面Apollo最为完善,但Nacos具有Apollo大部分配置管理功能。Nacos的一大优势是整合了注册中心、配置中心功能,部署和操作相比 Apollo都要直观简单,因此它简化了架构复杂度,并减轻运维及部署工作。

总的来看,Apollo和Nacos生态支持都很广泛,在配置管理流程上做的都很好。Apollo相对于Nacos在配置管理做的更加全面;Nacos则使用起来相对比较简洁,在对性能要求比较高的大规模场景更适合。

对于公司目前来说,修改配置的次数不是特别的频繁,对于配置权限的管理不是特别严格的,且对读写性能有一定要求的,可采用Nacos,反之使用Apollo。

 

来源:Java养基场内容投诉

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

软考中级精品资料免费领

  • 历年真题答案解析
  • 备考技巧名师总结
  • 高频考点精准押题
  • 2024年上半年信息系统项目管理师第二批次真题及答案解析(完整版)

    难度     813人已做
    查看
  • 【考后总结】2024年5月26日信息系统项目管理师第2批次考情分析

    难度     354人已做
    查看
  • 【考后总结】2024年5月25日信息系统项目管理师第1批次考情分析

    难度     318人已做
    查看
  • 2024年上半年软考高项第一、二批次真题考点汇总(完整版)

    难度     435人已做
    查看
  • 2024年上半年系统架构设计师考试综合知识真题

    难度     224人已做
    查看

相关文章

发现更多好内容

猜你喜欢

AI推送时光机
位置:首页-资讯-后端开发
咦!没有更多了?去看看其它编程学习网 内容吧
首页课程
资料下载
问答资讯