配置管理 订阅
配置管理(Configuration Management,CM)是通过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录软件产品的演化过程,确保软件开发者在软件生命周期中各个阶段都能得到精确的产品配置。 展开全文
配置管理(Configuration Management,CM)是通过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录软件产品的演化过程,确保软件开发者在软件生命周期中各个阶段都能得到精确的产品配置。
信息
外文名
Configuration Management
用    于
软件开发
中文名
配置管理
解    释
通过技术对软件产品进行控制
配置管理简介
配置管理过程是对处于不断演化、完善过程中的软件产品的管理过程。一致性、可追溯性,使产品极大程度地与用户需求相吻合。它通过控制、记录、追踪对软件的修改和每个修改生成的软件组成部件来实现对软件产品的管理功能。 [1]  早在七十年代初期加利福利亚大学的Leon Presser教授就撰写了一篇论文,提出控制变更和配置的概念,之后在1975年,他成立了一家名为SoftTool的公司,开发了自己的配置管理工具:CCC,这也是最早的配置管理工具之一。之后,随着软件开发规模的逐渐增大,越来越多的公司和团队意识到了软件配置管理的重要性,而相应的软件配置管理工具也如雨后春笋一般,纷纷涌现,比较有代表性的有:Marc Rochkind的SCCS(Source Code Control System)和Walter Tichy的RCS(Revision Control System),这两种工具对日后的配置管理工具的发展做出了重大的贡献,目前绝大多数广泛使用的配置管理工具基本上都是基于这两者的设计思想和体系架构。配置管理在软件开发过程和项目管理过程中的作用随着软件系统的日益复杂化和用户需求、软件更新的频繁化,配置管理逐渐成为软件生命周期中的重要控制过程,在软件开发过程中扮演着越来越来重要的角色。一个好的配置管理过程能覆盖软件开发和维护的各个方面,同时对软件开发过程的宏观管理,即项目管理,也有重要的支持作用。良好的配置管理能使软件开发过程有更好的可预测性,使软件系统具有可重复性,使用户和主管部门用软件质量和开发小组有更强的信心。软件配置管理的最终目标是管理软件产品。由于软件产品是在用户不断变化的需求驱动下不断变化,为了保证对产品有效地进行控制和追踪,配置管理过程不能仅仅对静态的、成形的产品进行管理,而必须对动态的、成长的产品进行管理。由此可见,配置管理同软件开发过程紧密相关。配置管理必须紧扣软件开发过程的各个环节:管理用户所提出的需求,监控其实施,确保用户需求最终落实到产品的各个版本中去,并在产品发行和用户支持等方面提供帮助,响应用户新的需求,推动新的开发周期。通过配置管理过程的控制,用户对软件产品的需求如同普通产品的订单一样,遵循一个严格的流程,经过一条受控的生产流水线,最后形成产品,发售给相应用户。从另一个角度看,在产品开发的不同阶段通常有不同的任务,由不同的角色担当,各个角色职责明确,泾渭分明,但同时又前后衔接,相互协调。好的配置管理过程有助于规范各个角色的行为,同时又为角色之间的任务传递提供无缝的接合,使整个开发团队像是一个交响乐队一样和谐而又错杂地行进。正因为配置管理过程直接连接产品开发过程、开发人员和最终产品,这些都是项目主管人员所关注的重点,因此配置管理系统在软件项目管理中也起着重要作用。配置管理过程演化出的控制、报告功能可帮助项目经理更好地了解项目的进度、开发人员的负荷、工作效率和产品质量状况、交付日期等信息。同时配置管理过程所规范的工作流程和明确的分工有利于管理者应付开发人员流动的困境,使新的成员可以快速实现任务交接,尽量减少因人员流动而造成的损失。
收起全文
精华内容
下载资源
问答
  • 配置管理

    千次阅读 2012-02-10 09:44:22
    配置管理 科技名词定义 中文名称: 配置管理 英文名称: configuration management 定义: 电信管理网管理功能的一个子集。配置管理控制执行系统的增加或减少,获得组成部件的状态和辨别其...

    配置管理

    科技名词定义

    中文名称:
    配置管理
    英文名称:
    configuration management
    定义:
    电信管理网管理功能的一个子集。配置管理控制执行系统的增加或减少,获得组成部件的状态和辨别其位置的一系列管理功能。
    应用学科:
    通信科技(一级学科);运行、维护与管理(二级学科)
    以上内容由全国科学技术名词审定委员会审定公布

    求助编辑百科名片

    配置管理(Configuration Management,CM)是通过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录软件产品的演化过程,确保软件开发者在软件生命周期中各个阶段都能得到精确的产品配置。

    编辑本段配置管理简介

      配置管理过程是对处于不断演化、完善过程中的软件产品的管理过程。其最终目标是实现软件产品的完整性、一致性、可控性,使产品极大程度地与用户需求相吻合。它通过控制、记录、追踪对软件的修改和每个修改生成的软件组成部件来实现对软件产品的管理功能
      早在七十年代初期加利福利亚大学的Leon Presser教授就撰写了一篇论文,提出控制变更和配置的概
      

    配置管理相关书籍

    念,之后在1975年,他成立了一家名为SoftTool的公司,开发了自己的配置管理工具:CCC,这也是最早的配置管理工具之一。之后,随着软件开发规模的逐渐增大,越来越多的公司和团队意识到了软件配置管理的重要性,而相应的软件配置管理工具也如雨后春笋一般,纷纷涌现,比较有代表性的有:Marc Rochkind的SCCS(Source Code Control System)和Walter Tichy的RCS(Revision Control System),这两种工具对日后的配置管理工具的发展做出了重大的贡献,目前绝大多数广泛使用的配置管理工具基本上都是基于这两者的设计思想和体系架构
      配置管理在软件开发过程和项目管理过程中的作用
      随着软件系统的日益复杂化和用户需求、软件更新的频繁化,配置管理逐渐成为软件生命周期中的重要控制过程,在软件开发过程中扮演着越来越来重要的角色。一个好的配置管理过程能覆盖软件开发和维护的各个方面,同时对软件开发过程的宏观管理,即项目管理,也有重要的支持作用。良好的配置管理能使软件开发过程有更好的可预测性,使软件系统具有可重复性,使用户和主管部门用软件质量和开发小组有更强的信心。
      软件配置管理的最终目标是管理软件产品。由于软件产品是在用户不断变化的需求驱动下不断变化,为了保证对产品有效地进行控制和追踪,配置管理过程不能仅仅对静态的、成形的产品进行管理,而必须对动态的、成长的产品进行管理。由此可见,配置管理同软件开发过程紧密相关。配置管理必须紧扣软件开发过程的各个环节:管理用户所提出的需求,监控其实施,确保用户需求最终落实到产品的各个版本中去,并在产品发行和用户支持等方面提供帮助,响应用户新的需求,推动新的开发周期。通过配置管理过程的控制,用户对软件产品的需求如同普通产品的订单一样,遵循一个严格的流程,经过一条受控的生产流水线,最后形成产品,发售给相应用户。从另一个角度看,在产品开发的不同阶段通常有不同的任务,由不同的角色担当,各个角色职责明确,泾渭分明,但同时又前后衔接,相互协调。
      好的配置管理过程有助于规范各个角色的行为,同时又为角色之间的任务传递提供无缝的接合,使整个开发团队象一个交响乐队一样和谐而又错杂地行进。正因为配置管理过程直接连接产品开发过程、开发人员和最终产品,这些都是项目主管人员所关注的重点,因此配置管理系统在软件项目管理中也起着重要。配置管理过程演化出的控制、报告功能可帮助项目经理更好地了解项目的进度、开发人员的负荷、工作效率和产品质量状况、交付日期等信息。同时配置管理过程所规范的工作流程和明确的分工有利于管理者应付开发人员流动的困境,使新的成员可以快速实现任务交接,尽量减少因人员流动而造成的损失。

    编辑本段配置管理的功能

    并行开发支持

      因开发和维护的原因,要求能够实现开发人员同时在同一个软件模块上工作,同时对同一个代码部分作不同的修改,即使是跨地域分布的开发团队也能互不干扰,协同工作,而又不失去控制;

    修订版管理

      跟踪每一个变更的创造者、时间和原因,从而加快问题和缺陷的确定 ;

    版本控制

      能够简单、明确地重现软件系统的任何一个历史版本 ;
      产品发布管理:管理、计划软件的变更,与软件的发布计划、预先定制好的生命周期或相关的质量过程
      

    配置管理

    保持一致;项目经理能够随时清晰地了解项目的状态 ;

    建立管理

      基于软件存储库的版本控制功能,实现建立(build)过程自动化 ;

    过程控制

      贯彻实施开发规范,包括访问权限控制、开发规则的实施等 ;
      变更请求管理:跟踪、管理开发过程中出现的缺陷(Defect)、功能增强请求(RFE)或任务(Task),加强沟通和协作,能够随时了解变更的状态 ;

    代码共享

      提供良好的存储和访问机制,开发人员可以共享各自的开发资源 ;

    编辑本段配置管理的流程

    制定配置管理计划

      配置管理员制定《配置管理计划》,主要内容包括配置管理软硬件资源、配置项计划、基线计划、交付计划、备份计划等。CCB审批该计划。

    配置库管理

      配置管理员为项目创建配置库,并给每个项目成员分配权限。各项目成员根据自己的权限操作配置库。配置管理员定期维护配置库,例如清除垃圾文件、备份配置库等。

    版本控制

      在项目开发过程中,绝大部分的配置项都要经过多次的修改才能最终确定下来。对配置项的任何修改都将产生新的版本。由于我们不能保证新版本一定比老版本“好”,所以不能抛弃老版本。版本控制的目的是按照一定的规则保存配置项的所有版本,避免发生版本丢失或混淆等现象,并且可以快速准确地查找到配置项的任何版本。
      配置项的状态有三种:“草稿”、“正式发布”和“正在修改”,本规程制定了配置项状态变迁与版本号的规则。

    变更控制

      在项目开发过程中,配置项发生变更几乎是不可避免的。变更控制的目的就是为了防止配置项被随意修改而导致混乱。
      修改处于“草稿”状态的配置项不算是“变更”,无需CCB的批准,修改者按照版本控制规则执行即可。
      当配置项的状态成为“正式发布”,或者被“冻结”后,此时任何人都不能随意修改,必须依据“申请-审批-执行变更-再评审-结束”的规则执行。

    配置审计

      为了保证所有人员(包括项目成员、配置管理员和CCB)都遵守配置管理规范,质量保证人员要定期审计配置管理工作。配置审计是一种“过程质量检查”活动,是质量保证人员的工作职责之一。

    编辑本段配置管理的实施

      实施配置管理系统,一般的步骤和需要考虑的问题如下:
      规划、调整网络开发环境
      一个规划良好的开发环境,是实施配置管理系统的前提。在此阶段我们要对配置管理系统做出规划,主要考虑以下问题:
      * 网络的带宽、拓扑结构
      *服务器的选择、命名规范
      *存储区的定位
      *开发人员及组的命名规约等
      设计配置管理库
      根据项目开发的要求,设计开发资源的存储模式,良好的存储模式有利于减轻管理上的负担,增强配置管理库的访问性能,同时便于控制访问权限,保护软件资产。
      定义配置管理系统的角色
      在此阶段,我们需要确定与配置管理相关的所有角色,包括他们的相应的活动。在开发过程中,一个开发人员可能兼任多种角色,但一项任务在同一时刻只能由一个角色来执行。
      一般配置管理中的角色主要包括:
      项目经理:项目经理在配置管理方面的职责是依靠配置管理员、系统管理员和系统体系结构设计人员的帮助,制定项目的组织结构和配置管理策略。这些工作包括:定制开发子系统,定制访问控制,制定常用策略,制定集成里程碑,以及进行系统集成;
      配置管理员:配置管理员的职责是根据项目经理制定的开发组织结构和策略,实施、维护配置管理的环境。其主要职责如下:创建配置管理库,对存储库进行日常备份和恢复,维护配置管理环境,及管理配置管理相关的用户;
      软件开发人员:软件开发人员依据项目的开发和配置管理策略,创建、修改和测试开发工件;
      集成人员:对软件进行归并,形成相应的基线或发布版本 ;
      QA人员:需要对软件配置管理有较深的认识,其主要工作是跟踪当前项目的状态,测试,报告错误,并验证其修复结果;
      制定配置管理流程
      这是配置管理实施的一个重要阶段,其主要目的是根据项目开发的需要,制定相应的配置管理流程,以更好地支持开发,主要活动包括:
      定制并行开发策略:合理的并行开发策略应该具有以下特点:协调项目的复杂性和需求,统一创建分支类型和元数据,为开发过程中的变更集成制定有效的规范,适时反映开发过程中方法和需求的变化
      发布版本管理:软件开发过程中的一个关键活动是提取工件的相关版本,以形成软件系统的阶段版本或发布版本,我们一般将其称为稳定基线。一个稳定基线代表新开发活动的开始,而一系列定制良好的活动之
      

    配置管理

    后又会产生一个新的稳定基线。有效地利用此项功能,在项目开发过程中可以自始至终管理、跟踪工件版本间的关联。
      烽火猎聘分类来培训相关人员
      一般来讲,实施配置管理系统,相关人员需要接受以下培训:
      管理员培训:针对配置管理员,主要学习配置管理工具管理相关内容
      开发人员培训:针对开发人员,主要学习配置管理工具与开发相关的常用操作
      管理流程培训:针对全体人员,目的是了解配置管理策略和流程,以及如何与开发管理、项目管理相结合

    编辑本段配置管理经验谈

      围绕配置管理,世界一些致力于软件工程研究的公司在深入理解ISO 9000的基础上, 推出了各种符合ISO 9000配置管理标准的工具软件,如INTERSOLV公司的PVCS,Rational公司的Clear Case等。这些配置管理工具面向软件规范化、工程化、自动化的需要,帮助开发团队提高科学管理水平,从而提高工程效率,降低工程成本。现以PVCS为例,结合我们的实际经验,谈谈我们实施配置管理的益处:

    节约费用

      (1) 缩短开发周期
      利用PVCS的Version Manager对程序资源进行版本管理和跟踪,建立公司的代码知识库,保存开发过程中每一过程版本,这样大大提高了代码的重用率,还便于同时维护多个版本和进行新版本的开发,防止系统崩溃,最大限度地共享代码。同时项目管理人员可以通过Version Manager查看项目开发日志,测试人员可以根据开发日志和不同版本对软件进行测试,工程人员可以从Version Manager上得到不同的运行版本,并且Version Manager 可以安装在Web Server供外地施工人员存取最新版本,无需开发人员亲临现场。
      利用Tracker组建开发团体之间的问题跟踪及消息通迅,通过其Notify模块与电子邮件结合起来大大加强了开发团体之间的沟通,Reporter模块可对发现的问题进行整理、以报表方式分类报出,作为开发的指导。
      以上为PVCS的两个主要模块,科学地应用可以大大提高开发效率,避免了代码覆盖、沟通不够、开发无序的混乱局面,如果利用了公司原有的知识库,则更能提高工作效率,缩短开发周期。
      (2) 减少施工费用
      利用PVCS进行软件配置管理后,建立开发管理规范,把版本管理档案挂接在公司内部的Web服务器上,内部直接通过Netscape访问Version Manager,工程人员通过远程进入内部网,获取所需的最新版本。开发人员无需下现场,现场工程人员通过对方系统管理员收集反馈意见,书面提交到公司内部开发组项目经理,开发组内部讨论决定是否修改,并作出书面答复。这样做,可以同时响应多个项目点,防止开发人员分配到各个项目点、分散力量、人员不够的毛病,同时节约大量的旅差费用。

    有利于知识库的建立

      (1) 代码对象
      软件代码是软件开发人员脑力劳动的结晶,也是软件公司的宝贵财富,长期开发过程中形成的各种代码对象就像一个个零件坯一样,是快速生成系统的组成部分。长期的一个事实是:一旦某个开发人员离开工作岗位,其原来所作的代码便基本成为垃圾,无人过问。究其原因,就是没有专门对各人的有用对象进行管理,把其使用范围扩大到公司一级,进行规范化,加以说明和普及。Version Manager为对象管理提供了一个平台和仓库,有利于建立公司级的代码对象库。
      (2) 业务及经验库
      通过PVCS Version Manager的注释及Tracker,可形成完整的开发日志及问题集合,以文字方式伴随开发的整个过程,不依某个人的转移而消失,有利于公司积累业务经验,无论对版本整改或版本升级,都具有重要的指导作用。

    规范管理

      (1) 量化工作量考核
      传统的开发管理中,工作量一直是难以估量的指标,靠开发人员自己把握,随意性相当大;靠管理人员把握,主观性又太强。采用PVCS管理后,开发人员每天下班前对修改的文件 Check In,其中记述当天修改细节描述,这些描述可以作为工作量的衡量指标。
      (2) 规范测试
      采用PVCS以后,测试有了实实在在的工作,测试工作人员根据每天的修改细节描述对每一天的工作做具体的测试,对测试人员也具有可考核性,这样环环相扣,大大减少了其工作的随意性。
      (3) 加强协调与沟通
      采用PVCS后,通过Version Manager文档共享及其特定锁机制、Tracker与电子邮件的集成,大大加强了项目成员之间的沟通,做到有问题及时发现、及时修改、及时通知,但又不额外增加很多的工作量。

    编辑本段配置管理的精髓

      具体来讲,配置管理包含如下内容:
      
    展开全文
  • 关于配置管理系统和配置管理项:  配置管理系统的定义是  整个项目管理系统的一个子系统。它由一系列正式的书面程序组成,用于对以下工作提供技术和管理方面的指导与监督:识别并记录产品、成果、服务或部件的...

    http://www.51testing.com/html/72/n-3723172.html

    关于配置管理系统和配置管理项:

      配置管理系统的定义是

      整个项目管理系统的一个子系统。它由一系列正式的书面程序组成,用于对以下工作提供技术和管理方面的指导与监督:识别并记录产品、成果、服务或部件的功能特征和物理特征;控制对上述特征的任何变更;记录并报告每一项变更及其实施情况;支持对产品、成果或部件的审查,以确保其符合要求。该系统包括文件和跟踪系统,并明确了为核准和控制变更所需的批准层次。

      配置管理系统的作用是

      1. 识别产品和组成部分功能和属性

      2. 控制上述特征的变更

      3. 记录每个变更实施情况

      4. 辅助审核,核实是否符合要求

      在项目中,使用包含变更控制过程的配置管理系统的目标是

      1. 建立一种先进的方法,以便规范地识别和提出对既定基准的变更,并评估变更的价值和有效性;

      2. 通过分析各项变更的影响,为持续验证和改进项目创造机会;

      3. 建立一种机制,以便项目管理团队规范地向有关干系人沟通变更的批准和否决情况。

      配置管理项

      1. 从哪里来 (谁创建,什么时候,为什么)

      2. 目前在哪里

      3. 将到哪里去

      以下是我的理解

      在PMP中,有配置管理系统,但这个系统不是我们一向认为的某个特定的软件系统之类的。是一种可以有系统管理,如果没有系统管理,人工通过文件或者架构设置工作流程都可以进行管理的系统。所以在PMP中的所有系统,都可以这样理解。(IT行业的同学,通常会理解为一个软件系统)

      配置管理系统如何理解,就要看它存在的目的。它存在的目的就是为了管理变更。所以,配置管理系统里面最重要的就是变更管理系统(这个是PMP的重点)。而配置管理系统比变更管理系统多出一部分,多出来的这部分是什么,就是配置管理系统区别于变更管理系统的部分。顾名思义,变更管理系统,只是负责管理变更,那么没有变更前,是怎样的呢,这个就是配置惯例系统负责的工作。

      举个例子:

      一个房屋装修项目,我已经确定了图纸和材料。我确定了我的窗户都是推开的窗。所以,窗户的大小,材料,和推开方式,就是某个配置项的内容。(识别产品和组成部分功能和属性)

      如果我现在要把窗户改成百页方式的,就改变了这个配置项的功能和属性。就需要提交这个变更请求,提交了变更请求,通过后,施工人员就可以看到这个配置管理项,来源是我提出的申请,在17日提出的,为了防蚊子。目前已经通过了变更审核了。将替换原来的窗户项目。

      在PMP考试中,重中之重是变更控制过程,配置管理系统是一个要点,但不算重点。因为,根据PMBOK所重点提到的,在项目管理中,用到了包含变更控制过程的配置管理系统,所以重点是变更控制。而配置管理系统属于项目管理信息系统的一部分。

      再举一个例子:

      我要购买一台电脑,肯定会考虑这台电脑需要什么配置,这里的配置,就是配置项。如果我的硬盘,要1TB,这个就是硬盘的配置项的属性。我的脑袋就是一个配置管理系统,定义了这些属性。如果听到了其他人的意见,决定修改配置,就需要通过配置管理系统里面的变更控制过程。如果还需要我老婆提供资金援助的,那么,她就是CCB了。要获得她的批准。

    展开全文
  • 软件配置管理

    千次阅读 2018-12-01 16:28:00
    第一章 1,软件配置管理用于控制变化 ...3,软件配置管理是一种标识、组织和控制修改的技术,软件配置管理应用于整个软件工程过程 4,SCM活动的目标就是为了标识变更、控制变更、确保变更正确实现...

    第一章

    1,软件配置管理用于控制变化

    2,软件配置管理(Software Configuration Management, SCM)是指一套管理软件开发和维护过程中所产生的各种中间软件产品的方法和规则,它是控制软件系统演变的学科。

    3,软件配置管理是一种标识、组织和控制修改的技术,软件配置管理应用于整个软件工程过程

    4,SCM活动的目标就是为了标识变更、控制变更、确保变更正确实现并向其他有关人员报告变更

    5,从某种角度讲,SCM的目的是使错误降为最小并最有效地提高生产效率。

    6,软件配置管理定义:

    软件配置管理是贯穿于整个软件过程中的保护性活动,它被设计用来:

    (1) 标识变化;(2) 控制变化;(3) 保证变化被适当的发现;(4) 向其他可能有兴趣的人员报告变化

    7,配置管理是否有成效取决于三个要素:人、规范、工具。

    8,软件配置是一个软件产品在生存期各个阶段的不同形式(记录特定信息的不同媒体)和不同版本的程序、文档及相关数据的集合,或者说是配置项的集合

    9,软件配置是一个集合,该集合中的每一个元素称为该软件产品软件配置中的一个配置项(Software Configuration Item,SCI)。

    10,常见的软件配置项:需求规格说明书、设计规格说明书、源代码、测试计划、测试用例、用户手册等

    11,基线(Baseline)是指一个(或一组)配置项在项目生命周期的不同时间点上通过正式评审而进入正式受控的一种状态。基线是软件生命周期中各开发阶段的一个特定点,它的作用是把开发各阶段工作的划分更加明确化,使本来连续的工作在这些点上断开,以便于检查与肯定阶段成果

    12,基线是已经正式通过复审和批准的某规约和产品,它因此可作为进一步开发的基础,并且只能通过正式的变化控制过程来改变。基线通常标志开发过程一个阶段的结束(里程碑)。

    13,里程碑(Milestone)是检查点 (Check Point),检查点不一定是里程碑,因为检查点还可以是时间、计划和事件

    14,功能基线:所规定的对待开发软件系统的规格说明

    15,指派基线:又称为分配基线,指在软件需求分析阶段结束时,经过正式评审和批准的软件需求的规格说明,指派基线是最初批准的指派配置标识。

    16,产品基线:指在软件组装与系统测试阶段结束时,经过正式评审的批准的有关所开发的软件产品的全部配置项的规格说明,产品基线是最初批准的产品配置标识

     

    17,软件配置控制委员会(Software Configuration Control Board, SCCB)负责管理软件配置项变更的组织。

    具体责任如下:

    评估变更;批准变更请求;在生命周期内规范变更申请流程;对变更进行反馈;与项目管理层沟通

    18,软件配置管理是在贯穿整个软件生命周期中建立和维护项目产品的完整性。它的基本目标包括:

    • 目标 1: 软件配置管理的各项工作是有计划进行的。
    • 目标 2: 被选择的项目产品得到识别,控制并且可以被相关人员获取。
    • 目标 3: 已识别出的项目产品的更改得到控制。
    • 目标 4: 使相关组别和个人及时了解软件基准的状态和内容。

    第二章

    1,软件配置管理角色

    PM: 项目经理;CCB: 配置控制委员会;CMO: 配置管理员;SIO: 系统集成员;DEV: 开发人员

    2,项目经理(Project Manager,PM)

    根据软件配置控制委员会的建议批准配置管理的各项活动并控制它们的进程。

    职责:制定和修改项目的组织结构和配置管理策略;批准、发布配置管理计划;

    决定项目起始基线和开发里程碑;接受并审阅配置控制委员会的报告。

    配置控制委员会(Configuration Control Board,CCB)

    负责指导和控制配置管理的各项具体活动的进行,为项目经理的决策提供建议。

    职责:定制开发子系统;定制访问控制;制定常用策略;建立、更改基线的设置,审核变更申请;根据配置管理员的报告决定相应的对策。

    配置管理员(Configuration Management Officer,CMO)

    根据配置管理计划执行各项管理任务,定期向CCB提交报告并列席CCB的例会。

    职责:软件配置管理工具的日常管理与维护;提交配置管理计划;各配置项的管理与维护;执行版本控制和变更控制方案;完成配置审计并提交报告;对开发人员进行相关的培训;识别软件开发过程中存在的问题并拟定解决方案。

    系统集成员(System Integration Officer,SIO)

    系统集成员负责生成和管理项目的内部和外部发布版本。

    职责:集成修改;构建系统;完成对版本的日常维护;建立外部发布版本。

    开发人员(Developer,DEV)

    开发人员的职责就是根据组织内确定的软件配置管理计划和相关规定,按照软件配置管理工具的使用模型来完成开发任务。

    34,软件配置管理过程包括7项基本活动:

    (1) 制定配置管理计划;(2) 识别和标志配置项;(3) 搭建配置管理环境;(4) 配置项的版本控制;(5) 基线变更管理;(6) 配置审核;(7) 配置状态统计

    5,制定配置管理计划

     

    • 配置管理计划的主要内容:

    配置管理组织及其职责;配置管理工具和配置库的组织结构;配置项标志和基线定义;

    变更管理流程;配置审核和配置状态统计

     

    6,识别和标志配置项:

    (1)为每一个配置项分配唯一的标志;建立配置项间的对应关系

    (2)两类配置项:

    • 基本配置项:软件开发者在项目开发过程中所创建的基本工作单元。
    • 集成配置项:一个集成配置项是基本配置项或其它集成配置项的集合。

    7,搭建配置管理环境

    配置管理环境是用于进行软件配置管理的系统环境,其中最重要的是配置管理库,简称配置库

    配置库存储配置项 (SCI)、修改请求、变化记录等,并提供对库中所存储文件的版本控制

    一般需采用配置管理工具来建立配置库。

     

    8,配置项的版本控制

    • 配置库的检入检出和版本控制机制解决了软件开发中的两个重要问题
      • 访问控制:保证具有相应权限的人员才能修改配置项。
      • 并行控制:保证不同人员同时对某配置项进行的修改不会互相覆盖。
    • 对配置项的修改(不同版本间的差别)应被记录下来。

      更动者(姓名及其身份);更动日期和时间;被更动SCI(名及其版本号);

      更动内容及其位置;更动原因;受此更动影响的诸SCI名表。

    • 软件产品版本编号方法
      • 数字顺序型版本编号

      普通版本编号

      • x.y.z,x为主版本号,y为特征版本号,z为缺陷修复版本号,如V3.10.16。
      • 主版本号的增加表示提供给客户的主要产品功能的增强。
      • 特征版本号的增加表示产品新增了一些特征或做了一些重要修改。
      • 缺陷修复版本号的增加表示在软件产品上做了一些缺陷修复工作。

      α和β版本编号

      • 在普通版本编号后面增加一个大写字符A或者B来分别表示α版本或β版本。例如1.2.4A或1.2.4B。
      • 如果存在多次的α发布和β发布,可在A或B后面添加一个数字来说明发布的次数,例如:1.2.5A1,1.3.0B2。

      α测试是由公司内部的用户在模拟实际操作环境下进行的测试。

      β测试是由软件的多个用户在实际使用环境下进行的测试。

      • 属性版本编号

        把版本的重要属性反映在标识中。可以包括的属性有:客户名、开发语言、开发状态、硬件平台、生成日期等。例如: J2SDK.v.l.2.2:10/31/2000-18:00,native threads, jit-122

        • 包含的信息丰富,方便了查询和管理,版本间的关系易于保持,但由于太复杂,一般只用于软件组织内部的管理

       

    9,基线变更管理

     

     

    • 变更批准或拒绝

    根据评估结果对变更作出决策:

    直接实现变更;挂起或延迟变更;拒绝变更

    对于批准的变更,要确定其实现进度:

    立即实现变更;在特定的日期实现变更;在软件另外的版本中实现

    • 变更实现

    10,配置审核

    配置管理活动审核:确保所有配置管理活动符合已批准的软件配置管理规程

    基线审核:审核基线配置项的完整性和一致性,从而保证基线配置项可被正确地构造。

    11,配置状态统计和报告

    变更请求的数量。变更管理活动的执行情况。

    配置管理系统存储量的变化。配置管理系统和SCCB在运作中发生异常的次数

    第三章

    1,CMM/CMMI将软件配置管理的活动分为6个方面,每个方面又再进行了细分

    SCM过程管理;软件配置标识;软件配置控制;软件配置状态统计;软件配置审计;软件发布管理和交付

    2,在CMM和CMMI中,将配置管理的目的定义为"建立和维护产品的完整性",

    3,配置完整性(对标准的理解)

    • 产品完整性:项目提交的工作成果是"产品集合完整、子产品正确"的
    • 产品集合完整:产品包含的子产品(配置项)是完整的
    • 子产品正确:子产品(配置项)达到了需求要求,满足标准、规程的要求

    4,三库管理:三库的概念源自CMM/CMMI,即开发库、受控库和产品库。配置项在三库之间迁移,一级比一级的控制更严格。

    5,软件开发组日常的工作在开发库中开展,当工作达到里程碑时,再迁移到受控库,在受控库中经过更严格的测试后,再上升到产品库,最后发布。

    6,在实践中,三库常常被实现为物理上的三库,而不是通过逻辑的方式来实现,三库物理隔离带来的最大问题是配置项失去了历史可追溯性

    7,实现三库的指导思想应该是逻辑上独立,物理上在一起,通过权限与流程的控制来实现配置项在不同库之间的流转,以及相应角色的人员对相应库的访问。

    1. CMM2在配置管理方面主要针对于实现部分;CMM3将配置管理扩展到需求、规格说明、设计和工具
    2. SCM意义

    记录软件产品的演化过程;

    确保软件开发者在软件生命周期中的各个阶段都能得到精确的产品配置;

    最终保证软件产品的完整性、一致性、追朔性、可控性;。

    10,每个基线都将接受配置管理的严格控制,对其的修改将严格按照变更控制要求的过程进行,在一个软件开发阶段结束时,上一个基线加上增加和修改的基线内容形成下一个基线,这就是"基线管理"的过程

    11,建立基线的好处:重现性;可追踪性;版本隔离。

    基线管理的步骤:

    (1) 在开发前确定基线的"配置";(2) 基线批准前,根据"配置"检查配置项是否齐备;

    (3) 对各个配置项,确认其版本的正确性;(4) 对每个配置项建立基线标志;

    (5) 基线变更管理;(6) 基线的各类报告和审计信息。

    12,变更管理的流程:

    (获得)提出变更请求;由CCB审核并决定是否批准;

    为(被接受)修改请求分配人员,提取SCI,进行修改;

    提交修改后的SCI,并测试(或者评审);重建软件的适当版本;

    复审(审计)所有SCI的变化;发布新版本。

    ---可以通过两种表格来帮助发现受到变更影响的内容,一种是《需求跟踪表》,一种是《配置项依赖关系表》

     

    13,配置库管理

    (1)设置配置库(即文件夹设置)和设置版本的分支

    (2)为每个配置项从建立开始就划分成3个不同的分支:私有分支、集成分支、公共(主干)分支

    私有分支(开发人员的私有开发空间):开发人员

    集成分支(开发团队的公共空间):由系统集成员及相关指定人员负责:所有涉及多人协调的开发工作(如集成测试等)都必须工作在这一空间中。该开发团队拥有对该集成分支的读写权限,而其他成员只有只读权限。

    公共(主干)分支(整个软件开发组织的公共空间):系统集成员:各个开发小组在现阶段的任务完成后,将可以发布的版本归并到该分支上,对组织内的全体软件人员开放只读权限

     

    上面定义的3类工作空间(分支)由配置管理员统一管理

     

    (3)按配置项类型分类建库和按任务建库。

    (4)配置库的日常工作:对配置库的定期备份;清除无用的文件和版本;检测并改进配置库的性能等

     

    14,配置审计:主要作用是作为变更控制的补充手段,来确保某一变更需求已被切实实现

    记录了谁修改了这个工件,什么时候做的修改,为什么原因做出这个改动,以及修改了哪些地方。 (Who、When、Why、What)

    • 同时配置审计工作该应当说明如下信息:

    (1) 变更要求被完成,并且对附加的修改已经执行了 (2) 采用了正确的正式验证手段

    (3) 遵循了标准的要求 (4) 变更的4W信息被完整记录,并和相关配置项关联

    • 配置审计有两种:
    • PCA (Physics Configuration Audit)-----非配置管理人员

    主要是检查版本是否正确一致。(1) 配置项是否齐备;(2) 版本是否齐全,由非配置管理人员来进行。

    • FCA (Function Configuration Audit) -----CMO

    检查配置项是否完整,各种过程文档是否齐备、正确、与需求是否一致,归结为两点,即完全和齐备。

    15,配置审计

    • When:软件交付或release时;每个阶段结束时;对于维护性项目,周期性地进行
    • Who:非本项目组成员;其他项目中的配置控制者;内部审计者;SCM小组
    • 配置审计步骤(How-审计流程)
    • (1) 由项目经理决定何时进行配置审计工作(识别配置审计的时间[PM])
    • (2) 质量保证组或项目组的配置管理组制定该项目的配置审计人员(指派审计者[QA/Audit Group])
    • (3) 项目经理和配置审计员决定审计范围(定义审计范围[PM&Auditors])
    • (4) 配置审计员准备配置审计检查单(准备配置审计Checklist[Auditor])
    • (5) 配置审计员安排时间审计文档和记录,审计活动可能涉及到:项目范围,配置项的入库(check in)及出库(check out),评审记录,配置项的变更历史,测试记录,文件的命名,变更请求和版本的编号等

    (通过评审(Review)、文档记录进行审计[Auditor])

    • (6) 配置审计员在审计中发现不一致现象,并作记录(识别不符合项[Auditor])
    • (7) 由项目经理负责消除不一致现象(关闭不符合项[PM])
    • (8) 配置审计员验证所有发现的不一致现象确已得到解决(验证[Auditor])

     

    16,配置状态报告就是根据配置项操作的记录来向管理者报告软件开发活动的进展情况

    应该是定期进行,并尽量通过CASE工具自动生成,用数据库中的客观数据来真实的反映各配置项的情况。

    应着重反映当前基线配置项的状态,以作为对开发进度报告的参照

     

    17,软件配置管理最佳实践:

    统一标识配置项并存入安全的配置管理系统;控制和审计配置项的变更;合理组织配置项;

    在项目的里程碑建立相应的基线;记录和跟踪变更请求;过程驱动的软件配置管理;

    维护稳定而一致的工作空间;支持并行开发;尽早和持续集成;

    确保有能力重现软件的构建过程;把握好工具、流程和人员三者之间的关系;善用模式和反模式;

    18,模式可以指导我们如何成功应用前人的实践,避免犯前人犯过的错误,提高SCM的实施成功率。

    反模式是指那些在特定情况下不应该采取的策略和方式。

     

    第4章

    1,软件配置管理计划: 人员及职责;配置管理软硬件资源;配置项计划;基线计划;配置库备份计划

    2,配置库管理报告: 基本信息;项目成员的操作权限;配置项记录;基线记录;配置库备份记录;配置项交付记录;配置库重要操作日志

    3,配置项变更控制报告: 变更申请;审批变更申请;变更配置项;结束变更

    4,配置状态报告 (Configuration Status Report)目的:有效记录和报告管理配置所需要的信息,及时、准确地给出软件配置项的当前状态,供相关人员了解,以加强配置管理工作

    • 内容
      • 各份变更请示概要:变更请求号、日期、申请人、状态、估计工作量、实际工作量、发行版本、变更结束日期
      • 基线库状态:库标识、至某日预计库内配置项数、实际配置项数
      • 发行信息:发行版本、计划发行时间、实际发行日期、说明
      • 备份信息:备份日期、介质、备份存放位置
      • 配置管理工具状态
      • 配置管理培训状态

    5,配置审计目的:验证配置项信息与配置标识(需求、标准、流程…)的一致性,4"W"

    配置审计报告内容:配置项状态统计;基线库基线统计;变更统计;审计中发现的主要问题

    第5章

    1,配置管理模式分类: 描述工作区结构的模式 描述码线结构的模式

    2,码线(codeline)--源代码文件与组成某个软件组件的其他人工制品(配置项)随着时间而变更的进展过程。

    码线包含沿着一条路径发展的各个配置项的每个版本

    3,与码线有关的模式:主线活动开发线; 码线策略; 私用版本; 版本线; 版本预备线; 任务分支4,与工作区有关的模式: 私有工作区;储存库; 私有系统构造; 集成构造; 第三方码线;任务级提; 冒烟测试; 单元测试; 回归测试

    1. 主线——问题: 如何使当前活动码线的数目保持在容易管理的水平,避免项目的版本树长得太宽太密?如何使合并的开销减至最小?

      解决方案:简化分支模型:开发单个产品版本时,在主线上进行开发。分支时,先考虑总体战略,然后再创建分支

    6,分支是组织文件版本和显示版本历史的手段,是隔离变更的强有力机制。

    7,主线既要使码线的并发性达到最大,又要使推迟集成可能造成的问题减至最小

    8,私有工作区——问题: 如何跟上不断变化的码线并取得进展,而不会为环境变化而分心?

    • 解决方案:以隔离工作的方法控制变更 (Isolate your work to change control)
    1. 储存库——问题:如何获得填充新工作区的正确组件的正确版本11,
    2. 冒烟测试(Smoke Test)如何知道系统在你变更后仍能工作?

    描述的是在将代码更改嵌入到产品的源树中之前对这些更改进行验证的过程;

    是确定和修复软件缺陷的最经济有效的方法;缺点在于覆盖面很有限。执行者是开发人员或版本编译人员

    12,每次构造都必须进行冒烟测试,以显而易见的方式验证应用未被损坏。

    13,单元测试((Unit Test)):如何测试模块经你变更后是否仍能像预期一样工作

    14,回归测试((Regression Test)):如何确保现有的代码没有因你进行其他改进而变得更糟?

    15,每日构建 (Daily Build)

    就是把一个软件项目的所有的最新的代码从配置库中取出,然后从头进行编译、链接和运行。通常由工具自动完成(构建自动化)。

    daily build 的另一个重要功能就是验证软件中各模块关系是否正确,也可称为"每日集成"。

     

    第9章

    1,版本库(Repository):按照一定格式存储了所有数据,包括文件和目录

    经过授权的客户端可以连接到版本库,读写库中的文件

    版本库和普通文件服务器的不同:版本库会记录每一次的更改

    2,版本控制系统的核心任务:协作编辑和数据共享

    3,拷贝-合并模型假定文件是可以通过上下文合并的。通常情况下,文本文件(例如源代码以及用纯文本,HTML,TXT等格式保存的文档)因为其内部结构直观可知,容易理解上下文,所以用拷贝-合并方案较好。而二进制文件(例如用Microsoft Word格式说,PDF等格式保存的文档及图片,声音,可执行文件,库等)内部结构复杂,且不容易理解更改处的上下文,采用锁定-解锁方案较好

    4,Subversion主要采用拷贝-修改-合并模型,配合锁定-修改-解锁模型管理数据的共享

    5,工作拷贝(Working Copy)是本地机器的一个普通的目录,是私有工作区

    6,修订版本(Revision):每当一次提交完成后,版本库的文件系统就进入了一个新的状态,叫做一次修订(Revision)。在版本库中,最新的一个修订版本称为HEAD

    7,CheckOut:从版本库中取出某个目录的拷贝到本机上某个目录的操作

    例:svn co svn://192.168.0.1/svnrepos/skizcorp/trunk

    -r 1452 会检出1452版,如果存在的话;-N:不递归(仅针对顶层目录),否则目录递归(默认,常用)

    8,Update:把版本库的修改同步到本地

    • 例1:up    直接把工作拷贝更新到最新版(HEAD版)
    • 例2:up -r 2007    更新到2007版
    • 例3:up doc/design    只更新doc/design下的文件

    9,BASE版:某个文件的BASE版本是指存放在管理目录.svn中的该文件拷贝的版本,Revert会使该文件回到BASE版本

    10,Revert,是指放弃对某个文件的修改------revert abc.c 丢弃对abc.c的所有修改

    11,当文件发生冲突时,SVN会额外创建3个不受版本控制的文件

    12,add:把一个文件加入SVN版本控制系统;delete:从版本控制系统中移除;

    move(rename):移动或者重命名;mkdir:创建目录;copy:拷贝;commit:提交;

    status:检查工作拷贝的状态;diff:检查更改的内容

    13,分支(Branch)是开发的一条"支线"。它独立于其他开发的线路,并且和其他线路并行开发

    • 所有的分支都有共同的历史,有着原先共同的主线(Trunk)

    14,创建分支使用copy命令:copy 源目录 目标目录

    • 例:先把目录checkout到本地,在本地执行copy命令后提交至版本库

    svn co svn://localhost/
    svn copy trunk/ branches/mybranch
    svn commit –m "My branch created"

    • svn copy svn://localhost/trunk svn://localhost/branches/mybranch –m "My branch"

    15,Switch操作可以使工作拷贝在不同的分支之间或者在位于不同服务器上相同的版本库的分支间切换。它的作用是改变工作拷贝对应的URL:switch [--relocate] 目标URL

    16,分支的合并是指把修改从分支拷贝到主干或者把主干的修改拷贝到分支的过程。

    • 传统方法:diff + patch(只适用于文件内容)
      • 例子:取出主干2000版到2007版的修改,然后把它应用到工作拷贝

        svn diff –r 2000:2007 svn://localhost/trunk > patchfile
         patch –p0 < patchfile

    • merge 初始版本树 最终版本树 目标(能够处理目录树的修改,而不限于单个文件内容)

    例子

    • merge svn://localhost/trunk@2000 svn://localhost/trunk@2007 my_wc
    • merge –r 2000:2007 svn://localhost/trunk my_wc

    17,tag:通常tag对应于milestone,是一个完整可用的版本,不能修改,是只读的

    branch:是trunk或tag的分支,可以修改,是可写的,用于做并行开发

     

    18,常用的SVN命令:

    命令名称

    功能

    svn add 

    往版本库中添加新的文件

    svn checkout 

    将文件checkout到本地目录

    svn cleanup 

    递归清理工作拷贝

    svn commit 

    将改动的文件提交到版本库

    svn copy 

    拷贝文件

    svn delete 

    删除文件

    svn diff 

    比较差异

    svn export 

    导出目录树

    svn import 

    导入目录树

    svn info 

    打印作者、时间戳、日志信息大小和日志信息

    svn list 

    版本库下的文件和目录列表

    svn lock 

    文件加锁

    svn log 

    查看日志

    svn merge 

    将两个版本之间的差异合并到当前文件

    svn mkdir 

    创建纳入版本控制下的新目录

    svn move 

    移动一个文件或目录

    svn resolved 

    移除工作副本的目录或文件的"冲突"状态

    svn revert 

    恢复本地修改

    svn status 

    查看文件或者目录状态

    svn switch 

    代码库URL变更

    svn unlock 

    文件解锁

    svn update

    更新到某个版本

     

     

    第8章

    1,两种版本控制模型

    • Lock-Modify-Unlock Model (加锁-修改-解锁):CVS,SVN,VSS2005
    • Copy-Modify-Merge Model (拷贝-修改-合并):VSS6.0,PCVS

    2,基于"拷贝—修改—合并"的并发控制

    • 客户端check out后,有文件的一份独立拷贝。
    • 开发者在自己的工作目录中修改文件。
    • 若有版本冲突,则使用合并(merge)功能与其它开发者的修改合并,然后提交(check in)。

     

    第6章

    1,常用的配置管理工具:Visual SourceSafe(VSS); CVS; Subversion(SVN); Borland StarTeam; IBM Rational ClearCase & ClearQuest; Hansky Firefly

    ClearCase,Firefly支持异地开发,与开发工具的集成非常好,价格昂贵

    VSS仅支持windows,其他支持常见平台,与vs无缝集成,与其他开发工具集成性差

    2,软件配置管理工具的主要功能:

    版本控制;变更管理;配置审核(配置审计)

    配置状态统计(查询和报告);问题跟踪(跟踪缺陷和变更);访问控制和安全控制

    3,ClearCase主要应用于复杂产品的并行开发、发布和维护,其功能划分为四个范畴:版本控制(Version Control)、工作空间管理(Workspace Management)、构造管理(Build Management)、过程控制(Process Control)。

    4,ClearCase把所有版本控制的数据存放在一个永久、安全的存储区中,这个存储区被称为版本对象类(Version Object Bases)

    A VIEW selects versions of elements

    What is seen is the result of an ordered set of rules called a configuration specification (config spec).

    Selected versions appear in a standard directory tree with recognizable file names.

    View分为SnapShot View和Dynamic View,Snapshot view是ClearCase在服务器上存储的文件和目录的一个本地镜像,Dynamic View是动态试图,它并不在本地存储任何文件,始终和服务器保持一致。

    1. 软件配置管理工具选择:功能;是否符合团队特点?性能;费用是;售后服务;易用性

     

     

     

    序号

    活动名称

    角色

    活动描述

    参考

    1 

    • 计划配置管理

    配置管理经理

    CCB

    • 制定配置管理策略
    • 制定变更控制策略
    • 编写配置管理计划
    • 评审配置管理计划

     

    《配置管理计划》模板

     

    2 

    • 创建配置管理环境

    配置管理经理

    • 设置硬件环境
    • 设置网络环境
    • 设置软件环境

      建立一个配置管理库,储存项目中定义的配置项;安装配置管理工具,例如: VSS等。

    • 提供配置管理培训

     

    VSS使用手册》

    《组织管理配置库使用指南》

    3 

    • 配置项的标识

    配置管理经理

    • 对文档类的配置项进行的标识,参见附录B
    • 对程序(coding、模型)的配置项进行标识

    《软件开发文档命名约定》

    4 

    • 建立基线

    配置管理经理

    集成员

    • 标识基线:根据配置管理计划,对经过测试或者评审通过的工件进行标识。
    • 审批基线:CCB负责召开会议,评审配置管理经理建立的基线。
    • 发布基线:将建立的基线向相关人员发布。

    《配置管理计划模板》

     

    《基线策略指南》

    5 

    • 报告配置状态

    配置管理经理

    根据配置管理计划,收集配置活动数据, 编写配置状态报告。

     

    《配置状态报告》模板

    6 

    • 执行配置审计

    配置管理经理

    • 根据配置管理计划定期地执行配置审计,它包括:
      物理审计
      功能审计
    • 编写配置审计报告

     

    《配置审计报告》模板

    7 

    • 变更控制管理

    CCB

    任意角色

    • 参见《变更控制规范》

    《文档变更请求》

     

     

     

     
     
     
    展开全文
  • 在大型集群和分布式应用中,配置不宜分散到节点中,应该集中管理,为各种业务平台提供统一的配置管理服务。 随着业务的发展,应用系统中的配置通常会越来越多,常见的一些应用配置大致会有数据源配置,数据源组件...
    在大型集群和分布式应用中,配置不宜分散到节点中,应该集中管理,为各种业务平台提供统一的配置管理服务。
    随着业务的发展,应用系统中的配置通常会越来越多,常见的一些应用配置大致会有数据源配置,数据源组件配置,业务组件配置等,对于这类配置都会比较稳定且较少变化,通常会放在文件中随应用一起发布。但实际中会有某些配置信息变化有一定频率和规律,并且希望能够做到尽量实时,比如一些营销类,或活动类应用系统,若使用传统的配置文件,加上重新发布应用可能会有些不方便,因此,才有了分布式配置管理平台,旨在能更好地解决这类问题。

    统一配置管理 VS 分布式管理配置
    (中央管理VS去中心化) 

    这个技术话题让我们想起了svn和git之争,统一管理和分布式之间的那些事儿,各有千秋。

     编程开发+脚本 或者借助第三方开源自动化工具 

    spring cloud/dubbo/autoconfig  +docker+k8s+ansible/saltstack  目前业界通用的解决方案

    Disconf+ZooKeeper+Spring (360和淘宝也开源了自己的统一配置管理)
    XXL-CONF
    diablo 
    ansible-playbook
    Fourinone
    saltstack
    DCMP

     推荐用 分布式管理配置  现在开源社区很多  你可以去搜一哈 
    选适合自己的  别人推荐的 不一定是最好的 

     分布式配置管理 - 开源中国社区 https://www.oschina.net/search?scope=all&q=%E5%88%86%E5%B8%83%E5%BC%8F%E9%85%8D%E7%BD%AE%E7%AE%A1%E7%90%86 

    分布式配置管理平台的设计与实现


    随着业务的发展,应用系统中的配置通常会越来越多,常见的一些应用配置大致会有数据源配置,数据源组件配置,业务组件配置等,对于这类配置都会比较稳定且较少变化,通常会放在文件中随应用一起发布。但实际中会有某些配置信息变化有一定频率和规律,并且希望能够做到尽量实时,比如一些营销类,或活动类应用系统,若使用传统的配置文件,加上重新发布应用可能会有些不方便,因此,才有了分布式配置管理平台,旨在能更好地解决这类问题。本文将介绍相关细节,及一个轻量的开源实现(https://github.com/ihaolin/diablo)

    分布式配置平台的一些应用场景

    分布式配置,也即配置中心。通常有以下的场景或需求,可以需要考虑使用分布式配置:

    • 对某些配置的更新,不想要重启应用,并且能近似实时生效;

    • 希望将配置进行统一管理,而非放入各应用的配置文件中;

    • 对于某些应用系统,其某些配置变更比较频繁,规律;

    • 通常配置中心也可作为在其他分布式应用中的感知组件,比如典型的Zookeeper;

    • ...。

    分布式配置平台需要满足的一些基本特性

    对于一个可靠的分布式配置平台,大致应该满足一些基本特性,如:

    • 高可用性:服务器集群应该无单点故障,即只要集群中还有存活的节点,就能提供服务;

    • 容错性:容错性主要针对客户端,应保证即便在配置平台不可用时,也不影响客户端的正常运行;

    • 高性能:对于配置平台,主要操作则是获取配置,不能因为获取配置给应用带来不可接受的损失;

    • 可靠的存储:这包括数据的备份容灾,一致性等,通过数据库和一些运维手段可以解决;

    • 近似实时生效:对于配置的变更,客户端应用能够及时感知;

    • 负载均衡:为了尽量提升服务器集群的性能及稳定性,应尽量保证客户端的请求能尽量均衡负载到各服务器节点;

    • 扩展性:服务器集群应该保证做到无感扩容,以提升集群服务能力;

    • ...。

    分布式配置平台Diablo的设计与实现

    Diablo架构设计

    Diablo的架构设计比较简单轻量,如图:

    • Apps:及各类业务应用实例;

    • Servers:为客户端提供获取配置服务的Server集群;

    • Redis Storage Service:用作数据存储。

    Diablo模型设计

    • 应用(App):通常,对于一个用于各外部系统的平台,都可以抽象这些系统为应用,用于标识或是分组。对于应用环境,个人觉得应交由应用去处理,而不是在平台为各应用提供不同环境,比如可以通过应用名称就能区分不同环境。除此外,通常需要让应用提供一些安全方面的配置,如签名Key,加密Key等,可用于在与外部应用交互中作一些安全处理(如签名,加密等);

    • 配置项(Config):对于配置平台,其数据模型比较简单,核心数据就是配置项。配置项除了基本的配置名称和配置值外,通常还需要有用于判定配置项是否变更的字段,可以用MD5值等。

    对等的服务器集群

    Diablo集群中的Server被视为是对等的,即各节点没有主从(Master/Slave)关系,是逻辑相等的,这样就避免了Master/Slave架构带来的问题,如数据同步延迟,数据丢失等问题。

    高性能处理

    客户端应用获取配置时,仅会从本地缓存中获取,开发人员在控制台更改配置后,会通知客户端刷新缓冲;

    使用Redis作存储

    配置平台本身并没有太多复杂的关联关系,因此使用NoSQL也能满足常用的查询。在设计存储Key上,因尽量保证Key的简洁清晰,比如,存储应用记录,可以以apps:1来标识一条记录,而存储结构最好使用hash,而不是使用JSON字符串。在使用Redis时,diablo避免使用了一些特殊函数,如管道,事务等,因为这些函数在一些Redis的高可用解决方案(如Redis Cluster,Redis Proxy等)中通常不支持,这样用户可以自由使用不同的Redis高可用方案。

    客户端的实现

    • 重试等待:diablo会通过重试等待等机制保证,在服务端集群不可用时,也不会影响客户端应用的正常运行,而是等待集群恢复;

    • 请求负载:为了使服务器集群的各节点的负载尽量均衡,在客户端进行请求处理前,服务端会为客户端分配一个可用的Server节点,后续的请求将在该节点上,这里使用的负载算法是一致性哈希;

    • 额外参数:通常对于客户端实现,在与服务器交互过程中,除了必要的数据外,还会携带一些额外参数,如客户端版本号(为后期作兼容性处理),语言类型(后端可针对不同语言进行处理)等。

    配置更新实时生效

    配置更新实时生效是配置平台的核心功能之一,对于获取配置的方式,大致有两种模式:

    • Pull模式:即客户端主动向服务端拉取配置信息,通常是客户端定时轮询拉取。这种方式最简单稳定,但是存在时间间隔问题,间隔太长,配置延迟更新越大,间隔太短对服务器会造成过多的压力;

    • Push模式:即当配置发生变更时,服务端主动推送更新至各个客户端。这种方式能保证配置更新实时生效,但需要在客户端/服务端建立长链接,服务端需要处理各种异常情况和协议规范,保证更新能实时推送成功,实现起来相对麻烦些。

    diablo使用了特殊Pull模式,即(长轮询)Long Pulling。当客户端发起Http请求后,服务端接收处理完请求,并不会立即返回客户端,而是等待一定条件发生或超时后才返回客户端,这里的一定条件就是当有配置发生变更时,这样就有效减少了客户端请求,也达到了实时生效的目的。对于Java长连接的实现,主要使用了Servlet规范中的AsyncContext,使得服务端接收到请求后,并不会让Servlet容器立即返回客户端,而是当调用AsyncContext.complete()方法时,才会返回。

    客户端语言类型

    diablo默认实现了Java语言的客户端,希望以后能支持node,go,python等语言。由于diablo仅通过Http接口提供服务,不同语言只要遵循API接口,即可实现不同的语言版本。若读者有意实现,可参考该客户端规范,下图为客户端与服务端的交互过程:

    diablo实践建议

    服务器集群部署:对于一个高可用的服务器集群,建议可以nginx等代理服务器作转发,这样在服务器集群发生变化时,客户端应用也不用更新任何配置,如:

    应用环境区分:对于需要区分不同环境的应用,可以通过不同的应用名称作区分,如app_dev,app_test。但对于生产环境,都建议与其他环境隔离,独立部署。

    总结

    以上,则是有关分布式配置管理平台设计与实现的相关细节,也欢迎issue和fork项目diablo。



    [案例分析讲解]

       案例一、  为了更好的解决分布式环境下多台服务实例的配置统一管理问题,本文提出了一套完整的分布式配置管理解决方案。结合.net项目具体情况,实现了配置发布的统一化,对配置进行持久化管理并对外提供restful接口,在此基础上,基于ZooKeeper实现对配置更改的实时推送。系统参考了百度的Disconf,实现和改进了部分功能,是Disconf的.Net精简版,功能有待进一步完善。

    这里主要使用到disconf分布式配置管理平台 支持window和linux下面是大家window环境步骤和一些操作总结。

      所需环境:Windows、nginx1.8.1、redis3.0.5、zookeeper3.4.6、mysql5.7 、python2.7.11、Git-2.6.4-64-bit.exe

    之前一直采用properties文件管理配置信息,若是集群则每个机器上都要拷贝一份,每次修改也需要依次修改。一直在寻找统一修改,实时生效,方便修改,分环境分系统的配置管理,自己也在整理设计,若找不到合意的就准备自己写一个,可以根据自己需求慢慢改进。通过开源中国微博知道了360的配置管理,看了下没大搞明白,貌似管理不太方便,反正不是我想要的,后来知道了百度的disconf,淘宝也有一个配置管理。我先看了百度的disconf,这就是我想要的,所以没看淘宝那个配置管理。

      首先这是一个开源项目,托管在github上,地址: https://github.com/knightliao/disconf,官方的文档还是很丰富的,地址:https://github.com/knightliao/disconf/wiki 。建议先看官方文档,文档很实用,花不了多少时间,我这里仅就官方没说,但刚接触这个的人常见的部分问题说说自己的解决方案,下面是一张运行效果图。

      

      要看这个项目,需要的知识:java相关技术、前端、git、mysql、tomcat、redis、zookeper、nginx,后面几个简单度一下就能了解个大概。

    1. 安装git客户端、下载代码、导入eclipse、运行redis、zookeper、mysql就不说了。
    2. windows上运行sh脚本小知识。
      一看项目内容就知道,这应该只考虑了Linux环境开发,只提供了sh脚本,而很多人都是windows开发环境。其实安装git客户端后,windows下是可以运行sh脚本的。如下图就是git下的sh软件和运行效果,需要先按官方教程配置环境变量,我换系统了所以没配置,之前配置过。

    3. 能不安装nginx吗?
      这是我刚开始在官方讨论群提的问题,得到的答案是不能,提到了什么动静分离,于是百度了解了下,对nginx在这里扮演的角色有了一个了解,知道他做了什么,才能知道他是否必须。了解了之后,就会知道,这里应该有多中方式实现不安装nginx,我实现了一种如下图所示,其他方式可以百度springMVC关于静态文件的处理方式,第一张截图就是我在eclipse中用tomcat运行的结果。这个能方便开发,正式环境建议还是按官方设计的方式使用,nginx对静态文件的处理要比tomcat快不少。
    4. 看交流群讨论,记录如下几点,可以研究下,看怎么修改能解决问题,然后推送官方,也贡献自己的一份力。
      1) 貌似使用spring4时有问题。
      2) 有人建议添加配置优先级,先读取环境变量,再各种配置文件,都没有时提供默认配置。

      由于官方文档比较详细,这里基本没有提到disconf本身的用途,使用方式。建议到处问人前先仔细看看官方教程。

    案例二、

    1.系统设计

    1.1设计理念

          l  简单易用,用户体验良好

          l  支持配置(KV配置项+配置文件)的分布式化管理

          l  配置发布、更新统一化:用户统一在平台上进行发布、更新配置。

          l  配置更新自动化:用户在平台更新配置,使用该配置的系统会自动发现该情况,并应用新配置。

     

          系统结构图如下: 

     

     

          初始化时,业务流程图如下:

     

          配置更新时,业务流程图如下:

     

    1.2.功能介绍

          系统模块架构图如下:

     

    1.2.1Client

      配置管理模块:统一管理用户实例中本地配置文件和配置项

      下载模块:restful风格的下载配置文件和配置项

      watch模块:监控远程配置文件和配置项的变化

    1.2.2Web

    配置管理模块:支持配置模板(配置项或配置文件)的上传、下载、更新

    配置存储模块:管理所有配置的存储和读取,根据appName、version、environment来区分项目配置

    通知模块:当配置更新后,实时通知使用这些配置的所有实例

    权限控制:web用户的权限控制

    2.客户端应用

    2.1添加clientConfig配置节点

    在app.config或者web.config中的configSections节点下添加配置

    <section name=”clientConfig” type=”Disconf.Net.Client.ClientConfigSection,Disconf.Net.Client”/>

    然后在appSettings同级别的节点上添加clientConfig配置,示例如下

    复制代码
    <configSections>
    
     <section name=”clientConfig” type=”Disconf.Net.Client.ClientConfigSection,Disconf.Net.Client”/>
    
    </configSections>
    
    <appSettings file=”appSettings.config”/>
    
    <clientConfig configSource=”clientConfig.config”/>
    复制代码

     

    2.2clientConfig配置说明

    具体示例如下:

    复制代码
    <clientConfig webApiHost=”http://192.168.1.100:8088/” enableRemote=”true”>
    
    <clientInfo appName=”consoletest” environment=”Dev” version=”1.0.0.0” clientName=”Console_1”/>
    
    <updateStrategy fileIgnores="notdown.txt" itemIgnores="aa,bb,cc " startedSync="true" retryTimes="3" retryIntervalSeconds="10" />
    
    <preservation absolutePath="false" tmpRootDirectory="Tmp\Download\Configs" factRootDirectory="" tmpItemsLocalName="~items.xml" tmpFilesLocalName="~files.txt"/>
    
    </clientConfig>
    复制代码

     

     

    节点名称

    必配

    默认值

    节点描述

    webApiHost

     

    Y

     

    Rest服务器域名地址

    enableRemote

     

    N

    true

    是否启用远程配置,默认true,设为false的话表示不从远程服务器下载配置

    clientInfo

    appName

    Y

     

    客户端程序名称,注意大小写要与服务端一致

    environment

    Y

     

    当前客户端程序所处环境,注意大小写要与服务端一致

    version

    Y

     

    当前客户端程序版本,注意大小写要与服务端一致

    clientName

    N

     

    客户端标识,用于服务端查看已更新客户端,如果不设置则默认获取客户端电脑名称

    updateStrategy

    fileIgnores

    N

     

    要忽略更新的文件配置,以,分割,注意大小写要与服务端一致

    itemIgnores

    N

     

    要忽略更新的键值对配置,以,分割,注意大小写要与服务端一致

    startedSync

    N

    true

    启动时是否同步加载,默认同步

    retryTimes

    N

    3

    当获取失败时的重试次数

    retryIntervalSeconds

    N

    10

    每次重试时间间隔,单位秒

    preservation

    absolutePath

    N

    false

    是否绝对路径,默认false。当false时,表示默认以

    AppDomain.CurrentDomain.BaseDirectory为比较点,注意:该配置同时适用于TmpRootDirectory、

    FactRootDirectory,即要么都只能绝对路径,要么都只能相对路径

    tmpRootDirectory

    N

    Tmp/Download/Configs

    下载下来的配置临时保存文件夹根目录

    factRootDirectory

    N

    Configs

    配置文件实际所在的根目录

    tmpItemsLocalName

    N

    ~items.xml

    在临时目录下用于保存所有键值对的文件名,设置为空表示不保存,文件保存在TmpRootDirectory目录下,所以注意不要与

    实际配置文件名字冲突

     

    tmpFilesLocalName

    N

    ~files.txt

    在临时目录下用于保存所有文件配置名的文件名,设置为空表示不保存,文件保存在TmpRootDirectory目录下,所以注意不要与实际配置文件名字冲突

     

    2.3Rules

    除了配置外,还需要设置更新策略,客户端才能进行配置更新。目前,Rules设置仅支持编码的方式进行,Rule分两种:FileRule,ItemRule,下面分别进行描述:

    FileRule:用于设置如何更新文件类型配置,其包含以下方法

    方法名

    描述

    IFileRule MapTo(string refreshSectionName)

    注册Rule规则,设置默认的文件配置映射

    参数refreshSectionName表示更新回调时,

    ConfigurationManager.RefreshSection要刷新的节点名称,默认采用远程配置的configName

    IFileRule RefreshIgnores()

    不自动调用ConfigurationManager.RefreshSection方法更新配置

    IFileRule CallBack(Action action)

    当文件下载完成并且替换本地对应文件后回调,注意此处将采用委托链的方式,即多次调用均会被执行

    ItemRule:用于设置如何更新键值对类型配置,其包含以下方法

    方法名

    描述

    IItemRule MapTo(string propName)

    注册Rule规则,设置默认的属性映射参数

    propName表示要赋值的属性名,默认采用远程的configName

    IItemRule SetProperty<T>(T entity, string propName = null, Func<string, object> typeConvert = null)

    更新指定实体的属性值,按默认方式获取实例属性,注意此处多次调用均会被执行

    IItemRule SetProperty(object entity, PropertyInfo prop, Func<string, object> typeConvert = null)

    更新指定实体的属性值,注意此处多次调用均会被执行

    IItemRule SetStaticProperty<T>(string propName = null, Func<string, object> typeConvert = null)

    更新静态属性的值,按默认方式获取静态属性,注意此处多次调用均会被执行

    IItemRule SetStaticProperty(PropertyInfo prop, Func<string, object> typeConvert = null)

    更新静态属性的值,注意此处多次调用均会被执行

    IItemRule CallBack(Action<string> action)

    当值发生变更时如何进行回调,注意此处将采用委托链的方式,即多次调用均会被执行

    2.4ConfigManager

    该类为Client配置入口,通过Singleton提供唯一实例,除了提供Rules的配置入口外,还提供异常通知的事件

    要使Disconf.Net.Client工作,必须显示执行指定方法manager.Init(),而在init之前,还需设置Rule和Fault,可以通过ConfigManager.Instance来获取该类的实例对象,然后通过对应的Rule进行相关Rule设定,示例如下:

    复制代码
    //要更新的文件
    
    ConfigManager.Instance.FileRules.For("appSettings.config").CallBack(() => {
    
          Console.WriteLine("File changed notice twice");
    
    });
    
    
    //要更新的键值对
    
    ConfigManager.Instance.ItemRules.For("Dai").MapTo("Person").SetStaticProperty<Program>().CallBack(v =>{
    
    Console.WriteLine("Now item value:{0}", v);
    
    Console.WriteLine("Program.Person is {0} now", Program.Person);
    
        if (v.Length > 3)
    
        {
    
            throw new Exception("Too Long");
    
        }
    
    });
    
    
    //忽略更新到本地的键值对
    
    ConfigManager.Instance.ItemRules.For("Peng").CallBack(v =>{
    
    Console.WriteLine("Now item value:{0}", v);
    
    });
    
    
    //异常处理
    
    ConfigManager.Instance.Faulted+=Manager_Faulted;
    
    //Config初始化,包括ZooKeeper、scan等
    
    ConfigManager.Instance.Init();
    复制代码

     

    需要特别说明的是:

    1、File因为属于下载后覆盖指定位置文件的方式,所以对于Rule可以设置默认规则,如例子中的appSettings.config,其对应的就是config文件中的appSettings部分,此时如果不需要进行CallBack调用,且文件名称(去除后缀)部分与Section一致,那么这部分Rule设置可以忽略,程序会在初始化时自动进行默认设置,而对于Item,因为无法确认更新策略,所以如果不设置Rule,那么就算从服务端获取到了值,该部分也只能被忽略。

    2、对于异常部分,程序只是简单的通过Faulted事件来传递异常信息,该事件只有一个Exception类型的参数。

    3.web端应用

    配置步骤:

    1、  创建具体应用(项目)

    2、  创建应用的配置模板(1~n个配置,如appSetting.config、redisconfig.config、rabbitMQConfig.config等配置模板)

    3、  创建应用的环境(如:开发环境、测试环境、仿真环境等),修改相关的配置

    4、  启用对应的配置

    5、  至此,client端就可以获取应用环境对应的所有配置

    3.1登录

    登陆进入配置管理界面

    3.2应用

     

     

    【新建】:填写应用名称,应用描述保存完成新建,返回可返回应用管理首页。

    【初始化ZooKeeper】:第一次启动时Zookeeper初始化。

    【编辑】:与新建界面一致,可修改应用名称,应用描述,保存即返回应用管理首页。

    【编辑环境】:进入环境环境配置管理首页。

    【删除】:删除对应应用记录。

    3.3模板

    显示所有模板,操作环境配置前,需要先配置模板,根据模板对相应环境的配置进行操作。

     

    【新建】:新增模板,填写模板名称、描述、类型、默认值版本号等,如选择文件类型。可上传文件读取文件内容,版本号可以选择已经有的版本号,或者新建版本号。

    【编辑】:操作同新建模板,可对模板内容进行修改。

    【删除】:点击删除可删除对应模板记录,如该模板在环境中存在配置项,则该模板不允许删除,需删除对应该模板的配置项,才可以删除对应模板。

    3.4环境

    【新增环境】点击加号可以新增环境,填写环境名称,描述保存即可。

     

    【编辑环境】在对应环境上点击鼠标右键即可弹出编辑菜单,点击Edit即可编辑环境,可以修改名称内容等。

     

    【配置首页】:配置首页根据版本进行分类,默认显示头部第一个版本,点击其他版本可以进行切换,显示的配置项是模板默认配置项,点击启用即可个性化赋值,针对不同环境进行不同的赋值。编辑可编辑相应配置,禁用等同于删除配置。

     

    【启用配置】:名称默认值不能修改,可以点击使用默认值,直接赋值,也可以上传文件使用文件内容,保存即可。

    【编辑配置】:操作同启用配置,保存即可修改值。

    【禁用配置】:禁用等同于删除配置,删除对应模板配置项,可删除对应模板。

    3.5角色

    【角色首页】:

    Ø  角色首页展示角色列表,角色分为超级管理员和非超级管理员;

    Ø  超级管理员角色不展示;

    Ø  超级管理员可以看到所有非超级管理员角色,非超级管理员只可以看到当前角色用户创建的角色;

    Ø  可以新增角色,也可以对角色进行编辑,只有在创建用户时勾选是否为系统管理员才可以进行角色管理。

    【新建角色】:

    Ø  新建角色输入角色名称,可以勾选的权限为当前用户所拥有的权限;

    Ø  新建的角色作为该用户的下属角色,可分配给当前用户新建的用户;

    Ø  父级权限为新建应用所增加的权限,以后每增加一个环境,就相应的增加该应用下的该环境权限,除超级管理员外的角色需对应勾选该权限才能看到该应用或者该权限,保存角色即可。

    【编辑角色】:操作同新建角色,可以对该角色进行名称修改,权限修改。

    3.6用户

    管理用户首页,显示所有用户,可进行新建,编辑用户等操作。

     

    【新建用户】:填写姓名,用户名,密码,选择角色(拥有对应角色权限、且可以选择的角色为当前登陆用户新建的角色),选择是否为系统管理员(系统管理员拥有新建用户、新建角色权限),保存即可。

    【编辑用户】:操作同新建用户,保存即可修改。


    案例三、

    《分布式配置管理平台XXL-CONF》

    一、简介

    1.1 概述

    XXL-CONF 是一个分布式配置管理平台,其核心设计目标是“为分布式业务提供统一的配置管理服务”。现已开放源代码,开箱即用。

    1.2 特性

    • 1、简单易用: 上手非常简单, 只需要引入maven依赖和一行配置即可;
    • 2、在线管理: 提供配置管理中心, 支持在线管理配置信息;
    • 3、实时推送: 配置信息更新后, Zookeeper实时推送配置信息, 项目中配置数据会实时更新并生效, 不需要重启线上机器;
    • 4、高性能: 系统会对Zookeeper推送的配置信息, 在Encache中做本地缓存, 在接受推送更新或者缓存失效时会及时更新缓存数据, 因此业务中对配置数据的查询并不存在性能问题;
    • 5、配置备份: 配置数据首先会保存在Zookeeper中, 同时, 在MySQL中会对配置信息做备份, 保证配置数据的安全性;
    • 6、HA: 配置中心基于Zookeeper集群, 只要集群节点保证存活数量大于N/2+1, 就可保证服务稳定, 避免单点风险;
    • 7、分布式: 可方便的接入线上分布式部署的各个业务线, 统一管理配置信息;
    • 8、配置共享: 平台中的配置信息针对各个业务线是平等的, 各个业务线可以共享配置中心的配置信息, 当然也可以配置业务内专属配置信息;
    • 9、配置分组: 支持对配置进行分组管理, 每条配置将会生成全局唯一标示GroupKey,在client端使用时,需要通过该值匹配对应的配置信息;

    1.3 背景

    why not properties

    常规项目开发过程中, 通常会将配置信息位于在项目resource目录下的properties文件文件中, 配置信息通常包括有: jdbc地址配置、redis地址配置、活动开关、阈值配置、黑白名单……等等。使用properties维护配置信息将会导致以下几个问题:

    • 1、需要手动修改properties文件;
    • 2、需要重新编译打包;
    • 3、需要重启线上服务器 (项目集群时,更加令人崩溃) ;
    • 4、配置生效不及时: 因为流程复杂, 新的配置生效需要经历比较长的时间才可以生效;
    • 5、不同环境上线包不一致: 例如JDBC连接, 不同环境需要差异化配置;

    why XXL-CONF

    • 1、不需要 (手动修改properties文件) : 在配置管理中心提供的Web界面中, 定位到指定配置项, 输入新的配置的值, 点击更新按钮即可;
    • 2、不需要 (重新编译打包) : 配置更新后, 实时推送新配置信息至项目中, 不需要编译打包;
    • 3、不需要 (重启线上服务器) : 配置更新后, 实时推送新配置信息至项目中, 实时生效, 不需要重启线上机器; (在项目集群部署时, 将会节省大量的时间, 避免了集群机器一个一个的重启, 费时费力)
    • 4、配置生效 "非常及时" : 点击更新按钮, 新的配置信息将会即可推送到项目中, 瞬间生效, 非常及时。比如一些开关类型的配置, 配置变更后, 将会立刻推送至项目中并生效, 相对常规配置修改繁琐的流程, 及时性可谓天壤之别;
    • 5、不同环境 "同一个上线包" : 因为差异化的配置托管在配置中心, 因此一个上线包可以复用在生产、测试等各个运行环境, 提供能效;

    1.4 下载

    源码地址 (将会在两个git仓库同步发布最新代码)
    中央仓库地址 (最新Release版本)
    <dependency>
      <groupId>com.xuxueli</groupId>
      <artifactId>xxl-conf-core</artifactId>
      <version>1.3.0</version>
    </dependency>
    
    博客地址 (将会在两个博客同步更新文档)
    技术交流群 (仅作技术交流)
    • 群4:464762661 image
    • 群3:242151780 (群即将满,请加群4)
    • 群2:438249535 (群即将满,请加群4)
    • 群1:367260654 (群即将满,请加群4)

    1.5 环境

    • Maven3+
    • Jdk1.7+
    • Tomcat7+
    • Zookeeper3.4+
    • Mysql5.5+

    二、快速入门

    2.1 初始化“数据库”

    请下载项目源码并解压,获取 "调度数据库初始化SQL脚本" 并执行即可。脚本位置如下:

    xxl-conf/db/xxl-conf.sql
    

    2.2 编译源码

    解压源码,按照maven格式将源码导入IDE, 使用maven进行编译即可,源码结构如下图所示:

    输入图片说明

    • xxl-conf-admin:配置管理中心
    • xxl-conf-core:公共依赖
    • xxl-conf-example: 接入XXl-CONF的Demo项目

    2.3 “配置管理中心” 项目配置

    项目:xxl-conf-admin
    作用:管理线上配置信息
    

    配置文件位置:

    xxl-conf/xxl-conf-admin/src/main/resources/xxl-config-admin.properties
    

    配置项目说明:

    # xxl-conf, zk address  (配置中心zookeeper集群地址,如有多个地址用逗号分隔)
    xxl.conf.zkserver=127.0.0.1:2181
    
    # xxl-conf, jdbc    (配置中心mysql地址)
    xxl.conf.jdbc.driverClass=com.mysql.jdbc.Driver
    xxl.conf.jdbc.url=jdbc:mysql://localhost:3306/xxl-conf?Unicode=true&amp;characterEncoding=UTF-8
    xxl.conf.jdbc.username=root
    xxl.conf.jdbc.password=root_pwd
    
    # xxl-conf, admin login (管理中心登录账号密码)
    xxl.conf.login.username=admin
    xxl.conf.login.password=123456
    

    2.4 “接入XXL-CONF的Demo项目” 项目配置

    项目:xxl-conf-example
    作用:供用户参考学习如何接入XXL-CONF
    
    A、引入maven依赖
    <!-- xxl-conf-client -->
    <dependency>
        <groupId>com.xuxueli</groupId>
        <artifactId>xxl-conf-core</artifactId>
        <version>${xxl.conf.version}</version>
    </dependency>
    
    B、配置 “XXL-CONF配置解析器”

    可参考配置文件:

    /xxl-conf/xxl-conf-example/src/main/resources/spring/applicationcontext-xxl-conf.xml
    

    配置项说明

    <!-- XXL-CONF配置解析器 -->
    <bean id="xxlConfPropertyPlaceholderConfigurer" class="com.xxl.conf.core.spring.XxlConfPropertyPlaceholderConfigurer" />
    
    C、设置 "xxl-conf.properties"

    可参考配置文件:

    /xxl-conf/xxl-conf-example/src/main/resources/xxl-conf.properties
    

    配置项说明

    # xxl-conf, zk address  (配置中心zookeeper集群地址,如有多个地址用逗号分隔)
    xxl.conf.zkserver=127.0.0.1:2181
    

    该配置文件,除了支持配置ZK地址,还可以配置一些本地配置。 XXL-CONF 加载配置时会优先加载 "xxl-conf.properties" 中的配置, 然后才会加载ZK中的配置。可以将一些希望存放本地的配置存放在该文件。

    2.5 新增配置分组

    输入图片说明

    每个配置分组对应一个唯一的GroupName,作为该分组下配置的统一前缀。在“分组管理”栏目可以创建并管理配置分组信息,系统已经提供一个默认分组.

    2.6 新增配置信息

    登录"配置管理中心"

    输入图片说明

    进入"配置管理界面",点击"新增配置"按钮

    输入图片说明

    在弹出界面,填写配置信息

    输入图片说明

    至此, 一条配置信息已经添加完成.

    通过client端,可以实时获取配置信息, 通过本地已经加载过得配置将会接受Zookeeper的更新推送, 如下如日志:

    输入图片说明

    2.7 项目中使用XXL-CONF

    项目: xxl-conf-example:   (可以参考 com.xxl.conf.example.controller.IndexController.index() )
    作用: 接入XXl-CONF的Demo项目
    
    • 方式1: XML文件中的占位符方式

      <bean id="configuration" class="com.xxl.conf.example.core.constant.Configuration">
          <property name="paramByXml" value="${default.key01}" />
      </bean>
      

      特点:

      • 上面配置说明: 在项目启动时, Configuration的paramByXml属性, 会根据配置的占位符${default.key01}, 去XXL-CONF中匹配KEY=key01的配置信息, 赋值给paramByXml;
      • 目前, 该方式配置信息, 只会在项目启动时从XXL-CONF中加载一次, 项目启动后该值不会变更。 例如配置数据连接信息, 如果XXL-CONF平台中连接地址配置改边, 需要重启后才生效;
      • 该方式, 底层本质上是通过 "方式2: API方式" 实现的。
    • 方式2: API方式

      String paramByClient = XxlConfClient.get("default.key02", null);
      

      特点:

      • 上面代码说明: 会获取XXL-CONF平台中KEY=default.key02的配置信息, 如果不存在值使用传递的默认值;
      • 因为Zookeeper会实时推送配置更新到客户端, 因此该方法放回的值可以XXL-CONF平台中的值保持实时一致;
      • XXL-CONF会对Zookeeper推送的配置信息做本地缓存, 该方法查询的是缓存的配置信息, 因此该方法并不会产生性能问题, 使用时不需要考虑性能问题;

    三、总体设计

    3.1 架构图

    输入图片说明

    3.2 "配置项" 设计

    系统配置信息以K/V的形式存在, "配置项" 属性如下:

    • 分组: "配置项" 的分组, 便于配置分组管理;
    • KEY : "配置项" 的全局唯一标识, 对应一条配置信息;
    • VALUE : "配置项" 中保存的数据信息, 仅仅支持String字符串格式;
    • 描述 : 配置项的描述信息;

    每条配置,将会生成全局唯一标示GroupKey,在client端使用时,需要通过该值匹配对应的配置信息;

    3.3 "配置中心" 设计

    输入图片说明

    • 1、ZK设计: 系统在ZK集群中占用一个根目录 "/xxl-conf", 每新增一条配置项, 将会在该目录下新增一个子节点。结构如下图, 当配置变更时将会触发ZK节点的变更, 将会触发对应类型的ZK广播。
    • 2、数据库备份配置信息: 配置信息在ZK中的新增、变更等操作, 将会同步备份到Mysql中, 进一步保证数据的安全性;
    • 3、配置推送: 配置推送功能在ZK的Watch机制实现。Client在加载一条配置信息时将会Watch该配置对应的ZK节点, 因此, 当对该配置项进行配置更新等操作时, 将会触发ZK的NodeDataChanged广播, Client竟会立刻得到通知并刷新本地缓存中的配置信息;

    ZK之watcher普及(来源官方文档,以及网络博客)

    1、可以注册watcher的方法:getData、exists、getChildren。
    2、可以触发watcher的方法:create、delete、setData。连接断开的情况下触发的watcher会丢失。
    3、一个Watcher实例是一个回调函数,被回调一次后就被移除了。如果还需要关注数据的变化,需要再次注册watcher。
    4、New ZooKeeper时注册的watcher叫default watcher,它不是一次性的,只对client的连接状态变化作出反应。(推荐ZK初始化时, 主动Watcher如exists)
    5、实现永久监听: 由于zookeeper是一次性监听,所以我们必须在wather的process方法里面再设置监听。
    6、getChildren("/path")监视/path的子节点,如果(/path)自己删了,也会触发NodeDeleted事件。
    
    《操作--事件》 event For “/path” event For “/path/child”
    create(“/path”) EventType.NodeCreated
    delete(“/path”) EventType.NodeDeleted
    setData(“/path”) EventType.NodeDataChanged
    create(“/path/child”) EventType.NodeChildrenChanged(getChild) EventType.NodeCreated
    delete(“/path/child”) EventType.NodeChildrenChanged(getChild) EventType.NodeDeleted
    setData(“/path/child”) EventType.NodeDataChanged

    《事件--Watch方式》 | Default Watcher | exists(“/path”) | getData(“/path”) | getChildren(“/path”) --- | --- | --- | --- EventType.None | 触发 | 触发 | 触发 | 触发 EventType.NodeCreated | | 触发 | 触发 |
    EventType.NodeDeleted | | 触发 | 触发 | EventType.NodeDataChanged | | 触发 | 触发 | EventType.NodeChildrenChanged | | | | 触发

    ZooKeeper的一个性能测试

    测试数据来自阿里中间件团队

    ZK集群情况: 3台ZooKeeper服务器。8核64位jdk1.6;log和snapshot放在不同磁盘;

    • 场景一: pub创建NODE,随后删除

      • 操作: 同一个目录下,先create EPHEMERAL node,再delete;create和delete各计一次更新。没有订阅。一个进程开多个连接,每个连接绑定一个线程,在多个path下做上述操作;不同的连接操作的path不同
      • 结果数据: "dataSize(字节)-TPS-响应时间(ms)" 统计结果为: 255-14723-82, 1024-7677-280, 4096-2037-1585;
    • 场景二: pub创建NODE, sub订阅并获取数据

      • 操作: 一个进程开多个连接,每连接一个线程,每个连接在多个path下做下述操作;不同的连接操作的path不同。每个path有3个订阅者连接,一个修改者连接。先全部订阅好。然后每个修改者在自己的每个path下创建一个EPHEMERAL node,不删除;创建前记录时间,订阅者收到event后记录时间(eventStat);重新get到数据后再记录时间(dataStat)。共1000个pub连接,3000个sub连接,20W条数据。收到通知后再去读取数据,五台4核client机器。
      • 结果汇总: getAfterNotify=false(只收事件,受到通知后不去读取数据);五台4核client机器
      • 结果数据: "dataSize(字节)-TPS-响应时间(ms)" 统计结果为: 255-1W+-256ms, 1024-1W+-256, 2048-1W+-270, 4096-8000+-520;
    • 场景三: pub创建NODE,随后设置数据

      • 一个进程开多个连接,每连接一个线程,每个连接在多个path下做下述操作;不同的连接操作的path不同。每个path有一个修改者连接,没有订阅者。每个修改者在自己的每个path下设置数据。
      • 结果汇总: getAfterNotify=false(只收事件,受到通知后不去读取数据);五台4核client机器
      • 结果数据: "dataSize(字节)-TPS-响应时间(ms)" 统计结果为: 255-14723-82, 1024-7677-280, 4096-2037-1585 ;

    总结: 由于一致性协议带来的额外网络交互,消息开销,以及本地log的IO开销,再加上ZK本身每1000条批量处理1次的优化策略,写入的平均响应时间总会在50-60ms之上。但是整体的TPS还是可观的。单个写入数据的体积越大,响应时间越长,TPS越低,这也是普遍规律了。压测过程中log文件对磁盘的消耗很大。实际运行中应该使用自动脚本定时删除历史log和snapshot文件。

    3.4 "配置管理中心" 设计

    "配置管理中心" 是 "配置中心" 的上层封装, 提供Web界面供用户对配置信息进行配置查询、配置新增、配置更新和配置删除等操作;

    3.5 "客户端" 设计

    输入图片说明

    API方式加载配置: 客户端主要分为三层:

    • ZK-Client : 第一层为ZK远程客户端的封装, 当业务方项目初始化某一个用到的配置项时, 将会触发ZK-Client对该配置对应节点的Watch, 因此当该节点变动时将会监听到ZK的类似NodeDataChanged的广播, 可以实时获取最新配置信息;
    • Ehcache : 第二层为客户端本地缓存, 可以大大提高系统的并发能力, 当配置初始化或者接受到ZK-Client的配置变更时, 将会把配置信息缓存只Encache中, 业务中针对配置的查询都是读缓存方式实现, 降低对ZK集群的压力;
    • Client-API : 第三层为暴露给业务方使用API, 简单易用, 一行代码获取配置信息, 同时可保证API获取到的配置信息是实时最新的配置信息;

    (API方式加载配置, 因为底层做了配置本地缓存, 因此可以放心应用在业务代码中, 不必担心并发压力。完整的支持配置实时推送更新)

    输入图片说明

    Bean方式加载配置:

    系统会在Spring容器中追加一个"PropertyPlaceholderConfigurer"属性解析器, 内部通过自定义的"StringValueResolver"解析器解析配置占位符 "${...}", 匹配到的配置信息将调用"XXL-CFONF"的API客户端加载最新配置信息进行Bean对象的属性赋值,最终完成实例化过程。

    (Bean方式加载配置,仅仅在实例化时加载一次; 考虑都实例化后的对象通常为持久化对象, 如数据库连接池对象, 不建议配置的太灵活, 因此Bean类型配置更新需要重启机器)

    四、历史版本

    4.1 版本1.1.0新特性

    • 1、简单易用: 上手非常简单, 只需要引入maven依赖和一行配置即可;
    • 2、在线管理: 提供配置管理中心, 支持在线管理配置信息;
    • 3、实时推送: 配置信息更新后, Zookeeper实时推送配置信息, 项目中配置数据会实时更新并生效, 不需要重启线上机器;
    • 4、高性能: 系统会对Zookeeper推送的配置信息, 在Encache中做本地缓存, 在接受推送更新或者缓存失效时会及时更新缓存数据, 因此业务中对配置数据的查询并不存在性能问题;
    • 5、配置备份: 配置数据首先会保存在Zookeeper中, 同时, 在MySQL中会对配置信息做备份, 保证配置数据的安全性;
    • 6、HA: 配置中心基于Zookeeper集群, 只要集群节点保证存活数量大于N/2+1, 就可保证服务稳定, 避免单点风险;
    • 7、分布式: 可方便的接入线上分布式部署的各个业务线, 统一管理配置信息;
    • 8、配置共享: 平台中的配置信息针对各个业务线是平等的, 各个业务线可以共享配置中心的配置信息, 当然也可以配置业务内专属配置信息;

    4.2 版本1.2.0新特性

    • 1、配置分组: 支持对配置进行分组管理, 每条配置将会生成全局唯一标示GroupKey,在client端使用时,需要通过该值匹配对应的配置信息;

    4.3 版本1.3.0新特性

    • 1、支持在线维护配置分组;
    • 2、项目groupId从com.xxl迁移至com.xuxueli,为推送maven中央仓库做准备;
    • 3、v1.3.0版本开始,推送公共依赖至中央仓库;

    4.4 版本1.3.1新特性(Coding)

    • zookeeper地址方式从磁盘迁移至项目内;

    TODO LIST

    • 1、权限管理:以分组为权限最小单元,只有分组的成员用户才有权限进行对应的配置操作;
    • 2、zookeeper客户端优化, 或将改用zkclient或者curator;
    • 3、local cache 备份到磁盘;zk异常且local properties未配置时,从磁盘上读取配置;

    五、其他

    5.1 报告问题

    XXL-CONF托管在Github上,如有问题可在 ISSUES 上提问,也可以加入上文技术交流群;

    5.2 接入登记

    更多接入公司,欢迎在github 登记


    案例四、

    DCMP 详细介绍

    DCMP是分布式配置管理平台。提供了一个etcd的管理界面,可通过界面修改配置信息,借助confd可实现配置文件的同步。

    安装 && 启动

    > go get github.com/silenceper/dcmp
    > ./service.sh

    界面预览

    访问 http://127.0.0.1:8000/


    Ø  超级管理员角色不展示;

    Ø  超级管理员可以看到所有非超级管理员角色,非超级管理员只可以看到当前角色用户创建的角色;

    Ø  可以新增角色,也可以对角色进行编辑,只有在创建用户时勾选是否为系统管理员才可以进行角色管理。

    【新建角色】:

    Ø  新建角色输入角色名称,可以勾选的权限为当前用户所拥有的权限;

    Ø  新建的角色作为该用户的下属角色,可分配给当前用户新建的用户;

    Ø  父级权限为新建应用所增加的权限,以后每增加一个环境,就相应的增加该应用下的该环境权限,除超级管理员外的角色需对应勾选该权限才能看到该应用或者该权限,保存角色即可。

    【编辑角色】:操作同新建角色,可以对该角色进行名称修改,权限修改。

    3.6用户

    管理用户首页,显示所有用户,可进行新建,编辑用户等操作。

     

    【新建用户】:填写姓名,用户名,密码,选择角色(拥有对应角色权限、且可以选择的角色为当前登陆用户新建的角色),选择是否为系统管理员(系统管理员拥有新建用户、新建角色权限),保存即可。

    【编辑用户】:操作同新建用户,保存即可修改。


    案例三、

    《分布式配置管理平台XXL-CONF》

    一、简介

    1.1 概述

    XXL-CONF 是一个分布式配置管理平台,其核心设计目标是“为分布式业务提供统一的配置管理服务”。现已开放源代码,开箱即用。

    1.2 特性

    • 1、简单易用: 上手非常简单, 只需要引入maven依赖和一行配置即可;
    • 2、在线管理: 提供配置管理中心, 支持在线管理配置信息;
    • 3、实时推送: 配置信息更新后, Zookeeper实时推送配置信息, 项目中配置数据会实时更新并生效, 不需要重启线上机器;
    • 4、高性能: 系统会对Zookeeper推送的配置信息, 在Encache中做本地缓存, 在接受推送更新或者缓存失效时会及时更新缓存数据, 因此业务中对配置数据的查询并不存在性能问题;
    • 5、配置备份: 配置数据首先会保存在Zookeeper中, 同时, 在MySQL中会对配置信息做备份, 保证配置数据的安全性;
    • 6、HA: 配置中心基于Zookeeper集群, 只要集群节点保证存活数量大于N/2+1, 就可保证服务稳定, 避免单点风险;
    • 7、分布式: 可方便的接入线上分布式部署的各个业务线, 统一管理配置信息;
    • 8、配置共享: 平台中的配置信息针对各个业务线是平等的, 各个业务线可以共享配置中心的配置信息, 当然也可以配置业务内专属配置信息;
    • 9、配置分组: 支持对配置进行分组管理, 每条配置将会生成全局唯一标示GroupKey,在client端使用时,需要通过该值匹配对应的配置信息;

    1.3 背景

    why not properties

    常规项目开发过程中, 通常会将配置信息位于在项目resource目录下的properties文件文件中, 配置信息通常包括有: jdbc地址配置、redis地址配置、活动开关、阈值配置、黑白名单……等等。使用properties维护配置信息将会导致以下几个问题:

    • 1、需要手动修改properties文件;
    • 2、需要重新编译打包;
    • 3、需要重启线上服务器 (项目集群时,更加令人崩溃) ;
    • 4、配置生效不及时: 因为流程复杂, 新的配置生效需要经历比较长的时间才可以生效;
    • 5、不同环境上线包不一致: 例如JDBC连接, 不同环境需要差异化配置;

    why XXL-CONF

    • 1、不需要 (手动修改properties文件) : 在配置管理中心提供的Web界面中, 定位到指定配置项, 输入新的配置的值, 点击更新按钮即可;
    • 2、不需要 (重新编译打包) : 配置更新后, 实时推送新配置信息至项目中, 不需要编译打包;
    • 3、不需要 (重启线上服务器) : 配置更新后, 实时推送新配置信息至项目中, 实时生效, 不需要重启线上机器; (在项目集群部署时, 将会节省大量的时间, 避免了集群机器一个一个的重启, 费时费力)
    • 4、配置生效 "非常及时" : 点击更新按钮, 新的配置信息将会即可推送到项目中, 瞬间生效, 非常及时。比如一些开关类型的配置, 配置变更后, 将会立刻推送至项目中并生效, 相对常规配置修改繁琐的流程, 及时性可谓天壤之别;
    • 5、不同环境 "同一个上线包" : 因为差异化的配置托管在配置中心, 因此一个上线包可以复用在生产、测试等各个运行环境, 提供能效;

    1.4 下载

    源码地址 (将会在两个git仓库同步发布最新代码)
    中央仓库地址 (最新Release版本)
    <dependency>
      <groupId>com.xuxueli</groupId>
      <artifactId>xxl-conf-core</artifactId>
      <version>1.3.0</version>
    </dependency>
    
    博客地址 (将会在两个博客同步更新文档)
    技术交流群 (仅作技术交流)
    • 群4:464762661 image
    • 群3:242151780 (群即将满,请加群4)
    • 群2:438249535 (群即将满,请加群4)
    • 群1:367260654 (群即将满,请加群4)

    1.5 环境

    • Maven3+
    • Jdk1.7+
    • Tomcat7+
    • Zookeeper3.4+
    • Mysql5.5+

    二、快速入门

    2.1 初始化“数据库”

    请下载项目源码并解压,获取 "调度数据库初始化SQL脚本" 并执行即可。脚本位置如下:

    xxl-conf/db/xxl-conf.sql
    

    2.2 编译源码

    解压源码,按照maven格式将源码导入IDE, 使用maven进行编译即可,源码结构如下图所示:

    输入图片说明

    • xxl-conf-admin:配置管理中心
    • xxl-conf-core:公共依赖
    • xxl-conf-example: 接入XXl-CONF的Demo项目

    2.3 “配置管理中心” 项目配置

    项目:xxl-conf-admin
    作用:管理线上配置信息
    

    配置文件位置:

    xxl-conf/xxl-conf-admin/src/main/resources/xxl-config-admin.properties
    

    配置项目说明:

    # xxl-conf, zk address  (配置中心zookeeper集群地址,如有多个地址用逗号分隔)
    xxl.conf.zkserver=127.0.0.1:2181
    
    # xxl-conf, jdbc    (配置中心mysql地址)
    xxl.conf.jdbc.driverClass=com.mysql.jdbc.Driver
    xxl.conf.jdbc.url=jdbc:mysql://localhost:3306/xxl-conf?Unicode=true&amp;characterEncoding=UTF-8
    xxl.conf.jdbc.username=root
    xxl.conf.jdbc.password=root_pwd
    
    # xxl-conf, admin login (管理中心登录账号密码)
    xxl.conf.login.username=admin
    xxl.conf.login.password=123456
    

    2.4 “接入XXL-CONF的Demo项目” 项目配置

    项目:xxl-conf-example
    作用:供用户参考学习如何接入XXL-CONF
    
    A、引入maven依赖
    <!-- xxl-conf-client -->
    <dependency>
        <groupId>com.xuxueli</groupId>
        <artifactId>xxl-conf-core</artifactId>
        <version>${xxl.conf.version}</version>
    </dependency>
    
    B、配置 “XXL-CONF配置解析器”

    可参考配置文件:

    /xxl-conf/xxl-conf-example/src/main/resources/spring/applicationcontext-xxl-conf.xml
    

    配置项说明

    <!-- XXL-CONF配置解析器 -->
    <bean id="xxlConfPropertyPlaceholderConfigurer" class="com.xxl.conf.core.spring.XxlConfPropertyPlaceholderConfigurer" />
    
    C、设置 "xxl-conf.properties"

    可参考配置文件:

    /xxl-conf/xxl-conf-example/src/main/resources/xxl-conf.properties
    

    配置项说明

    # xxl-conf, zk address  (配置中心zookeeper集群地址,如有多个地址用逗号分隔)
    xxl.conf.zkserver=127.0.0.1:2181
    

    该配置文件,除了支持配置ZK地址,还可以配置一些本地配置。 XXL-CONF 加载配置时会优先加载 "xxl-conf.properties" 中的配置, 然后才会加载ZK中的配置。可以将一些希望存放本地的配置存放在该文件。

    2.5 新增配置分组

    输入图片说明

    每个配置分组对应一个唯一的GroupName,作为该分组下配置的统一前缀。在“分组管理”栏目可以创建并管理配置分组信息,系统已经提供一个默认分组.

    2.6 新增配置信息

    登录"配置管理中心"

    输入图片说明

    进入"配置管理界面",点击"新增配置"按钮

    输入图片说明

    在弹出界面,填写配置信息

    输入图片说明

    至此, 一条配置信息已经添加完成.

    通过client端,可以实时获取配置信息, 通过本地已经加载过得配置将会接受Zookeeper的更新推送, 如下如日志:

    输入图片说明

    2.7 项目中使用XXL-CONF

    项目: xxl-conf-example:   (可以参考 com.xxl.conf.example.controller.IndexController.index() )
    作用: 接入XXl-CONF的Demo项目
    
    • 方式1: XML文件中的占位符方式

      <bean id="configuration" class="com.xxl.conf.example.core.constant.Configuration">
          <property name="paramByXml" value="${default.key01}" />
      </bean>
      

      特点:

      • 上面配置说明: 在项目启动时, Configuration的paramByXml属性, 会根据配置的占位符${default.key01}, 去XXL-CONF中匹配KEY=key01的配置信息, 赋值给paramByXml;
      • 目前, 该方式配置信息, 只会在项目启动时从XXL-CONF中加载一次, 项目启动后该值不会变更。 例如配置数据连接信息, 如果XXL-CONF平台中连接地址配置改边, 需要重启后才生效;
      • 该方式, 底层本质上是通过 "方式2: API方式" 实现的。
    • 方式2: API方式

      String paramByClient = XxlConfClient.get("default.key02", null);
      

      特点:

      • 上面代码说明: 会获取XXL-CONF平台中KEY=default.key02的配置信息, 如果不存在值使用传递的默认值;
      • 因为Zookeeper会实时推送配置更新到客户端, 因此该方法放回的值可以XXL-CONF平台中的值保持实时一致;
      • XXL-CONF会对Zookeeper推送的配置信息做本地缓存, 该方法查询的是缓存的配置信息, 因此该方法并不会产生性能问题, 使用时不需要考虑性能问题;

    三、总体设计

    3.1 架构图

    输入图片说明

    3.2 "配置项" 设计

    系统配置信息以K/V的形式存在, "配置项" 属性如下:

    • 分组: "配置项" 的分组, 便于配置分组管理;
    • KEY : "配置项" 的全局唯一标识, 对应一条配置信息;
    • VALUE : "配置项" 中保存的数据信息, 仅仅支持String字符串格式;
    • 描述 : 配置项的描述信息;

    每条配置,将会生成全局唯一标示GroupKey,在client端使用时,需要通过该值匹配对应的配置信息;

    3.3 "配置中心" 设计

    输入图片说明

    • 1、ZK设计: 系统在ZK集群中占用一个根目录 "/xxl-conf", 每新增一条配置项, 将会在该目录下新增一个子节点。结构如下图, 当配置变更时将会触发ZK节点的变更, 将会触发对应类型的ZK广播。
    • 2、数据库备份配置信息: 配置信息在ZK中的新增、变更等操作, 将会同步备份到Mysql中, 进一步保证数据的安全性;
    • 3、配置推送: 配置推送功能在ZK的Watch机制实现。Client在加载一条配置信息时将会Watch该配置对应的ZK节点, 因此, 当对该配置项进行配置更新等操作时, 将会触发ZK的NodeDataChanged广播, Client竟会立刻得到通知并刷新本地缓存中的配置信息;

    ZK之watcher普及(来源官方文档,以及网络博客)

    1、可以注册watcher的方法:getData、exists、getChildren。
    2、可以触发watcher的方法:create、delete、setData。连接断开的情况下触发的watcher会丢失。
    3、一个Watcher实例是一个回调函数,被回调一次后就被移除了。如果还需要关注数据的变化,需要再次注册watcher。
    4、New ZooKeeper时注册的watcher叫default watcher,它不是一次性的,只对client的连接状态变化作出反应。(推荐ZK初始化时, 主动Watcher如exists)
    5、实现永久监听: 由于zookeeper是一次性监听,所以我们必须在wather的process方法里面再设置监听。
    6、getChildren("/path")监视/path的子节点,如果(/path)自己删了,也会触发NodeDeleted事件。
    
    《操作--事件》 event For “/path” event For “/path/child”
    create(“/path”) EventType.NodeCreated
    delete(“/path”) EventType.NodeDeleted
    setData(“/path”) EventType.NodeDataChanged
    create(“/path/child”) EventType.NodeChildrenChanged(getChild) EventType.NodeCreated
    delete(“/path/child”) EventType.NodeChildrenChanged(getChild) EventType.NodeDeleted
    setData(“/path/child”) EventType.NodeDataChanged

    《事件--Watch方式》 | Default Watcher | exists(“/path”) | getData(“/path”) | getChildren(“/path”) --- | --- | --- | --- EventType.None | 触发 | 触发 | 触发 | 触发 EventType.NodeCreated | | 触发 | 触发 |
    EventType.NodeDeleted | | 触发 | 触发 | EventType.NodeDataChanged | | 触发 | 触发 | EventType.NodeChildrenChanged | | | | 触发

    ZooKeeper的一个性能测试

    测试数据来自阿里中间件团队

    ZK集群情况: 3台ZooKeeper服务器。8核64位jdk1.6;log和snapshot放在不同磁盘;

    • 场景一: pub创建NODE,随后删除

      • 操作: 同一个目录下,先create EPHEMERAL node,再delete;create和delete各计一次更新。没有订阅。一个进程开多个连接,每个连接绑定一个线程,在多个path下做上述操作;不同的连接操作的path不同
      • 结果数据: "dataSize(字节)-TPS-响应时间(ms)" 统计结果为: 255-14723-82, 1024-7677-280, 4096-2037-1585;
    • 场景二: pub创建NODE, sub订阅并获取数据

      • 操作: 一个进程开多个连接,每连接一个线程,每个连接在多个path下做下述操作;不同的连接操作的path不同。每个path有3个订阅者连接,一个修改者连接。先全部订阅好。然后每个修改者在自己的每个path下创建一个EPHEMERAL node,不删除;创建前记录时间,订阅者收到event后记录时间(eventStat);重新get到数据后再记录时间(dataStat)。共1000个pub连接,3000个sub连接,20W条数据。收到通知后再去读取数据,五台4核client机器。
      • 结果汇总: getAfterNotify=false(只收事件,受到通知后不去读取数据);五台4核client机器
      • 结果数据: "dataSize(字节)-TPS-响应时间(ms)" 统计结果为: 255-1W+-256ms, 1024-1W+-256, 2048-1W+-270, 4096-8000+-520;
    • 场景三: pub创建NODE,随后设置数据

      • 一个进程开多个连接,每连接一个线程,每个连接在多个path下做下述操作;不同的连接操作的path不同。每个path有一个修改者连接,没有订阅者。每个修改者在自己的每个path下设置数据。
      • 结果汇总: getAfterNotify=false(只收事件,受到通知后不去读取数据);五台4核client机器
      • 结果数据: "dataSize(字节)-TPS-响应时间(ms)" 统计结果为: 255-14723-82, 1024-7677-280, 4096-2037-1585 ;

    总结: 由于一致性协议带来的额外网络交互,消息开销,以及本地log的IO开销,再加上ZK本身每1000条批量处理1次的优化策略,写入的平均响应时间总会在50-60ms之上。但是整体的TPS还是可观的。单个写入数据的体积越大,响应时间越长,TPS越低,这也是普遍规律了。压测过程中log文件对磁盘的消耗很大。实际运行中应该使用自动脚本定时删除历史log和snapshot文件。

    3.4 "配置管理中心" 设计

    "配置管理中心" 是 "配置中心" 的上层封装, 提供Web界面供用户对配置信息进行配置查询、配置新增、配置更新和配置删除等操作;

    3.5 "客户端" 设计

    输入图片说明

    API方式加载配置: 客户端主要分为三层:

    • ZK-Client : 第一层为ZK远程客户端的封装, 当业务方项目初始化某一个用到的配置项时, 将会触发ZK-Client对该配置对应节点的Watch, 因此当该节点变动时将会监听到ZK的类似NodeDataChanged的广播, 可以实时获取最新配置信息;
    • Ehcache : 第二层为客户端本地缓存, 可以大大提高系统的并发能力, 当配置初始化或者接受到ZK-Client的配置变更时, 将会把配置信息缓存只Encache中, 业务中针对配置的查询都是读缓存方式实现, 降低对ZK集群的压力;
    • Client-API : 第三层为暴露给业务方使用API, 简单易用, 一行代码获取配置信息, 同时可保证API获取到的配置信息是实时最新的配置信息;

    (API方式加载配置, 因为底层做了配置本地缓存, 因此可以放心应用在业务代码中, 不必担心并发压力。完整的支持配置实时推送更新)

    输入图片说明

    Bean方式加载配置:

    系统会在Spring容器中追加一个"PropertyPlaceholderConfigurer"属性解析器, 内部通过自定义的"StringValueResolver"解析器解析配置占位符 "${...}", 匹配到的配置信息将调用"XXL-CFONF"的API客户端加载最新配置信息进行Bean对象的属性赋值,最终完成实例化过程。

    (Bean方式加载配置,仅仅在实例化时加载一次; 考虑都实例化后的对象通常为持久化对象, 如数据库连接池对象, 不建议配置的太灵活, 因此Bean类型配置更新需要重启机器)

    四、历史版本

    4.1 版本1.1.0新特性

    • 1、简单易用: 上手非常简单, 只需要引入maven依赖和一行配置即可;
    • 2、在线管理: 提供配置管理中心, 支持在线管理配置信息;
    • 3、实时推送: 配置信息更新后, Zookeeper实时推送配置信息, 项目中配置数据会实时更新并生效, 不需要重启线上机器;
    • 4、高性能: 系统会对Zookeeper推送的配置信息, 在Encache中做本地缓存, 在接受推送更新或者缓存失效时会及时更新缓存数据, 因此业务中对配置数据的查询并不存在性能问题;
    • 5、配置备份: 配置数据首先会保存在Zookeeper中, 同时, 在MySQL中会对配置信息做备份, 保证配置数据的安全性;
    • 6、HA: 配置中心基于Zookeeper集群, 只要集群节点保证存活数量大于N/2+1, 就可保证服务稳定, 避免单点风险;
    • 7、分布式: 可方便的接入线上分布式部署的各个业务线, 统一管理配置信息;
    • 8、配置共享: 平台中的配置信息针对各个业务线是平等的, 各个业务线可以共享配置中心的配置信息, 当然也可以配置业务内专属配置信息;

    4.2 版本1.2.0新特性

    • 1、配置分组: 支持对配置进行分组管理, 每条配置将会生成全局唯一标示GroupKey,在client端使用时,需要通过该值匹配对应的配置信息;

    4.3 版本1.3.0新特性

    • 1、支持在线维护配置分组;
    • 2、项目groupId从com.xxl迁移至com.xuxueli,为推送maven中央仓库做准备;
    • 3、v1.3.0版本开始,推送公共依赖至中央仓库;

    4.4 版本1.3.1新特性(Coding)

    • zookeeper地址方式从磁盘迁移至项目内;

    TODO LIST

    • 1、权限管理:以分组为权限最小单元,只有分组的成员用户才有权限进行对应的配置操作;
    • 2、zookeeper客户端优化, 或将改用zkclient或者curator;
    • 3、local cache 备份到磁盘;zk异常且local properties未配置时,从磁盘上读取配置;

    五、其他

    5.1 报告问题

    XXL-CONF托管在Github上,如有问题可在 ISSUES 上提问,也可以加入上文技术交流群;

    5.2 接入登记

    更多接入公司,欢迎在github 登记


    案例四、

    Ø  超级管理员角色不展示;

    Ø  超级管理员可以看到所有非超级管理员角色,非超级管理员只可以看到当前角色用户创建的角色;

    Ø  可以新增角色,也可以对角色进行编辑,只有在创建用户时勾选是否为系统管理员才可以进行角色管理。

    【新建角色】:

    Ø  新建角色输入角色名称,可以勾选的权限为当前用户所拥有的权限;

    Ø  新建的角色作为该用户的下属角色,可分配给当前用户新建的用户;

    Ø  父级权限为新建应用所增加的权限,以后每增加一个环境,就相应的增加该应用下的该环境权限,除超级管理员外的角色需对应勾选该权限才能看到该应用或者该权限,保存角色即可。

    【编辑角色】:操作同新建角色,可以对该角色进行名称修改,权限修改。

    3.6用户

    管理用户首页,显示所有用户,可进行新建,编辑用户等操作。

     

    【新建用户】:填写姓名,用户名,密码,选择角色(拥有对应角色权限、且可以选择的角色为当前登陆用户新建的角色),选择是否为系统管理员(系统管理员拥有新建用户、新建角色权限),保存即可。

    【编辑用户】:操作同新建用户,保存即可修改。


    案例三、

    《分布式配置管理平台XXL-CONF》

    一、简介

    1.1 概述

    XXL-CONF 是一个分布式配置管理平台,其核心设计目标是“为分布式业务提供统一的配置管理服务”。现已开放源代码,开箱即用。

    1.2 特性

    • 1、简单易用: 上手非常简单, 只需要引入maven依赖和一行配置即可;
    • 2、在线管理: 提供配置管理中心, 支持在线管理配置信息;
    • 3、实时推送: 配置信息更新后, Zookeeper实时推送配置信息, 项目中配置数据会实时更新并生效, 不需要重启线上机器;
    • 4、高性能: 系统会对Zookeeper推送的配置信息, 在Encache中做本地缓存, 在接受推送更新或者缓存失效时会及时更新缓存数据, 因此业务中对配置数据的查询并不存在性能问题;
    • 5、配置备份: 配置数据首先会保存在Zookeeper中, 同时, 在MySQL中会对配置信息做备份, 保证配置数据的安全性;
    • 6、HA: 配置中心基于Zookeeper集群, 只要集群节点保证存活数量大于N/2+1, 就可保证服务稳定, 避免单点风险;
    • 7、分布式: 可方便的接入线上分布式部署的各个业务线, 统一管理配置信息;
    • 8、配置共享: 平台中的配置信息针对各个业务线是平等的, 各个业务线可以共享配置中心的配置信息, 当然也可以配置业务内专属配置信息;
    • 9、配置分组: 支持对配置进行分组管理, 每条配置将会生成全局唯一标示GroupKey,在client端使用时,需要通过该值匹配对应的配置信息;

    1.3 背景

    why not properties

    常规项目开发过程中, 通常会将配置信息位于在项目resource目录下的properties文件文件中, 配置信息通常包括有: jdbc地址配置、redis地址配置、活动开关、阈值配置、黑白名单……等等。使用properties维护配置信息将会导致以下几个问题:

    • 1、需要手动修改properties文件;
    • 2、需要重新编译打包;
    • 3、需要重启线上服务器 (项目集群时,更加令人崩溃) ;
    • 4、配置生效不及时: 因为流程复杂, 新的配置生效需要经历比较长的时间才可以生效;
    • 5、不同环境上线包不一致: 例如JDBC连接, 不同环境需要差异化配置;

    why XXL-CONF

    • 1、不需要 (手动修改properties文件) : 在配置管理中心提供的Web界面中, 定位到指定配置项, 输入新的配置的值, 点击更新按钮即可;
    • 2、不需要 (重新编译打包) : 配置更新后, 实时推送新配置信息至项目中, 不需要编译打包;
    • 3、不需要 (重启线上服务器) : 配置更新后, 实时推送新配置信息至项目中, 实时生效, 不需要重启线上机器; (在项目集群部署时, 将会节省大量的时间, 避免了集群机器一个一个的重启, 费时费力)
    • 4、配置生效 "非常及时" : 点击更新按钮, 新的配置信息将会即可推送到项目中, 瞬间生效, 非常及时。比如一些开关类型的配置, 配置变更后, 将会立刻推送至项目中并生效, 相对常规配置修改繁琐的流程, 及时性可谓天壤之别;
    • 5、不同环境 "同一个上线包" : 因为差异化的配置托管在配置中心, 因此一个上线包可以复用在生产、测试等各个运行环境, 提供能效;

    1.4 下载

    源码地址 (将会在两个git仓库同步发布最新代码)
    中央仓库地址 (最新Release版本)
    <dependency>
      <groupId>com.xuxueli</groupId>
      <artifactId>xxl-conf-core</artifactId>
      <version>1.3.0</version>
    </dependency>
    
    博客地址 (将会在两个博客同步更新文档)
    技术交流群 (仅作技术交流)
    • 群4:464762661 image
    • 群3:242151780 (群即将满,请加群4)
    • 群2:438249535 (群即将满,请加群4)
    • 群1:367260654 (群即将满,请加群4)

    1.5 环境

    • Maven3+
    • Jdk1.7+
    • Tomcat7+
    • Zookeeper3.4+
    • Mysql5.5+

    二、快速入门

    2.1 初始化“数据库”

    请下载项目源码并解压,获取 "调度数据库初始化SQL脚本" 并执行即可。脚本位置如下:

    xxl-conf/db/xxl-conf.sql
    

    2.2 编译源码

    解压源码,按照maven格式将源码导入IDE, 使用maven进行编译即可,源码结构如下图所示:

    输入图片说明

    • xxl-conf-admin:配置管理中心
    • xxl-conf-core:公共依赖
    • xxl-conf-example: 接入XXl-CONF的Demo项目

    2.3 “配置管理中心” 项目配置

    项目:xxl-conf-admin
    作用:管理线上配置信息
    

    配置文件位置:

    xxl-conf/xxl-conf-admin/src/main/resources/xxl-config-admin.properties
    

    配置项目说明:

    # xxl-conf, zk address  (配置中心zookeeper集群地址,如有多个地址用逗号分隔)
    xxl.conf.zkserver=127.0.0.1:2181
    
    # xxl-conf, jdbc    (配置中心mysql地址)
    xxl.conf.jdbc.driverClass=com.mysql.jdbc.Driver
    xxl.conf.jdbc.url=jdbc:mysql://localhost:3306/xxl-conf?Unicode=true&amp;characterEncoding=UTF-8
    xxl.conf.jdbc.username=root
    xxl.conf.jdbc.password=root_pwd
    
    # xxl-conf, admin login (管理中心登录账号密码)
    xxl.conf.login.username=admin
    xxl.conf.login.password=123456
    

    2.4 “接入XXL-CONF的Demo项目” 项目配置

    项目:xxl-conf-example
    作用:供用户参考学习如何接入XXL-CONF
    
    A、引入maven依赖
    <!-- xxl-conf-client -->
    <dependency>
        <groupId>com.xuxueli</groupId>
        <artifactId>xxl-conf-core</artifactId>
        <version>${xxl.conf.version}</version>
    </dependency>
    
    B、配置 “XXL-CONF配置解析器”

    可参考配置文件:

    /xxl-conf/xxl-conf-example/src/main/resources/spring/applicationcontext-xxl-conf.xml
    

    配置项说明

    <!-- XXL-CONF配置解析器 -->
    <bean id="xxlConfPropertyPlaceholderConfigurer" class="com.xxl.conf.core.spring.XxlConfPropertyPlaceholderConfigurer" />
    
    C、设置 "xxl-conf.properties"

    可参考配置文件:

    /xxl-conf/xxl-conf-example/src/main/resources/xxl-conf.properties
    

    配置项说明

    # xxl-conf, zk address  (配置中心zookeeper集群地址,如有多个地址用逗号分隔)
    xxl.conf.zkserver=127.0.0.1:2181
    

    该配置文件,除了支持配置ZK地址,还可以配置一些本地配置。 XXL-CONF 加载配置时会优先加载 "xxl-conf.properties" 中的配置, 然后才会加载ZK中的配置。可以将一些希望存放本地的配置存放在该文件。

    2.5 新增配置分组

    输入图片说明

    每个配置分组对应一个唯一的GroupName,作为该分组下配置的统一前缀。在“分组管理”栏目可以创建并管理配置分组信息,系统已经提供一个默认分组.

    2.6 新增配置信息

    登录"配置管理中心"

    输入图片说明

    进入"配置管理界面",点击"新增配置"按钮

    输入图片说明

    在弹出界面,填写配置信息

    输入图片说明

    至此, 一条配置信息已经添加完成.

    通过client端,可以实时获取配置信息, 通过本地已经加载过得配置将会接受Zookeeper的更新推送, 如下如日志:

    输入图片说明

    2.7 项目中使用XXL-CONF

    项目: xxl-conf-example:   (可以参考 com.xxl.conf.example.controller.IndexController.index() )
    作用: 接入XXl-CONF的Demo项目
    
    • 方式1: XML文件中的占位符方式

      <bean id="configuration" class="com.xxl.conf.example.core.constant.Configuration">
          <property name="paramByXml" value="${default.key01}" />
      </bean>
      

      特点:

      • 上面配置说明: 在项目启动时, Configuration的paramByXml属性, 会根据配置的占位符${default.key01}, 去XXL-CONF中匹配KEY=key01的配置信息, 赋值给paramByXml;
      • 目前, 该方式配置信息, 只会在项目启动时从XXL-CONF中加载一次, 项目启动后该值不会变更。 例如配置数据连接信息, 如果XXL-CONF平台中连接地址配置改边, 需要重启后才生效;
      • 该方式, 底层本质上是通过 "方式2: API方式" 实现的。
    • 方式2: API方式

      String paramByClient = XxlConfClient.get("default.key02", null);
      

      特点:

      • 上面代码说明: 会获取XXL-CONF平台中KEY=default.key02的配置信息, 如果不存在值使用传递的默认值;
      • 因为Zookeeper会实时推送配置更新到客户端, 因此该方法放回的值可以XXL-CONF平台中的值保持实时一致;
      • XXL-CONF会对Zookeeper推送的配置信息做本地缓存, 该方法查询的是缓存的配置信息, 因此该方法并不会产生性能问题, 使用时不需要考虑性能问题;

    三、总体设计

    3.1 架构图

    输入图片说明

    3.2 "配置项" 设计

    系统配置信息以K/V的形式存在, "配置项" 属性如下:

    • 分组: "配置项" 的分组, 便于配置分组管理;
    • KEY : "配置项" 的全局唯一标识, 对应一条配置信息;
    • VALUE : "配置项" 中保存的数据信息, 仅仅支持String字符串格式;
    • 描述 : 配置项的描述信息;

    每条配置,将会生成全局唯一标示GroupKey,在client端使用时,需要通过该值匹配对应的配置信息;

    3.3 "配置中心" 设计

    输入图片说明

    • 1、ZK设计: 系统在ZK集群中占用一个根目录 "/xxl-conf", 每新增一条配置项, 将会在该目录下新增一个子节点。结构如下图, 当配置变更时将会触发ZK节点的变更, 将会触发对应类型的ZK广播。
    • 2、数据库备份配置信息: 配置信息在ZK中的新增、变更等操作, 将会同步备份到Mysql中, 进一步保证数据的安全性;
    • 3、配置推送: 配置推送功能在ZK的Watch机制实现。Client在加载一条配置信息时将会Watch该配置对应的ZK节点, 因此, 当对该配置项进行配置更新等操作时, 将会触发ZK的NodeDataChanged广播, Client竟会立刻得到通知并刷新本地缓存中的配置信息;

    ZK之watcher普及(来源官方文档,以及网络博客)

    1、可以注册watcher的方法:getData、exists、getChildren。
    2、可以触发watcher的方法:create、delete、setData。连接断开的情况下触发的watcher会丢失。
    3、一个Watcher实例是一个回调函数,被回调一次后就被移除了。如果还需要关注数据的变化,需要再次注册watcher。
    4、New ZooKeeper时注册的watcher叫default watcher,它不是一次性的,只对client的连接状态变化作出反应。(推荐ZK初始化时, 主动Watcher如exists)
    5、实现永久监听: 由于zookeeper是一次性监听,所以我们必须在wather的process方法里面再设置监听。
    6、getChildren("/path")监视/path的子节点,如果(/path)自己删了,也会触发NodeDeleted事件。
    
    《操作--事件》 event For “/path” event For “/path/child”
    create(“/path”) EventType.NodeCreated
    delete(“/path”) EventType.NodeDeleted
    setData(“/path”) EventType.NodeDataChanged
    create(“/path/child”) EventType.NodeChildrenChanged(getChild) EventType.NodeCreated
    delete(“/path/child”) EventType.NodeChildrenChanged(getChild) EventType.NodeDeleted
    setData(“/path/child”) EventType.NodeDataChanged

    《事件--Watch方式》 | Default Watcher | exists(“/path”) | getData(“/path”) | getChildren(“/path”) --- | --- | --- | --- EventType.None | 触发 | 触发 | 触发 | 触发 EventType.NodeCreated | | 触发 | 触发 |
    EventType.NodeDeleted | | 触发 | 触发 | EventType.NodeDataChanged | | 触发 | 触发 | EventType.NodeChildrenChanged | | | | 触发

    ZooKeeper的一个性能测试

    测试数据来自阿里中间件团队

    ZK集群情况: 3台ZooKeeper服务器。8核64位jdk1.6;log和snapshot放在不同磁盘;

    • 场景一: pub创建NODE,随后删除

      • 操作: 同一个目录下,先create EPHEMERAL node,再delete;create和delete各计一次更新。没有订阅。一个进程开多个连接,每个连接绑定一个线程,在多个path下做上述操作;不同的连接操作的path不同
      • 结果数据: "dataSize(字节)-TPS-响应时间(ms)" 统计结果为: 255-14723-82, 1024-7677-280, 4096-2037-1585;
    • 场景二: pub创建NODE, sub订阅并获取数据

      • 操作: 一个进程开多个连接,每连接一个线程,每个连接在多个path下做下述操作;不同的连接操作的path不同。每个path有3个订阅者连接,一个修改者连接。先全部订阅好。然后每个修改者在自己的每个path下创建一个EPHEMERAL node,不删除;创建前记录时间,订阅者收到event后记录时间(eventStat);重新get到数据后再记录时间(dataStat)。共1000个pub连接,3000个sub连接,20W条数据。收到通知后再去读取数据,五台4核client机器。
      • 结果汇总: getAfterNotify=false(只收事件,受到通知后不去读取数据);五台4核client机器
      • 结果数据: "dataSize(字节)-TPS-响应时间(ms)" 统计结果为: 255-1W+-256ms, 1024-1W+-256, 2048-1W+-270, 4096-8000+-520;
    • 场景三: pub创建NODE,随后设置数据

      • 一个进程开多个连接,每连接一个线程,每个连接在多个path下做下述操作;不同的连接操作的path不同。每个path有一个修改者连接,没有订阅者。每个修改者在自己的每个path下设置数据。
      • 结果汇总: getAfterNotify=false(只收事件,受到通知后不去读取数据);五台4核client机器
      • 结果数据: "dataSize(字节)-TPS-响应时间(ms)" 统计结果为: 255-14723-82, 1024-7677-280, 4096-2037-1585 ;

    总结: 由于一致性协议带来的额外网络交互,消息开销,以及本地log的IO开销,再加上ZK本身每1000条批量处理1次的优化策略,写入的平均响应时间总会在50-60ms之上。但是整体的TPS还是可观的。单个写入数据的体积越大,响应时间越长,TPS越低,这也是普遍规律了。压测过程中log文件对磁盘的消耗很大。实际运行中应该使用自动脚本定时删除历史log和snapshot文件。

    3.4 "配置管理中心" 设计

    "配置管理中心" 是 "配置中心" 的上层封装, 提供Web界面供用户对配置信息进行配置查询、配置新增、配置更新和配置删除等操作;

    3.5 "客户端" 设计

    输入图片说明

    API方式加载配置: 客户端主要分为三层:

    • ZK-Client : 第一层为ZK远程客户端的封装, 当业务方项目初始化某一个用到的配置项时, 将会触发ZK-Client对该配置对应节点的Watch, 因此当该节点变动时将会监听到ZK的类似NodeDataChanged的广播, 可以实时获取最新配置信息;
    • Ehcache : 第二层为客户端本地缓存, 可以大大提高系统的并发能力, 当配置初始化或者接受到ZK-Client的配置变更时, 将会把配置信息缓存只Encache中, 业务中针对配置的查询都是读缓存方式实现, 降低对ZK集群的压力;
    • Client-API : 第三层为暴露给业务方使用API, 简单易用, 一行代码获取配置信息, 同时可保证API获取到的配置信息是实时最新的配置信息;

    (API方式加载配置, 因为底层做了配置本地缓存, 因此可以放心应用在业务代码中, 不必担心并发压力。完整的支持配置实时推送更新)

    输入图片说明

    Bean方式加载配置:

    系统会在Spring容器中追加一个"PropertyPlaceholderConfigurer"属性解析器, 内部通过自定义的"StringValueResolver"解析器解析配置占位符 "${...}", 匹配到的配置信息将调用"XXL-CFONF"的API客户端加载最新配置信息进行Bean对象的属性赋值,最终完成实例化过程。

    (Bean方式加载配置,仅仅在实例化时加载一次; 考虑都实例化后的对象通常为持久化对象, 如数据库连接池对象, 不建议配置的太灵活, 因此Bean类型配置更新需要重启机器)

    四、历史版本

    4.1 版本1.1.0新特性

    • 1、简单易用: 上手非常简单, 只需要引入maven依赖和一行配置即可;
    • 2、在线管理: 提供配置管理中心, 支持在线管理配置信息;
    • 3、实时推送: 配置信息更新后, Zookeeper实时推送配置信息, 项目中配置数据会实时更新并生效, 不需要重启线上机器;
    • 4、高性能: 系统会对Zookeeper推送的配置信息, 在Encache中做本地缓存, 在接受推送更新或者缓存失效时会及时更新缓存数据, 因此业务中对配置数据的查询并不存在性能问题;
    • 5、配置备份: 配置数据首先会保存在Zookeeper中, 同时, 在MySQL中会对配置信息做备份, 保证配置数据的安全性;
    • 6、HA: 配置中心基于Zookeeper集群, 只要集群节点保证存活数量大于N/2+1, 就可保证服务稳定, 避免单点风险;
    • 7、分布式: 可方便的接入线上分布式部署的各个业务线, 统一管理配置信息;
    • 8、配置共享: 平台中的配置信息针对各个业务线是平等的, 各个业务线可以共享配置中心的配置信息, 当然也可以配置业务内专属配置信息;

    4.2 版本1.2.0新特性

    • 1、配置分组: 支持对配置进行分组管理, 每条配置将会生成全局唯一标示GroupKey,在client端使用时,需要通过该值匹配对应的配置信息;

    4.3 版本1.3.0新特性

    • 1、支持在线维护配置分组;
    • 2、项目groupId从com.xxl迁移至com.xuxueli,为推送maven中央仓库做准备;
    • 3、v1.3.0版本开始,推送公共依赖至中央仓库;

    4.4 版本1.3.1新特性(Coding)

    • zookeeper地址方式从磁盘迁移至项目内;

    TODO LIST

    • 1、权限管理:以分组为权限最小单元,只有分组的成员用户才有权限进行对应的配置操作;
    • 2、zookeeper客户端优化, 或将改用zkclient或者curator;
    • 3、local cache 备份到磁盘;zk异常且local properties未配置时,从磁盘上读取配置;

    五、其他

    5.1 报告问题

    XXL-CONF托管在Github上,如有问题可在 ISSUES 上提问,也可以加入上文技术交流群;

    5.2 接入登记

    更多接入公司,欢迎在github 登记


    案例五、

    分布式配置管理平台Disconf

    摘要

    为了更好的解决分布式环境下多台服务实例的配置统一管理问题,本文提出了一套完整的分布式配置管理解决方案(简称为disconf[4],下同)。首先,实现了同构系统的配置发布统一化,提供了配置服务server,该服务可以对配置进行持久化管理并对外提供restful接口,在此基础上,基于zookeeper实现对配置更改的实时推送,并且,提供了稳定有效的容灾方案,以及用户体验良好的编程模型和WEB用户管理界面。其次,实现了异构系统的配置包管理,提出基于zookeeper的全局分布式一致性锁来实现主备统一部署、系统异常时的主备自主切换。通过在百度内部以及外部等多个产品线的实践结果表明,本解决方案是有效且稳定的。

    技术背景

    在一个分布式环境中,同类型的服务往往会部署很多实例。这些实例使用了一些配置,为了更好地维护这些配置就产生了配置管理服务。通过这个服务可以轻松地管理成千上百个服务实例的配置问题。

    王阿晶提出了基于zooKeeper的配置信息存储方案的设计与实现[1], 它将所有配置存储在zookeeper上,这会导致配置的管理不那么方便,而且他们没有相关的源码实现。淘宝的diamond[2]是淘宝内部使用的一个管理持久配置的系统,它具有完整的开源源码实现,它的特点是简单、可靠、易用,淘宝内部绝大多数系统的配置都采用diamond来进行统一管理。他将所有配置文件里的配置打散化进行存储,只支持KV结构,并且配置更新的推送是非实时的。百度内部的BJF配置中心服务[3]采用了类似淘宝diamond的实现,也是配置打散化、只支持KV和非实时推送。

    同构系统是市场的主流,特别地,在业界大量使用部署虚拟化(如JPAAS系统,SAE,BAE)的情况下,同一个系统使用同一个部署包的情景会越来越多。但是,异构系统也有一定的存在意义,譬如,对于“拉模式”的多个下游实例,同一时间点只能只有一个下游实例在运行。在这种情景下,就存在多台实例机器有“主备机”模式的问题。目前国内并没有很明显的解决方案来统一解决此问题。

    功能特点与设计理念

    disconf是一套完整的基于zookeeper的分布式配置统一解决方案。

    它的功能特点是

    • 支持配置(配置项+配置文件)的分布式化管理
      • 配置发布统一化
      • 配置发布、更新统一化(云端存储、发布):配置存储在云端系统,用户统一在平台上进行发布、更新配置。
      • 配置更新自动化:用户在平台更新配置,使用该配置的系统会自动发现该情况,并应用新配置。特殊地,如果用户为此配置定义了回调函数类,则此函数类会被自动调用。
    • 配置异构系统管理
      • 异构包部署统一化:这里的异构系统是指一个系统部署多个实例时,由于配置不同,从而需要多个部署包(jar或war)的情况(下同)。使用Disconf后,异构系统的部署只需要一个部署包,不同实例的配置会自动分配。特别地,在业界大量使用部署虚拟化(如JPAAS系统,SAE,BAE)的情况下,同一个系统使用同一个部署包的情景会越来越多,Disconf可以很自然地与他天然契合。 异构主备自动切换:如果一个异构系统存在主备机,主机发生挂机时,备机可以自动获取主机配置从而变成主机。
      • 异构主备机Context共享工具:异构系统下,主备机切换时可能需要共享Context。可以使用Context共享工具来共享主备的Context。
    • 注解式编程,极简的使用方式:我们追求的是极简的、用户编程体验良好的编程方式。通过简单的标注+极简单的代码撰写,即可完成复杂的配置分布式化。
    • 需要Spring编程环境

    它的设计理念是:

    • 简单,用户体验良好:
      • 摒弃了打散化配置的管理方式[2,3],仍旧采用基于配置文件的编程方式,这和程序员以前的编程习惯(配置都是放在配置文件里)一致。特别的,为了支持较为小众的打散化配置功能,还特别支持了配置项。
      • 采用了基于XML无代码侵入编程方式:只需要几行XML配置,即可实现配置文件发布更新统一化、自动化。
      • 采用了基于注解式的弱代码侵入编程方式:通过编程规范,一个配置文件一个配置类,代码结构简单易懂。XML几乎没有任何更改,与原springXML配置一样。真正编程时,几乎感觉不到配置已经分布式化
    • 可以托管任何类型的配置文件,这与[2,3]只能支持KV结构的功能有较大的改进。
    • 配置更新实时推送
    • 提供界面良好Web管理功能,可以非常方便的查看配置被哪些实例使用了。

    详细设计

    架构设计

    disconf服务集群模式

    disconf的模块架构图

    每个模块的简单介绍如下:

    • Disconf-core
      • 分布式通知模块:支持配置更新的实时化通知
      • 路径管理模块:统一管理内部配置路径URL
    • Disconf-client
      • 配置仓库容器模块:统一管理用户实例中本地配置文件和配置项的内存数据存储
      • 配置reload模块:监控本地配置文件的变动,并自动reload到指定bean
      • 扫描模块:支持扫描所有disconf注解的类和域
      • 下载模块:restful风格的下载配置文件和配置项
      • watch模块:监控远程配置文件和配置项的变化
      • 主备分配模块:主备竞争结束后,统一管理主备分配与主备监控控制
      • 主备竞争模块:支持分布式环境下的主备竞争
    • Disconf-web
      • 配置存储模块:管理所有配置的存储和读取
      • 配置管理模块:支持配置的上传、下载、更新
      • 通知模块:当配置更新后,实时通知使用这些配置的所有实例
      • 配置自检监控模块:自动定时校验实例本地配置与中心配置是否一致
      • 权限控制:web的简单权限控制
    • Disconf-tools
      • context共享模块:提供多实例间context的共享。

    流程设计

    运行流程详细介绍:

    与2.0版本的主要区别是支持了:主备分配功能/主备切换事件。

    • 启动事件A:以下按顺序发生。
      • A3:扫描静态注解类数据,并注入到配置仓库里。
      • A4+A2:根据仓库里的配置文件、配置项,去 disconf-web 平台里下载配置数据。这里会有主备竞争
      • A5:将下载得到的配置数据值注入到仓库里。
      • A6:根据仓库里的配置文件、配置项,去ZK上监控结点。
      • A7+A2:根据XML配置定义,到 disconf-web 平台里下载配置文件,放在仓库里,并监控ZK结点。这里会有主备竞争。
      • A8:A1-A6均是处理静态类数据。A7是处理动态类数据,包括:实例化配置的回调函数类;将配置的值注入到配置实体里。
    • 更新配置事件B:以下按顺序发生。
      • B1:管理员在 Disconf-web 平台上更新配置。
      • B2:Disconf-web 平台发送配置更新消息给ZK指定的结点。
      • B3:ZK通知 Disconf-cient 模块。
      • B4:与A4一样。
      • B5:与A5一样。
      • B6:基本与A4一样,唯一的区别是,这里还会将配置的新值注入到配置实体里。
    • 主备机切换事件C:以下按顺序发生。
      • C1:发生主机挂机事件。
      • C2:ZK通知所有被影响到的备机。
      • C4:与A2一样。
      • C5:与A4一样。
      • C6:与A5一样。
      • C7:与A6一样。

    模块实现

    disconf-web提供了前后端分离的web架构,具体可见:https://github.com/knightliao/disconf/tree/master/disconf-web

    本部分会重点介绍disconf-client的实现方式。

    注解式disconf实现

    本实现会涉及到 配置仓库容器模块、扫描模块、下载模块、watch模块,

    http://ww1.sinaimg.cn/bmiddle/60c9620fjw1eqj9zzgc7yj20b20pn41v.jpg

    使用AOP拦截的一个好处是可以比较轻松的实现配置控制,比如并发环境下的配置统一生效。关于这方面的讨论可以见这里

    特别地,本方式提供的编程模式非常简单,例如使用以下配置类的程序在使用它时,可以直接@Autowired进来进行调用,使用它时就和平常使用普通的JavaBean一样,但其实它已经分布式化了。配置更新时,配置类亦会自动更新。

    @Service
    @DisconfFile(filename = "redis.properties")
    public class JedisConfig {
    
        // 代表连接地址
        private String host;
    
        // 代表连接port
        private int port;
    
        /**
         * 地址, 分布式文件配置
         * 
         * @return
         */
        @DisconfFileItem(name = "redis.host", associateField = "host")
        public String getHost() {
            return host;
        }
    
        public void setHost(String host) {
            this.host = host;
        }
    
        /**
         * 端口, 分布式文件配置
         * 
         * @return
         */
        @DisconfFileItem(name = "redis.port", associateField = "port")
        public int getPort() {
            return port;
        }
    
        public void setPort(int port) {
            this.port = port;
        }
    }
    

    基于XML配置disconf实现

    本实现提供了无任何代码侵入方式的分布式配置。

    ReloadablePropertiesFactoryBean继承了Spring Properties文件的PropertiesFactoryBean类,管理所有当配置更新时要进行reload的配置文件。对于被管理的每一个配置文件,都会通过 配置仓库容器模块、扫描模块、下载模块、watch模块 进行配置获取至配置仓库里。

    ReloadingPropertyPlaceholderConfigurer继承了Spring Bean配置值控制类PropertyPlaceholderConfigurer。在第一次扫描spring bean里,disconf会记录配置文件的配置与哪些bean有关联。

    ReloadConfigurationMonitor是一个定时任务,定时check本地配置文件是否有更新。

    当配置中心的配置被更新时,配置文件会被下载至实例本地,ReloadConfigurationMonitor即会监控到此行为,并且通知 ReloadingPropertyPlaceholderConfigurer 对相关的bean类进行值更新。

    特别的,此种方式无法解决并发情况下配置统一生效的问题。

    主备分配实现

    在实现中,为每个配置提供主备选择的概念。用户实例在获取配置前需要先进行全局唯一性竞争才能得到配置值。在这里,我们采用基于zookeeper的全局唯一性锁来实现。

    Comparisons

      淘宝Diamond[2] Disconf 比较
    数据持久性 存储在mysql上 存储在mysql上 都持久化到数据库里,都易于管理
    推拉模型 拉模型,每隔15s拉一次全量数据 基于Zookeeper的推模型,实时推送 disconf基于分布式的Zookeeper来实时推送,在稳定性、实效性、易用性上均优于diamond
    配置读写 支持实例对配置读写。支持某台实例写配置数据,并广播到其它实例上 只支持实例对配置读。通过在disconf-web上更新配置到达到广播写到所有应用实例 从目前的应用场景来看,实例对配置的写需求不是那么明显。disconf支持的中心化广播方案可能会与人性思考更加相似。
    容灾 多级容灾模式,配置数据会dump在本地,避免中心服务挂机时无法使用 多级容灾模式,优先读取本地配置文件。 双方均支持在中心服务挂机时配置实例仍然可以使用
    配置数据模型 只支持KV结构的数据,非配置文件模式 支持传统的配置文件模式(配置文件),亦支持KV结构数据(配置项) 使用配置文件的编程方式可能与程序员的编程习惯更为相似,更易于接受和使用。
    编程模型 需要将配置文件拆成多个配置项,没有明显的编程模型 在使用配置文件的基础上,提供了注解式和基于XML的两种编程模型
    并发性 多条配置要同时生效时,无法解决并发同时生效的问题




    展开全文
  • 总结Nacos配置管理操作流程 可以 做 ip hash定位使用哪台机器;每次都访问同一台机器 ,或者做共享session; 集群列表的配置文件,第3步通知的时候就是读取这里获取集群所有服务器列表 给配置文件中的集群列表发送给...
  • 配置管理口管理曙光服务器

    万次阅读 2018-04-24 17:43:00
    曙光服务器自带的管理口默认没有配置IP,需要进到BIOS中先配置管理IP,再通过管理口管理服务器。下面简单介绍如何配置管理口IP以及如何登陆管理界面。一、配置管理口IP服务器开机后,在提示界面按DEL键进入BIOS界面...
  •  配置管理(Configuration Management, CM)的目的,在使用配置识别、配置控制、配置状态记录及配置审计,来达到建立与维护工作产品的完整性。  配置管理提供了结构化的,有序化的,产品化的管理软件工程的方法...
  • 如何有效管理配置三库? 项目配置三库分别是开发库、受控库、产品库;针对三库的关系,概要总结就是:...受控库,保存已被批准的配置项(包括基线),由配置管理员管理与维护。信息分两类:受控基线和受控配置项。...
  • 项目管理中的配置管理

    千次阅读 2017-11-05 23:07:59
    配置管理的目标:为了系统地控制配置变更,在系统的整个生命周期中维持配置的完整性和可跟踪性,标识系统在不同时间点上的配置。配置管理的主要活动:制定配置管理计划、配置标识、配置控制、配置状态报告、配置审计...
  • 下面来介绍一下通过windows命令来打开SQLSERVER配置管理器。 首先:windows键+R键 各个sqlserver版本在textbox中输入对应的命令如下: SQLServerManager13.msc(对于 SQL Server 2016 ) SQLServerManager12.ms...
  • java微服务Nacos配置管理

    千次阅读 2019-07-11 11:13:37
    介绍Nacos配置管理 Nacos 提供了动态配置服务,能让我们可以实时进行服务应用的配置变更,让配置管理变得更加高效和快捷。它基于 key/value 方式存储应用配置和其他元数据信息,为分布式系统中的外部化配置提供...
  • 配置管理之三类配置库

    万次阅读 2018-02-22 15:19:13
    1 三库管理原则项目配置管理的库分为开发库、受控库、产品库。这三个库是相互独立的物理库,其中受控库在逻辑上分为配置库和基线库。1.1 开发库存放代码、脚本等开发过程中的产物。由开发人员使用。只有开发人员可...
  • 配置管理-学习笔记

    千次阅读 2018-11-06 10:47:06
    配置管理 配置管理是描述、跟踪、控制和汇报所有IT基础架构中所有设备或系统的管理流程。这些设备和系统被称为配置项,通过该管理流程实现对所有配置项的有效管理、跟踪和控制,以支持IT服务和基础设施成功运行。 ...
  • 第七章 软件配置管理

    万次阅读 2018-07-02 14:41:56
    本章内容提要软件配置管理的作用软件配置管理的相关概念建立软件配置管理环境版本控制系统集成分支管理变更管理配置审计和配置状态报告配置管理过程软件配置管理工具第一节 软件配置管理的作用星形网拓扑结构不同...
  • 随着软件系统的日益复杂化和用户需求、软件更新的频繁化,配置管理逐渐成为软件生命周期中的重要控制过程,在软件开发过程中扮演着越来越来重要的角色。一个好的配置管理过程能覆盖软件开发和维护的各个方面,同时对...
  • 配置管理系统浅析

    万次阅读 2013-06-13 21:42:29
    我们的程序常常有一些配置... 公司或者部门范围内构建统一的配置管理系统,应用通过API获取配置服务。 通过配置文件管理配置信息的方式存在一些问题,主要有: 1.部署和更新成本高 当前一个互联网服务常常部署在多台
  • [项目管理]-第十章:配置管理

    千次阅读 2019-05-24 15:36:54
    第十章:配置管理(PPT.279) 1.配置管理的概念(PPT.281) 概念:是项目管理的一项内容,主要涉及对变更进行系统地控制,建立和维护在项目的 整个软件生存周期中软件项目产品的完整性。 主要包括: 1)标识在...
  • 上一篇文章讲了 【Nacos源码之配置管理 八】客户端怎么获取服务端集群列表 ,客户端获取到集群列表缓存在内存中,是在获取配置的时候需要使用的; 因为要去服务端发起http请求获取数据; 那么我们今天来分析一下,客户端...
  • yaconf-配置管理扩展

    千次阅读 2018-08-07 11:48:09
    什么是yaconf ?  它使用单独的一个配置目录(在yaconf.directory指定), 不和代码在一起. ... 配置目录和代码分离以后, 可以借助一个配置管理后台, 来实现配置的统一化管理.  配置如果有变化, ...
  • VS配置管理

    万次阅读 2016-11-23 15:50:05
    可以在VS的配置管理器中,配置当前活动解决方案采用debug和release模式,还可以设置活动解决方案平台,即win32或x64。还可以配置整个解决方案哪些项目需要生成,哪些不用,在多项目编译时间较长的情况下还是挺有作用...
  • [项目管理] 项目管理之配置管理

    千次阅读 2013-02-05 16:40:13
    一、什么是配置管理软件配置管理是对软件修改进行标识、组织和控制的技术,用来协调和控制整个过程。是通过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的主要目标是,建立...
  • 百度分布式配置管理平台-Disconf

    千次阅读 2018-01-06 16:38:32
    Disconf专注于各种分布式系统配置管理的通用组件和通用平台, 提供统一的配置管理服务。 主要目标: 部署极其简单:同一个上线包,无须改动配置,即可在 多个环境中(RD/QA/PRODUCTION) 上线。 部署动态化:...
  • sql Server配置管理

    千次阅读 2019-02-13 20:53:03
    一个是书里的,一个是我的,对比一下 一:管理SQL Server 2008服务 开始----所有程序----Microsoft SQL Server 2008 R2----配置工具----SQL Server配置管理器    ...
  • ipmitool配置管理网络

    千次阅读 2017-09-07 17:14:27
    配置管理网络(ipmi/ilo)ipmi设置ipmitool lan set 1 ipsrc static ipmitool lan set 1 ipaddr 192.168.142.11 ipmitool lan set 1 netmask 255.255.255.0 ipmitool lan set 1 defgw ipaddr 192.168.142.254...
  • 基于zookeeper实现统一配置管理

    万次阅读 多人点赞 2017-12-07 16:47:19
    为什么要用统一配置? 我们做项目时用到的配置比如数据库配置等...我们都是写死在项目里面,如果需要更改,那么也是的修改配置文件然后再投产上去,那么问题来了,如果做集群的呢,有...那么就需要用到统一配置管理啦。
  • 项目级配置管理员的职责: 1 制定配置管理计划 2 建立并维护配置管理库 3 建立并发布基线 4 物理审计(PCA) 5 跟踪并关闭变更申请 6 报告配置状态 组织级CM的职责: 1 为项目组建立初始的配置库 2 向项目组成员...
  • 软件配置管理基线解释

    千次阅读 2017-10-28 22:48:54
    软件配置管理(Software Configuration Management,SCM) 配置(Configuration) 配置项(Configuration Item,CI) 基线(Baseline) 项目经理(Project Manager,PM) 里程碑(Milestone) 配置控制委员会...
  • 配置管理工作职责思考

    千次阅读 2016-06-30 14:07:05
    毕业刚好两年了,做配置管理差不多一年半吧。一开始的半年主要接触的质量管理工作,倒也和配置管理有些沾边。两年时间,说说现在我对配置管理的理解。等过些年再来看,期待到时有新的认识。我所理解的配置管理工作...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 250,159
精华内容 100,063
关键字:

配置管理