因为公司进行系统的服务化拆分,导致模块骤增,随之而来配置文件管理难度也随之增加,所以想采用一个配置集中管理的中间件。
下面对市面比较流行的Naocs和Apollo从各方面进行比较。
1. 配置中心
1.1 什么是配置
应用程序在启动和运行的时候往往需要读取一些配置信息,配置基本上伴随着应用程序的整个生命周期,比如:数 据库连接参数、启动参数等。
配置主要有以下几个特点:
配置对于程序是只读的,程序通过读取配置来改变自己的行为,但是程序不应该去改变配置
配置贯穿于应用的整个生命周期,应用在启动时通过读取配置来初始化,在运行时根据配置调整行为。
比如:启动时需要读取服务的端口号、系统在运行过程中需要读取定时策略执行定时任务等。
常见的有程序内部hard code,配置文件,环境变量,启动参数,基于数据库等
同一份程序在不同的环境(开发,测试,生产)、不同的集群(如不同的数据中心)经常需要有不同的配置,所以需要有完善的环境、集群配置管理
1.2 什么是配置中心
在分布式服务架构中,当系统从一个单体应用,被拆分成分布式系统上一个个服务节点后,配置文件也必须跟着迁移 (分割),这样配置就分散了,不仅如此,分散中还包含着冗余,如下图
而配置中心将配置从各应用中剥离出来,对配置进行统一管理,应用自身不需要自己去管理配置。如下图
配置中心的服务流程如下:
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.客户端
- <dependency>
- <groupId>com.alibaba.nacos</groupId>
- <artifactId>nacos-client</artifactId>
- <version>1.4.1</version>
- </dependency>
- <dependency>
- <groupId>com.alibaba.nacos</groupId>
- <artifactId>nacos-spring-context</artifactId>
- <version>1.0.0</version>
- </dependency>
- <!--NacosServer地址-->
- <nacos:global-properties server-addr="192.168.134.128:8848" />
- <!--在NacosServer配置的文件-->
- <nacos:property-source data-id="application.properties"
- group-id="redirectpaymentservice"
- auto-refreshed="true"/>
- @Service("Tx2101")
- public class Tx2101 extends TxBase {
- @NacosValue(value = "${useLocalCacheSwitch}", autoRefreshed = true)
- private boolean useLocalCacheSwitch;
- @Override
- public Document process(Document document) throws CodeException {
- System.out.println("是否刷新缓存:" + useLocalCacheSwitch);
- return null;
- }
- }
3.效果
- 是否刷新缓存:false
- 是否刷新缓存: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的基础模型:
2.2.4 开发
Apollo支持API方式和Spring整合方式 。
API方式灵活,功能完备,配置值实时更新(热发布),支持所有Java环境。
Spring方式接入简单,如
Spring方式也可以结合API方式使用,如注入Apollo的Config对象,就可以照常通过API方式获取配置了
下面只介绍下Spring整合Apollo方式,做一个演示:
1.服务端
2.客户端
- <dependency>
- <groupId>com.ctrip.framework.apollo</groupId>
- <artifactId>apollo-client</artifactId>
- <version>1.1.0</version>
- </dependency>
- <apollo:config/>
- -Dapp.id=RedirectPaymentService -Denv=DEV -Ddev_meta=http://localhost:8080
- @Service("Tx2101")
- public class Tx2101 extends TxBase {
- @Value("${useLocalCacheSwitch:false}")
- private boolean useLocalCacheSwitch;
- @Override
- public Document process(Document document) throws CodeException {
- System.out.println("是否刷新缓存:" + useLocalCacheSwitch);
- return null;
- }
- }
3.效果
- 是否刷新缓存:false
- 是否刷新缓存: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。
本文转载自公众号读芯术(ID:AI_Discovery) 如果你即将要面临大型科技公司的技术...
与普通的IDC机房或服务器厂商相比,阿里云提供的云服务器ECS具有高可用性、安全...
开源 RPC 框架有哪些呢?一类是跟某种特定语言平台绑定的,另一类是与语言无关即...
为了使伸缩组自动加入的实例自动部署应用,您需要创建私有镜像,确保该镜像上有...
最近,在为 Coco 优化分层架构之时,我陷入了各种决策困难之中。所以我通过不断...
计算的下一步发展是什么,将如何影响组织的战略?专家预测了边缘计算在2021年的发...
游戏市场的热度已经不言而喻,随着民众生活水平的提升,大家对于精神娱乐生活的...
来源 | 阿里飞天CIO学堂微信公众号 金融数字化转型过程中,市场的细微变化,客户...
一、背景 ? 我们大部分人的编程习惯都是线性编程,所谓线性编程就是一个请求涉及...
一、数据中台是真的热 在2018年之前可能只有一少部分人在谈中台,从2018年下半年...