SCI论文（www.lunwensci.com）
摘要：在云原生环境下的应用软件开发中,使用配置文件管理配置的传统方法费时费力,应用的可持续交付能力较差。而现有配置中心从数据库中读取配置,高并发场景下性能较差。针对以上问题,对现有配置中心Nacos进行改进,提出了一种Informer模型,设计并实现了一个云原生环境中基于缓存的配置中心,该配置中心将配置从应用中抽离,统一由配置中心管理,并且修改配置后可以立即生效,提高了应用的可持续交付能力。与现有配置中心基于数据库查询相比,该配置中心基于缓存查询,以提高查询效率。每一类配置项均添加了Informer,实现缓存与数据库的数据一致性。实验结果表明,该配置中心可以实现热更新,与现有配置中心相比,在不同高并发场景下,查询性能提升13.33%58.21%。
关键词：配置中心,缓存,高并发,云原生,Nacos,热更新
【Abstract】：In application development in cloud-native environment,the traditional approach of using configuration files to manage configurations is so time-consuming and laborious that the continuous delivery of applications is poor.The existing configuration center gets configuration from database and has poor performance in high concurrency scenarios.In view of this,we make some improvements to the existing configuration center Nacos and propose an Informer model to design and implement a cache-based configuration center in cloud-native environment,which separates the configuration from the application and makes it to be managed by the configuration center.Modifications to the configuration can take effect immediately,so the continuous delivery of the application is improved.Compared with the existing configuration center based on database queries,this configuration center is based on cache queries to improve query performance.Informer is added to each type of configuration item to achieve data consistency between cache and database.Experimental results show that this configuration center can implement hot update and in different high concurrency scenarios,using our configuration center can obtain an improvement in the query performance ranging from 13.33%to 58.21%compared to the existing configuration center.
【Key words】：configuration center;cache;high concurrency;cloud native;Nacos;hot update
引言:在云原生环境下的现代应用开发过程中,系统架构正在从单体架构转向微服务架构,一个应用往往是由多个微服务协同工作组成的[1],而在众多微服务中,开发人员为了实现系统功能往往需要大量的配置文件。传统的微服务配置方式是将配置写成配置文件,保存在项目的特定路径下。如果需要修改某一个配置,则开发者先在本地做出修改,接着把修改提交到远端代码仓库,比如Gitee、GitLab、Github等,要重新部署并且发布新版本应用后这些配置才生效。这种传统做法具有耗时耗力且流程复杂[2]、可持续交付能力差、在高并发场景下性能较差等缺点。
因此在现代化应用开发中,开发人员往往使用配置中心来进行配置管理[3,4]。使用配置中心管理配置的好处如下：
（1）灵活性。使用配置中心可以方便地实现对配置的修改和发布,提高开发效率。
（2）实时性。部分配置中心支持配置修改后立即生效,而无须等待重新部署应用[5]。
（3）安全性。通过配置中心修改的配置可以采用灰度发布[6]的方式进行更新,同时配置中心也能保证在不同部署环境下应用程序配置的隔离性。
为了满足云原生环境下开发人员对应用配置管理的需求,基于现有配置中心的优缺点,在继承其灵活性、实时性和安全性等优点的同时,使用基于缓存查询的方法解决其在高并发场景下由于数据库查询请求数激增导致的查询效率下降问题,并通过一种Informer模型来保证缓存和数据库的数据一致性,本文设计实现了一个云原生环境中基于缓存的配置中心。
1相关技术研究
1.1配置概念
云原生环境下的应用开发需要配置许多的参数,比如数据库链接地址及账号密码、服务启动端口、使用第三方API的AccessKeyId、AccessKeySecret等,这些被称为配置。配置中心的作用是将配置从应用中抽离出来单独管理,方便应用的开发人员和运维人员更方便快捷地管理配置。
1.2现有配置中心对比
本节对现有配置中心进行对比并且选型：
（1）Disconf是百度开源的一套完整的基于Zookeeper的分布式配置管理解决方案。Disconf支持配置的分布式化管理,即配置发布、更新的统一化和配置更新自动化,同时提供了稳定有效的容灾方案,以及用户体验良好的编程模型和Web用户管理界面。
（2）Spring Cloud Config基于Spring环境,可以无缝集成在Spring应用中,并且为配置管理提供了服务端和客户端支持,可以集中管理不同环境下的应用配置。同时配置服务器存储后端的默认实现方式基于Git,可以使用相关Git工具实现对配置的版本管理。
（3）Nacos是阿里巴巴开源的配置管理中心,致力于帮助发现、配置和管理微服务。Nacos提供了动态配置服务,使用户可以以中心化、外部化和动态化的方式管理所有环境的应用配置和服务配置,并且支持配置热更新,修改配置无须重新部署运行应用和服务,使服务可以更好地按需弹性扩展。
经过对比,最终决定使用Nacos作为基础配置中心,并对其进行改进。理由如下：
（1）Disconf目前已经停止维护,版本更新升级停滞,考虑到后续的功能升级,不适用于做基础配置中心。
（2）Spring Cloud Config不支持热更新配置功能,除此之外在配置更新推送时,还需要Git的WebHook、Spring Cloud Bus和客户端/bus/refresh端点,但Spring Cloud Bus链路较长且复杂,配置推送效率低。
（3）Nacos实现了基本配置中心需要的功能,并且可以实现配置热更新、灰度发布等功能。
2基于缓存的配置中心的设计与实现
基于现有配置中心Nacos进行改进,设计并实现一个云原生环境中基于缓存的配置中心。使用该配置中心可以实现以下几点：
（1）将配置从应用中抽离出来,使应用程序无须管理配置。与传统使用配置文件管理配置的方式相比,该配置中心让配置管理流程变得更加方便,简单易用。
（2）应用程序的配置统一由配置中心管理,修改配置时只需要开发人员在线上修改配置后立即生效,提高了应用的可持续交付能力。对比与传统使用配置文件的方式,该配置中心实现了配置的热更新以及灰度发布功能,使配置修改可以实时生效并且安全可靠。
（3）与现有配置中心基于数据库查询相比,本配置中心基于缓存查询配置,大大提高了查询效率,降低性能损耗。与现有的配置中心相比,该配置中心将配置缓存在内存中,客户端每次查询配置都是直接从内存中查询,降低了服务端性能压力,提高了查询效率。并且当客户端需要更新配置时,可以将内存与数据库中的数据同步更新。
（4）设计并实现一种Informer模型,通过为每一类配置项添加Informer实现缓存与数据库的数据一致性。采用内存做缓存,将配置保存在内存中,这就涉及到缓存与数据库中数据一致性的问题。因此提出了一种Informer模型,当客户端对配置进行更新时,通过Informer告知缓存中的配置进行数据刷新,从而保证缓存与远端数据库的数据一致性。
2.1 Nacos原理及架构
2.1.1相关概念
（1）配置项（Configuration Item）：一般以键值对形式存在,是某一个参数的取值。
（2）命名空间（Namespace）：用于做配置的环境隔离,不同命名空间下可能有相同名称的配置。
（3）配置集（Configuration Set）：一个或者多个配置项的集合,通常对应一个配置文件。
（4）配置Id（data Id）：用于表示配置集的唯一Id。
2.1.2配置模型
Nacos配置模型如图1所示。通过Nacos控制台,可以对配置进行发布、更新、删除、灰度、版本管理等功能。通过SDK,可以提供发布配置、更新配置、监听配置等功能,并且通过GRPC长连接监听配置变更。服务端通过对比客户端配置的MD5值和本地MD5值是否相等来判断是否需要推送配置。
2.2 Infomer模型
针对现有配置中心每次查询需要从数据库中查询的缺点,提出了一种Informer模型,相较于现有配置中心基于数据库查询,Informer模型基于缓存查询配置,大大提高了查询效率。此外,该Informer模型监听配置集,当一个配置集发生修改时,会自动刷新缓存中的配置数据,保证了缓存和远端数据库的数据一致性。
2.2.1模型提出
在现代应用程序开发中,可以通过如下方式使用现有配置中心(以Nacos为例)对配置进行管理：先调用Nacos的SDK,Nacos服务端再从存储相应配置的数据库中查询所需配置信息并返回给客户端。这种方案的优点是相较于传统使用配置文件的方法,每一次更新配置后无须重新部署应用。但是缺点也十分明显,即该方案实际上就是从数据库中查询配置,由于在处理流程中新增了一个Nacos服务端的处理过程,在高并发场景下对数据库查询还会影响应用性能,无法充分发挥使用配置中心进行配置管理的优势。
由于常规的通过SDK使用Nacos配置中心的方案无法很好地发挥其在高并发场景下的优势,故需要对现有配置中心进行优化,该优化需要解决以下三个问题：
（1）采用缓存思想,在内存中添加一个缓存区用于存储配置,使客户端需要获取配置时可以直接从内存中获取,从而提高配置获取的效率。
（2）如果将配置缓存在内存中,则需要解决内存中配置与远端数据库中配置的数据一致性。
（3）Nacos中默认的配置刷新方式是,通过各个客户端向Nacos服务端轮询发送HTTP短连接查询相关配置是否发生改变,Nacos服务端通过MD5值的比对判断配置是否改变。当使用Nacos服务端的客户端程序较多时,就可能使Nacos服务端的负荷过高,从而影响Nacos的性能以及整个系统的稳定性。因此需要优化配置的刷新方式,使配置中心内存储的配置发生修改时,内存中对应的缓存配置可以同步刷新,并且还能解决Nacos服务端潜在的负荷过高问题。
2.2.2 Informer原理
对于Nacos中的每一个配置集(对应传统方式的一个配置文件),将其抽象成一个实现了Config接口的配置类,下文以管理OSS相关配置的配置类OSSConfig为例对Informer的原理进行说明。当客户端每次获取OSS的相关配置时,不通过Nacos服务端向数据库查询,而是通过OSSConfig类中的公开静态变量ossConfigJson来获取配置,该变量是一个存储了OSS配置信息的JSON字符串。在应用生命周期内,只有在初始化时会通过Nacos服务端从数据库初始化ossConfigJson,之后便不再与远端数据库有任何直接联系。当客户端需要获取OSS配置时,直接访问ossConfigJson即可,这样就通过一个静态变量实现了把远端配置信息缓存在本机的内存中。
OSSConfig类实现了自定义的Config接口,该接口有一个refreshConfig函数,用于实现动态刷新配置。当配置中心内有关OSS的配置发生变化时,会调用OSSConfig类中的refreshConfig函数,将ossConfigJson修改为最新配置信息,这样就保证了内存中配置与远端数据库中配置的数据一致性。
对于Nacos中的每一个配置集,如图2所示在本模型中均设置了一个相应的Informer用于监听配置修改。使各个客户端不主动向Nacos服务端发送请求查询配置是否变化,而是当Nacos配置中心中的配置发生变化时,由Nacos服务端主动通知客户端,让客户端对内存中对应的缓存配置进行刷新,这样就能显著降低Nacos服务端的压力,使配置中心可以稳定运行。在具体实现中,首先定义了一个监听器类NacosConfigListener,该监听器类实现了Nacos提供的com.alibaba.nacos.api.config.listener.Listener接口,可以监听配置中心内配置信息的变动情况,当OSS相关配置发生修改时可以接收到修改后配置的JSON字符串,将该字符串作为参数传递给OSSConfig类中的refreshConfig函数,并调用该函数刷新内存中缓存的OSS配置。接着定义了一个通NacosConfigInformer,该通知器类的各变量说明如表1所示。NacosConfigInformer继承自Thread类,对于系统内的每一个配置,会启动一个线程去监听配置修改,在每个线程中会把对应配置的监听器运行起来,当对应配置发生变化时,监听器可以利用Java反射机制调用对应配置类的refreshConfig函数刷新内存中的配置。
（1）将配置从应用中抽离出来,使得应用程序无须管理配置。
（2）应用程序的配置统一由配置中心管理,修改配置时只需要开发人员在线上修改配置后立即生效,提高了应用的可持续交付能力。
（3）与现有配置中心基于数据库查询相比,该配置中心基于缓存查询配置,大大提高了查询效率,降低性能损耗。
（4）通过为每一类配置项添加Informer来实现缓存与数据库的数据一致性。
3实验结果分析
本节对云原生环境中基于缓存的配置中心进行性能对比实验,以验证其性能。本节采用压力测试工具Apache JMeter[7]进行压力测试,通过在测试时设置不同的每秒处理事务数(Transaction Per Second,TPS)来模拟不同的并发用户数场景,其中一个完整的事务包括了从发出请求到收到响应结果的全过程。测试中选择了两组TPS值,其中第一组TPS值为250、500、750和1000,用于模拟正常并发场景,第二组TPS值为1250、1500、1750和2000,用于模拟一些高并发场景。TPS值越高,配置中心每秒需要处理的获取配置请求数越多,也就相当于模拟了更大的并发用户数。同时选择了平均响应时间(Response Time,RT)作为配置中心获取配置的性能衡量指标,RT值越小代表配置中心可以更快地处理获取配置的请求,即具有更好的性能。
正常并发下的性能对比实验结果如表2所示,性能对比图如图3所示,高并发下的性能对比实验结果如表3所示,性能对比图如图4所示。其中PIR是性能提升比,RTbefore为原始Nacos配置中心响应请求所需的平均响应时间,RTarter为基于缓存的配置中心响应请求所需的平均响应时间。
通过对比实验发现,使用基于缓存的配置中心获取配置的响应时间始终优于原始Nacos配置中心。且随着TPS值的增加,基于缓存的配置中心的性能提升更为显著,因此解决了在高并发场景下配置中心性能较差的问题。具体来说,在正常并发场景下,随着测试过程中TPS值的增加,两个配置中心处理用户的获取配置请求所需的平均响应时间均随之增加,当TPS值相同时,基于缓存的配置中心相较于原始的Nacos配置中心平均有接近30%的性能提升。而在高并发场景下,随着TPS值的增加,原始Nacos配置中心的性能受到了较为明显的影响,特别当TPS值从1750增加到2000时,所需平均响应时间的增涨幅度已经超过了50%,而基于缓存的配置中心在高并发场景下的性能则十分稳定,所需的平均响应时间几乎不变,而且在TPS值为2000的高并发场景下仍可将平均响应时间控制在400ms以内,性能表现相当优秀。因此该云原生环境下基于缓存的配置中心可以很好地投入到实际应用中,在并发越高的场景下,其相较于原始Nacos配置中心的性能提升就越为明显。
4结语
现代应用软件开发过程中,随着系统架构从单体架构向微服务架构演进,一个系统级应用往往包含多个微服务,而每一个微服务中存在大量的配置项。传统的使用配置文件管理配置的方法耗时耗力、流程复杂,并且在更新配置文件后需要重新部署应用才能够使配置生效,降低了应用的可持续交付能力。因此现代应用软件开发一般使用配置中心来管理应用配置,但是采用原始的配置中心来管理配置的方法采用从数据库中读取配置,并且存在高并发场景下性能较差的问题。
针对上述提到的问题,本文设计并实现了一个云原生环境中基于缓存的配置中心,并通过实验验证了其热更新特性以及在一些高并发场景下相较于原始配置中心的性能优势。该配置中心可以很好地应用于实际软件开发中,在一些高并发场景下有着十分优秀的性能表现。
参考文献
[1]DRAGONI N,GIALLORRNZO S,LAFUENTE A,et al.Mic roservices:Yesterday,today,and Tomorrow[J].Present and Ulterior Software Engineering,2017,4:195-216.
[2]CONRADI R,WESTFECHTEL B.Version Models for Software Configuration Management[J].ACM Computing Surveys,1998,30(2):232-282.
[3]DART S.Concepts in Configuration Management Systems[C]//Proceedings of the 3rd International Workshop on Soft-ware Configuration Management,1991:1-18.
[4]FEILER P H.Configuration Management Models in Com-mercial Environments[M].Pittsburgh,PA:Carnegie MellonUniversity,Software Engineering Institute,1991.
[5]JIANG Y,ZHANG N,REN Z.Research on Intelligent Monitoring Scheme for Microservice Application Systems[C]//2020 International Conference on Intelligent Transportation,Big Data&Smart City(ICITBS).IEEE,2020:791-794.
[6]PARNIN C,HELMS E,ATLEE C,et al.The top 10 adages in Continuous Deployment[J].IEEE Software,2017,34(3):86-95.[7]HALILI E H.Apache JMeter[M].Birmingham:Packt Publishing,2008:15-17.
关注SCI论文创作发表，寻求SCI论文修改润色、SCI论文代发表等服务支撑，请锁定SCI论文网！ 文章出自SCI论文网转载请注明出处：https://www.lunwensci.com/jisuanjilunwen/74481.html
