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

    千次阅读 2011-05-16 09:57:00
    一、概述配置管理(Configuration Management, CM)的目的,在使用配置识别、配置控制、配置状态记录及配置审计,来达到建立与维护工作产品的完整性。配置管理提供了结构化的,有序化的,产品化的管理软件工程的...

    一、概述配置管理(Configuration Management, CM)的目的,在使用配置识别、配置控制、配置状态记录及配置审计,来达到建立与维护工作产品的完整性。配置管理提供了结构化的,有序化的,产品化的管理软件工程的方法。它涵盖了软件生命周期的所有领域并影响所有数据和过程。配置管理是指用于控制系统一系列变化的学科。通过一系列技术,方法和手段来维护产品的历史,标识和定位产品独有的版本,并在产品的开发和发布阶段控制变化。通过有序管理和减少重复性工作,配置管理保证了生产的质量和效率。可以说不懂软件项目的配置管理,就不懂软件开发管理,不对软件项目进行配置管理,就没有进行软件项目开发管理。二、配置管理的基本概念 1、配置标识 IEEE中的定义:识别产品的结构、产品的构件及其类型,为其分配唯一的标识符,并以某种形式提供对它们的存取。可以理解为:标识软件系统的结构,标识独立部件(工作产品),并使它们是可访问的。配置标识的目的,是在整个生命周期中标识系统各部件并提供对软件过程及其软件产品的跟踪能力。即:怎么命名?版本如何设置?放到哪里?哪些是受控的?受控的级别是什么?读写的权限是什么? 2、配置变更控制 IEEE中的定义:通过建立产品基线,控制软件产品的发布和在整个软件生命周期中对软件产品的修改。可以理解为:软件生命周期中控制软件产品的发布和变更,目的是建立确保软件产品质量的机制。即怎么变更?谁控制变更?谁来分析变更的影响范围?变更后如何验证、入库以及恢复? 3、配置状态统计 IEEE中的定义:记录并报告构件和修改请求的状态,并收集关于产品构件的重要统计信息。可以理解为:记录和报告变更过程,目标是不间断记录所有基线项的状态和历史,并进行维护。每次基线的生成和变更都能让相关者知道变了什么?为什么变?变化前后的状态是什么? 4、配置审计 IEEE中的定义:确认产品的完整性并维护构件间的一致性,即确保产品是一个严格定义的构件集合。可以理解为:验证软件产品的构造是否符合需求、标准、或合同的要求,目的是根据配置管理的过程和程序,验证所有的软件产品已经产生并有正确标识和描述,所有阶段的工作产品都一致并满足系统的需求,并且所有的变更需求都已解决。三、配置管理计划《配置管理计划》一般是《项目综合管理计划》的子计划。在项目策划的时候我们就要制定这个计划。 1、配置管理活动的职责分配 a) 配置管理员:识别和标识配置项,建立和维护配置库;配置库管理;执行配置审计 b) 配置控制委员会(CCB):批准基线库的生成;评估和审核变更请求,并确保批准的更改得到实施. c) QA:配置管理活动审查 2、配置管理的资源 a) 配置库的服务器 b) 配置库工具 c) 配置库的访问方式 3、识别配置项对于配置项,可以给出一个比较简单的定义,即软件过程的输出信息可以分为4个主要类别: a) 计算机程序(源代码及可执行程序) b) 描述计算机程序的文档(针对技术开发者和用户) c) 数据(包含在程序内部或外部) d) 项目管理的有关文件、信息记录等在实际项目中,我们如何识别配置项? a) 《项目过程裁剪定义》中要产出的工作产品 b) 源代码、可执行程序 c) 数据(包含在程序内部或外部) d) 客户提供的文档、工具 e) 需要提交给客户的其他工作产品。 4、配置项的控制级别 IEEE中基线的定义是这样的:已经正式通过审核批准的某规约或产品,它因此可作为进一步开发的基础,并且只能通过正式的变化控制过程改变。在项目中我们一般把配置项分为3种控制级别: a) 数据项:数据项是指对变更不作控制的配置项; b) 受控项:受控项是指不需要进行基线控制但变更后需要得到相关人员确认或通知到相关人员的配置项。 c) 基线项:基线项是指需要严格执行基线变更流程的配置项。一般数据项就是我们大部分企业说的工作区。 5、配置项的标识与控制在配置库中,配置项都应该有一个合适的目录去存放和分类。放入之特定目录下的配置项也必须严格按照“文件命名规则”来命名,并且这些配置项要按照“版本设置规则”来标识版本。在配置库中各种配置项的操作权限都应严格管理。我们一般是通过目录的访问权限来控制的,所以配置库的目录结构与配置项的访问权限也有着密切的关系,配置项的权限设置的原则如下: a) 基线配置项:只有配置管理员有写的权限,项目组全员开放读的权限。 b) 受控配置项:PM、CCB读写权限,项目组全员或相关人员开放读的权限。 c) 数据配置项:PM、CCB、配置项的责任人或开发小组开放读写权限,项目组全员开放读的权限。 7、基线计划在配置管理中基线发布是一个重要活动,基线发布的时间点一般就是项目里程碑时间点。通常会有下列基线:需求基线、设计基线、代码基线、交付基线等。在计划中我们要依据《项目综合管理计划》的里程碑时间点,结合项目管理的需要,设定项目的基线计划。即项目过程中发布哪些基线,这些基线发布的时间点,发布的责任人。同时我们也要明确定义基线的版本规则,因为基线也是在不断变更的。 8、配置审计计划配置审计的时机: a) 一般基线发布前对要进入基线的配置项进行配置审计。 b) 如果2条基线的发布时长超过2个月时,应该在时间2个基线发布中适当安排配置审计,建议是1个月1次。 c) 产品交付前必须要进行配置审计。我们在计划中要规划好配置审计的概要时间。这样有利于配置审计的及时开展。 9、配置管理计划定义各类配置项如库、出库的准则和操作流程。定义基线变更的准则和操作流程。明确配置库的备份及维护的方法,当出现异常后如何恢复的预案等。版本发布的准则、发布流程及发布计划,如测试版本、β版本、Release版本等。四、配置管理的主要活动 1、配置状态报告配置状态报告是一个配置管理中一个很重要的活动,多个开发组保持开发一致的重要活动。我们的配置状态报告的主要对象是基线库。配置状态报告要报告的内容有:基线库的基线项的清单、基线项的名称、版本、存放位置。在每次基线变更后,状态报告还要能说明。哪些基线项变了、为什么变、变化前的版本是什么、变化后的版本是什么。 2、基线变更流程一般项目管理中,基线变更的控制权限是CCB(配置变更委员会)。基线变更控制一般是由两种变更方式,需求变更、内部变更。下图是基线变更的流程。 3、配置审计在CMMI模型中明确将配置审计分为物理审计和功能审计,在定义中与IEEE是没有冲突的。在CMMI模型中对物理审计和功能审计的定义如下: a) 物理审计:验证已构建出的配置项符合定义和描述它的技术文档的审计行为。 b) 功能审计:验证配置项的开发已经被完全满足的审计行为,即验证配置项已经达到了在功能或已分配的配置标识中刻画的性能和功能特性,并且其运行和支持文档是完整的和满意的。配置审计的范围:物理审计的范围是受控项和基线项,功能审计的范围是基线项。功能审计是验收的前提条件,不同的角色所做的功能审计侧重点不同。配置审计的步骤: a) 准备《配置审计检查单》,这个检查单包含所有受控项和基线项的状态,受控项清单包含受控项的命名、控制级别、存放位置、当前版本、控制权限等状态信息。基线项的状态就是最新的《配置状态报告》中配置项的状态。 b) 依据配置审计的计划时间去执行配置审计。 c) 根据《配置审计检查单》对配置库进行物理审计。责任人:CM发起并参与、CCB。 d) 根据《配置审计检查单》对配置库进行功能审计。责任人:CM发起并参与、需求人员、CCB(PM、及各Leader)及相关人员。 e) QA监督配置审计是否按照标准流程来进行,并记录不一致问题。 f) 每次配置审计要将审计结果记录到《配置审计报告》中,记录和跟踪配置审计检查出的问题。物理审计的方法:根据《配置审计检查单》去检查,该有的配置项是否都有了?文件命名与计划中的命名规则是否一致?存放位置与计划是否一致?版本设置与计划中的版本设置规则是否一致?控制权限是正确?功能审计的方法: a) 检查与需求的一致性、完整性:根据《需求追踪矩阵》对配置库的基线项进行检查,看看所有需求是否都已经不多不少地被实现了?并纳入了基线库?如果物理审计中基线项的审计没有问题,我们也可以通过《需求追踪矩阵》对《配置状态报告》中基线项进行检查,看看所有需求是否都已经不多不少地被实现了? b) 验证工作产品与需求的符合程度:查看所有基线项评审和测试报告,看看所有的基线项是否都已经通过各级评审及测试? c) 交付给客户的文档与软件的功能一致性:检查交付客户的文档是否与当前最新的基线中的需求一致? 4、配置管理活动的QA审查配置管理过程的审查:确保配置管理的记录和配置项是完整的、一致的和准确的审查行为,客观评价管理过程与其过程描述、标准和规程的符合性并处理不一致问题。配置管理活动的QA检查时机:定期检查配置管理工作,依据基线和配置审计计划检查这些基线的建立变更及配置审计活动。检查内容: a) 检查配置管理的各种记录、报告等与配置库中的物理的配置项实体是否一致、完整、准确 b) 是否每次新建和变更基线都有完整的申请记录 c) 每次基线新建和变更的审核流程是否执行并有记录 d) 基线库中的产品是否经过了功能审计 e) 每次配置审计的问题是否都被跟踪直到关闭 f) 配置库的权限是否都是正确分配的 g) 配置库的目录结构是否都与《配置管理计划》一致 本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/tomfshao/archive/2008/07/11/2638626.aspx

    展开全文
  • 微服务架构的实现首先需要提供一些基础组件,这些基础的功能性组件主要包括服务之间的通信、面向事件驱动的架构设计方法、负载均衡、服务路由、API网关和分布式配置中心等,我们对这六大基本组件进行初步的分析定案...

    微服务架构的实现首先需要提供一些基础组件,这些基础的功能性组件主要包括服务之间的通信、面向事件驱动的架构设计方法、负载均衡、服务路由、API网关和分布式配置中心等,我们对这六大基本组件进行初步的分析定案。

    一、服务通信:网络连接+IO模型+可靠性+同步与异步

    对于微服务而言,网络通信主要关注于网络连接、IO模型、可靠性设计及服务调用方式。

    1.网络连接

    一般,基于TCP网络连接有两种基本方式,也就是我们常说的长连接和短连接,连接的建立需要三次握手,释放需要四次握手,而每次连接都意味着资源和时间的消耗。

    三次建立握手示意图如下:            

    注:1.TCP规定,SYN报文段(SYN=1的报文段)不能携带数据,但需要消耗掉一个序号。

           2.TCP规定,ACK报文段可以携带数据,但是如果不携带数据则不消耗序号。

    四次释放握手示意图如下:

    注:1. TCP规定,FIN报文段即使不携带数据,也要消耗一个序号。

           2.服务器结束TCP连接的时间要比客户端早一些。

    而且,一般短连接只会在客户端/服务器端间传递一次读写操作,存在的连接都是有用的连接,不需要额外的控制手段。而长连接则与其不同,当客户端与服务端完成一次读写操作后他们的连接不会主动关闭,用于后续的读写操作。

    注意,长连接和短连接的产生在于客户端和服务端所采取的关闭策略,具体的应用场景采用何种策略需要依据情况具体分析,没有十全十美的选择,只有合适的选择。

    2.IO模型

    现代操作系统都包括内核空间和用户空间,其中,内核空间主要存放内核代码和数据,供系统进程使用,用户空间主要存放用户代码和数据,是供用户进程使用。

    一般,IO操作都有类似如下两个阶段,第一阶段,当数据分组到来时,将其拷贝到内核空间的临时缓存区,第二个阶段,再将内存空间临时缓存区中的数据复制到用户空间缓存区。围绕着这两个阶段,存在这一下几种主流的IO操作模式:

    阻塞IO:所有的套接口都是阻塞的,意味着IO的发起和结束都需等待,任何一个系统调用都会产生一个由用户态到内核态切换,在从内核态到用户态的一个切换过程,而进程的上下文切换也是通过系统中断程序来实现的,需要保存当前进程的上下文,这是一个成本很高的过程。

    非阻塞IO:把套接口设置成非阻塞时,用户进程会不停的询问某种操作是否准备就绪,轮询方式,这是种比较浪费CPU的方式。

    IO复用:主要依赖于操作系统提供的select和poll机制,这是阻塞进程是在这两个系统调用上,不在真正的IO操作上,IO操作看起来复用阻塞了两次,但是第一次阻塞是在select上监控多个套接口是否已有IO操作准备就绪,加大了性能指标。

    信号驱动IO:通过sigaction系统调用注册一个信号处理程序,主程序可以继续向下执行,当所监控的套接口有IO操作准备就绪的时候,由内核触发通知前面的注册信号处理程序执行,将数据从内核空间复制到用户空间。

    异步IO:与信号驱动IO的区别是直接由内核告诉IO操作何时完成了。

    可以看到,前四种IO模型的主要区别是在第一阶段,因为它们第二阶段都是在阻塞等待数据由内核空间复制到用户空间;而异步IO在第一阶段和第二阶段都不会阻塞。

    3.可靠性

    常见的网络通信保障手段包括链路有效性检测以及断线以后的重连处理。

    (1)链路有效性检测

    要确保通信链路的可靠性就必须对链路进行周期性的有效性检测,通用的做法就是心跳检测,通常有两种技术实现方式:

    一种是在TCP层通过建立长连接在发送端和接收端之间传递心跳信息;

    另一种则是在应用层,心跳信息根据系统要求可能包含一定的业务逻辑。

    (2)重连处理

    当发送方检测到通信链路中断,会在事先约定好的重连间隔时间之后发起重连操作,如果重连失败,则周期性地使用该间隔时间进行重连直至重连成功。

    4.同步与异步

    通信中的两种基本方式,一种是请求应答模式的同步操作,一种是单向模式的异步操作。

    同步调用会造成业务线程阻塞,但开发和管理相对简单。

    异步调用的目的在于获取高性能,队列思想和事件驱动都是实现异步调用的常见策略,但都主要依赖于基础中间件平台。JDK也为我们提供了Future模式实现异步调用。

    Future模式调用可以进一步分为两种模式,Future-Get模式和Future-Listener模式,Future-Get模式通过主动get方式获取Future结果,但是get过程是串行的,会造成执行get方法的线程形成阻塞,Future-Listener模式中需要创建Listener,当Future结果生成时唤醒注册该Future上的Listener对象,从而形成异步回调机制。

    二、事件驱动:基本事件驱动架构+事件驱动架构与领域模型

    1.基本事件驱动架构

    基本事件驱动处理架构的优势在于当系统中需要添加另一个业务逻辑来完成整体流程时,只需要对该事件添加一个订阅者即可,不需要对原系统做任何修改。

    以下系统进行分析:

    如图,一个订单处理的基本场景中需要预约订单处理系统同时知道支付、物流和账单服务,并进行服务的调用和协调,完成业务的闭环,但是,如果当系统业务进行变更后,需要一个新的服务才能完成所需要的业务流程,那么原有交互模式就需要进行调整,不利用系统扩展。

    如果我们采用事件驱动架构来实现的话,当一个订单操作完成时,订单系统就可以发送一个事件用于表示这个操作已完成,并触发所有对该事件感兴趣的微服务,这些微服务相当于这个事件的订阅者和消费者,这样一来,一个微服务可以处理支付,一个微服务处理物流,另一个微服务则处理账单,三个事件通过事件进行了解耦,通过消息传递机制,不必花费太大代价就能实现事件驱动架构。

    2.事件驱动与领域模型

    如图,一种领域事件框架围绕领域事件生命周期给出了三种不同的处理方式,体现在不同是事件订阅者。

    简单订阅者:直接处理事件,表现为一个独立的事件处理程序,对应于事件的使用阶段。

    即时转发订阅者:对应于事件的分发和使用阶段,一方面可以具备简单订阅者的功能,另一方面也可以把事件转发给其他订阅者(消息队列是一个较好地实践方法)。

    事件存储订阅者:在处理事件的同时对事件进行持久化,存储的事件可以作为一种历史记录,也可以通过专门的事件转发器转发到消息队列,对应于事件的存车使用阶段。

    如下图,在架构设计上,对领域事件的处理就是基本的发布-订阅风格。

    其中,DomainEvent本身具备一定的类型,DomainEventSubscriber根据类型订阅某种特定的DomainEvent,领域对象间的交互图一般如下:

    应用层AplicationService对某个实体对象进行操作会触发领域事件的生成,领域事件通过DomainEventPublisher进行发布,DomainEventSubscriber则根据需要由AplicationService创建并根据事件类型进行订阅和处理。

    而包含事件存储的发布订阅时序图一般如下,针对远程交互本身存在的网络稳定性等各种不可控原因会对事件进行存储以便发生问题时跟踪和重试。支持不同事件冲突、支持领域事件和存储事件之间的转换、检索由领域模型所产生的所有结果的历史记录、使用事件存储中的数据进行业务预测和分析是常见的事件存储需求。

    三、负载均衡:服务端负载均衡+客户端负载均衡+负载均衡算法

    从横向拆分角度讲,分布式是指将不同的业务分布在不同的地方,而集群指的是将几台服务器集中在一起实现同一业务。分布式中的每一个节点都可以做集群,但集群并不一定是分布式的。

    集群概念的提出同时考虑到了分布式系统中性能和可用性的问题,一方面,集群的负载均衡机制可以将业务请求分摊到多台单机性能不一定出众的服务器,另一方面,集群的容错机制确保当集群中的某台机器无法正常提供服务时整体集群仍然可用。而负载均衡简单讲就是将请求分摊到多个操作单元上进行执行。

    负载均衡建立在现有网络结构上,提供了一种廉价、有效、透明的方法扩展服务器的带宽、增加吞吐量、加强网络数据处理能力,以及提高网络的灵活性。以各种负载均衡算法为基础的分发策略决定了负载均衡的效果,根据服务器地址列表所存放的位置可以分为两大类,一类是服务器负载均衡,另一类是客服端负载均衡。

    1.服务端负载均衡

    客户端发送请求到负载均衡器LB,负载均衡器负责将接收到的各个请求转发到运行中的某台服务节点上,然后接收到请求的微服务做响应处理,常见的有Apache、Nginx、HAProxy。

    其实现机制比较忙简单,只需要在客服端与各个微服务实例之间架设集中式的负载均衡器即可,负载均衡器动态获取各个微服务运行时的信息,决定负载均衡的目标服务,若负载均衡器检测到某个服务已经不可用的时候就会自动移除该服务。

    注意,负载均衡器运行在一台独立的服务器上并充当代理的作用,同时,需要注意的是当服务请求越来越大的时候,负载均衡器就会成为系统的瓶颈,同时若负载均衡器自身发生失败时,整体服务的调用都将发生失败。

    2.客户端负载均衡

    客户端负载均衡机制的主要优势就是不会出现集中式负载均均衡所产生的瓶颈问题,因为每个客户端都有自己的负载均衡器,负载均衡器失败也不会造成严重的后果,但是运行时的信息在多个负载均衡器之间进行服务配置信息的传递会在一定程度上加重网络流量负载。              

    实现上,需要在客服端程序里面自己设定一个调度算法,在向服务器发起请求的时候,先执行调度算法计算出目标服务器地址,具体与原理如下图分析:

    其另一种典型的实现方式是把Nginx等能够实现代理功能的负载服务器部署到运行微服务的一台机器上。这时需要考虑实施成本和维护性问题。

    客户端负载均衡比较适合于客户端具有成熟的调度库函数、算法以及API的工具和框架。

    3.负载均衡算法

    大致可以分为两大类,即静态负载均衡算法和动态负载均衡算法。

    (1)静态负载均衡算法

    主要指的是各种随机算法和轮询算法。

    轮询算法:将请求按顺序轮流地分配到后端服务器上,它均衡地对待后端的每一台服务器,而不关心服务器实际的连接数和当前的系统负载。

    随机算法:通过系统的随机算法,根据后端服务器的列表大小值来随机选取其中的一台服务器进行访问。由概率统计理论可以得知,随着客户端调用服务端的次数增多,其实际效果越来越接近于平均分配调用量到后端的每一台服务器,也就是轮询的结果。

    加权轮询算法:不同的后端服务器可能机器的配置和当前系统的负载并不相同,因此它们的抗压能力也不相同。给配置高、负载低的机器配置更高的权重,让其处理更多的请;而配置低、负载高的机器,给其分配较低的权重,降低其系统负载,加权轮询能很好地处理这一问题,并将请求顺序且按照权重分配到后端。

    (2)动态负载均衡算法

    根据服务器的实时性能分配连接是常见的动态策略。所有涉及权重的静态算法都可以转变为动态算法。常见的有以下几种:

    最小连接数算法:比较灵活和智能,由于后端服务器的配置不尽相同,对于请求的处理有快有慢,它是根据后端服务器当前的连接情况,动态地选取其中当前积压连接数最少的一台服务器来处理当前的请求,尽可能地提高后端服务的利用效率,将负责合理地分流到每一台服务器。

    源地址哈希算法:根据获取客户端的IP地址,通过哈希函数计算得到的一个数值,用该数值对服务器列表的大小进行取模运算,得到的结果便是客服端要访问服务器的序号。采用源地址哈希法进行负载均衡,同一IP地址的客户端,当后端服务器列表不变时,它每次都会映射到同一台后端服务器进行访问。

    四、服务路由:直接路由+间接路由+路由规则

    负载均衡的出发点是提供服务分发而不是解决路由问题,常见的静态、动态负载均衡算法也无法实现精细化的路由管理,但是负载均衡也可以简单看做是路由方案的一种。服务路由的管理可归纳为三大类,直接路由、间接路由和路由规则。路由策略整体如下:

    1.直接路由

    服务消费者需要感知服务提供者的地址信息,基本思路是通过配置中心或者数据库,当服务消费者需要调用某个服务时,基于配置中心或者数据库中存储的目标服务的具体地址构建链路完成调用。

    存在的问题:(1)增强了服务提供者和消费者之间的耦合度;

                         (2)创建和维护配置中心或数据库持久化操作需要成本。

    2.间接路由

    强调解耦思想并充分利用了发布-订阅模式作用,发布者发布事件,订阅者关注自身所想关注的事件,发布者和订阅者并不需要感知对方的存在,两者之间通过传输事件的基础设施进行完全解耦。

    在为微服务架构里面,实现间接路由的组件一般称为服务注册中心,从概念上讲就是发布-订阅模式中传输事件的基础设施,可以把服务的地址信息理解为事件的具体表现。通过服务注册中心,服务提供者发布服务到注册中心,服务消费者订阅感兴趣的服务,服务消费者只需要知道有哪些服务,而不需要知道服务具体在什么位置,从而实现间接路由。

    3.路由规则

    间接路由解决了路由解耦问题,面向全路由场景。但是在服务故障、高峰期导流、业务相关定制路由等特定场景下,依靠间接路由提供静态路由信息并不能满足要求,这就需要动态路由,而动态路由规则需要通过路由规则进行实现。

    路由规则常见的实现方案是白名单和黑名单,即把需要路由的服务地址信息放入到可以控制是否可见的路由池中。更为复杂的可以用Python等脚本语言实现定制化。

    五、API网关:网关的作用+网关的功能

    在设计模式中,外观模式的设计意图在于为子系统中的一组接口提供一个一致的入口,这个入口使得这一子系统更加容易使用,实现上用户界面不与系统耦合,而外观类与系统耦合。在层次化结构中,可以使用外观模式定义系统中的每一层的入口。

    外观模式:封装许多对象,以简化它们的接口,此模式定义了一个高层的接口,这个接口使得这一子系统更加容易使用,如下图:

    API网关本质上就是一种外观模式的具体实现,它是一种服务器端应用程序并作为系统访问的唯一入口。在微服务架构中,API网关的核心要点是,所有的客户端和消费端都通过统一的网关接入微服务,在网关层处理所有的非业务功能。

    1.网关的作用:解耦+API优化+简化调用过程

    微服务提供的API粒度与客户端的要求不一定完全匹配,微服务一般提供细粒度的API,这意味着客户端通常需要与多个服务进行交互,网关要起到客户端与微服务间的隔离作用,随着业务需求的变化和时间的演进,网关背后的各个微服务的划分和实现可能需要做相应的调整和升级,这种调整和升级要求对客户端透明。

    API网关的作用主要体现在以下三个方面:

    (1)解耦:API网关使客户端和服务器端在调用关系和部署环境上进行解耦,向客户端隐藏了应用如何被划分到微服务的细节。

    (2)API优化:要求对每个客户端提供最优的API,在多客户端场景中,对于同一个业务请求,不同的客户端一般需要不同的数据。

    (3)简化调用过程:可以对返回数据进行处理,API网关减少了请求往返的次数,从而简化客户端的调用,提高服务访问的性能。

    但是需要注意的是,API网关也增加了系统的复杂性和响应时间,通过API网关也多了一层网络跳转,但是我们认为API网关模式的缺点相比优点是微不足道的。

    2.网关的功能

    网关的基本功能基本包含五点,具体细分如下图:

    功能1-NIO接入和异步接出:由于API网关作为客户端和微服务之间提供了桥梁,增加了一层网络跳转,为了解决网络跳转带来的性能影响,在实现上需要提供NIO接入和异步接出功能。

    功能2-报文格式转换:API网关作为单一入口,可构建异构系统,通过协议转换整合后基于REST、AMQP和Dubbo等不同风格和实现技术的微服务。

    功能3-安全性控制:API网关是统一管理安全性的绝佳场所,可以将认证的部分抽离到网关层,然后微服务系统无需关注认证的逻辑只关注自身业务即可。

    功能4-访问控制:需要控制客户端的访问次数和访问频率等功能。

    功能5-业务路由支持:可在网关层制定灵活的路由策略,对于特定API可设置白名单、路由规则等限制,非业务功能的配置及变更在网关层单独操作。

    六、配置管理:配置中心模型+分布式协调机制

    在微服务架构中,一般都需要引入配置中心的设计思想和相关工具。

    1.配置中心模型:4大分类+4个核心需求+2个维度分析

    4大分类

    先来梳理下配置相关的内容和分类:

    按配置的来源划分:源代码文件、数据库和远程调用。

    按配置的适用环境划分:开发环境、测试环境、预发布环境、生产环境等。

    按配置的集成阶段划分:编译时---源代码级的配置+配置文件和源代码一起提交到代码仓库;

                                           打包时---通过某种方式将配置打入最终的应用包中;

                                           运行时---应用启动时并不知道具体配置,需从本地或远程获取配置,在正常启动。

    按配置的加载方式划分:单次加载型配置、动态加载型配置。

    4个核心需求

    依照配置相关的内容和分类来看,构建一个合适的配置中心,至少需要满足以下4个核心需求:

    (1)非开发环境下应用配置的保密性,避免将关键配置写入源代码;

    (2)不同部署环境下应用配置的隔离性,比如非生产环境的配置不能参与生产环境;

    (3)同一部署环境下的服务器应用配置的一致性,即所有服务器使用同一份配置;

    (4)分布式环境下应用配置的可管理性,即提供远程配置能力。

    2个维度分析

    采取配置中心也就意味着采用集中式配置管理的设计思想。

    维度一:在集中式配置中心中,开发、测试和生产等不同环境配置信息统一保存在配置中心中;

    维度二;分布式集群环境,需要确保集群中同一类服务的所有服务器保存同一份配置文件并且能够同步更新。

    2.分布式协调机制

    配置中心在实现上需要满足3大需求:高效获取、实时感知、分布式访问。为满足这三大需求,配置中心需要依赖分布式协调机制,即通过一定的方法确保配置信息在分布式环境中的各个服务中能够得到实时、一致管理。目前业界主流的分布式协调框架为Zookeeper。         

    相关Zookeeper内容参考链接:http://www.cnblogs.com/wuxl360/p/5817471.html .                   

     

    参考书籍、文献和资料:

    【1】https://blog.csdn.net/qzcsu/article/details/72861891.

    【2】郑天民. 微服务设计原理与架构. 北京:人民邮电出版社,2018.

    【3】https://blog.csdn.net/youanyyou/article/details/78990133.

    【4】https://blog.csdn.net/wind19/article/details/7373010.

    【5】http://www.cnblogs.com/wuxl360/p/5817471.html.

    展开全文
  • SpringCloud 入门教程(二): 配置管理

    万次阅读 2019-01-16 11:53:26
    使用Config Server,您可以在所有环境中管理应用程序的外部属性。...随着应用程序通过从开发人员到测试和生产的部署流程,您可以管理这些环境之间的配置,并确定应用程序具有迁移时需要运行的一切。服务器存储后端的...

    使用Config Server,您可以在所有环境中管理应用程序的外部属性。客户端和服务器上的概念映射与Spring EnvironmentPropertySource抽象相同,因此它们与Spring应用程序非常契合,但可以与任何以任何语言运行的应用程序一起使用。随着应用程序通过从开发人员到测试和生产的部署流程,您可以管理这些环境之间的配置,并确定应用程序具有迁移时需要运行的一切。服务器存储后端的默认实现使用git,因此它轻松支持标签版本的配置环境,以及可以访问用于管理内容的各种工具。很容易添加替代实现,并使用Spring配置将其插入

    以上是Spring Cloud官网对配置服务的描述, 简单阐述一下我的理解。比如我们要搭建一个网站,需要配置数据库连接,指定数据库服务器的IP地址,数据库名称,用户名和口令等信息。通常的方法, 我们可以在一个配置文件中定义这些信息,或者开发一个页面专门配置这些东西。只有一个web服务器的时候, 很方便。

    但假如需要搭建同多台服务器时,当然可以每台服务器做同样配置,但维护和同步会很麻烦。我理解的配置服务至少有两种不同场景:

    1).  多个客户使用同一配置: 比如,多台服务器组成的集群,假如后端使用同一数据库,那么每台服务器都是用相同的配置。

    2).  不同客户使用不同的配置: 比如典型的场景是,开发,测试,生产使用相同的系统,但使用不同的数据库

    如果有个统一的根本配置,是不是就很方便,一个可行的办法是,把这些配置文件放到一个共享存储(比如网络共享盘)中。这样只需要在共享存储修改一个或多个配置文件就可以了。但共享文件的方式受到具体布署环境的限制,很多时候很难达到多台Web服务器共享同一个存储硬盘。

    共享盘的缺点是资源定位比较困难,Spring Cloud的解决方案是, 将这些配置文件放到版本管理服务器里面,Spring Cloud缺省配置使用GIT中。所有Web服务均从GIT中获取这些配置文件。由于GIT服务器与具体Web服务器之间不需要共享存储, 只要网络可达就行,从而可以实现Web服务于配置信息的存放位置的解耦。

    Spring Cloud统一控制应用和GIT服务的交互,应用只需要按照Spring Cloud的规范配置GIT的URL即可。 使用GIT后,场景2和场景1的区别仅仅是,场景2中不同的client使用不同版本的配置文件,但应用但访问的文件看起来是会是同一个。Spring Cloud的配置服务结构入下图

    下面我们继续上一节的例子Spring Cloud 入门之一. 服务注册 继续展开, 让“Hello World”从配置文件helloworld.properties读出,内容格式如下

    hello=Hello World

    其中关键字hello的值“Hello World”,就是我们要输出的内容。

    一. 创建config Server

     1.  创建Config Server, maven工程里面配置spring-cloud-config-server

    <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-config-server</artifactId>
    </dependency>

    完整配置如下:

    1 <?xml version="1.0" encoding="UTF-8"?>
     2 <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
     3     xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
     4   <modelVersion>4.0.0</modelVersion>
     5   <groupId>com.chry</groupId>
     6   <artifactId>springcloud.helloworld.config.server</artifactId>
     7   <version>0.0.1-SNAPSHOT</version>
     8   <packaging>jar</packaging>
     9   <name>helloworld.config.server</name>
    10   <description>Demo Config Server</description>
    11 
    12     <parent>
    13         <groupId>org.springframework.boot</groupId>
    14         <artifactId>spring-boot-starter-parent</artifactId>
    15         <version>1.5.3.RELEASE</version>
    16         <relativePath/> <!-- lookup parent from repository -->
    17     </parent>
    18 
    19     <properties>
    20         <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    21         <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
    22         <java.version>1.8</java.version>
    23     </properties>
    24 
    25     <dependencies>
    26         <!--eureka server -->
    27         <dependency>
    28             <groupId>org.springframework.cloud</groupId>
    29             <artifactId>spring-cloud-starter-eureka</artifactId>
    30         </dependency>
    31         <dependency>
    32             <groupId>org.springframework.cloud</groupId>
    33             <artifactId>spring-cloud-starter-eureka-server</artifactId>
    34         </dependency>
    35         <dependency>
    36             <groupId>org.springframework.cloud</groupId>
    37             <artifactId>spring-cloud-config-server</artifactId>
    38         </dependency>
    39         <!-- spring boot test-->
    40         <dependency>
    41             <groupId>org.springframework.boot</groupId>
    42             <artifactId>spring-boot-starter-test</artifactId>
    43             <scope>test</scope>
    44         </dependency>
    45     </dependencies>
    46 
    47     <dependencyManagement>
    48         <dependencies>
    49             <dependency>
    50                 <groupId>org.springframework.cloud</groupId>
    51                 <artifactId>spring-cloud-dependencies</artifactId>
    52                 <version>Dalston.RC1</version>
    53                 <type>pom</type>
    54                 <scope>import</scope>
    55             </dependency>
    56         </dependencies>
    57     </dependencyManagement>
    58 
    59     <build>
    60         <plugins>
    61             <plugin>
    62                 <groupId>org.springframework.boot</groupId>
    63                 <artifactId>spring-boot-maven-plugin</artifactId>
    64             </plugin>
    65         </plugins>
    66     </build>
    67 
    68     <repositories>
    69         <repository>
    70             <id>spring-milestones</id>
    71             <name>Spring Milestones</name>
    72             <url>https://repo.spring.io/milestone</url>
    73             <snapshots>
    74                 <enabled>false</enabled>
    75             </snapshots>
    76         </repository>
    77     </repositories>
    78 
    79 </project>

    2. 创建Config Server,它也是一个Spring Boot应用,@EnableConfigServer注解说明了一个Config Server。同样我们使用@EnableEurekaClient将它注册到服务中心。

     1 package springcloud.helloworld.config.server;
     2 
     3 import org.springframework.boot.SpringApplication;
     4 import org.springframework.boot.autoconfigure.SpringBootApplication;
     5 import org.springframework.cloud.config.server.EnableConfigServer;
     6 import org.springframework.cloud.netflix.eureka.server.EnableEurekaServer;
     7 
     8 @EnableEurekaServer
     9 @EnableConfigServer
    10 @SpringBootApplication
    11 public class ConfigServerApplication {
    12     public static void main(String[] args) {
    13         SpringApplication.run(ConfigServerApplication.class, args);
    14     }
    15 }

    3. Config server的配置文件appication.yml , 注意配置文件的url是GIT服务器的仓库地址, searchPaths配置文件所在的文件夹在仓库中的路径, 在server端不需要指定具体配置文件名, 因为具体的配置文件是什么有应用(也就是client)决定。

    eureka:
      client:
        serviceUrl:
          defaultZone: http://localhost:8761/eureka/
    server:
      port: 8888
    
    spring:
      cloud:
        config:
          server:
            git:
              uri: https://git.oschina.net/chrywhy/test
              searchPaths: spring-cloud/helloworldConfig
      application:
        name: config-server

    4. 启动config server后,访问http://localhost:8888/abc/xyz, 可见如下响应。这个是输出是并没有包括具体配置文件的内容, 这个响应说明,config server可以正常访问我们配置在application.yml中的GIT服务

    这个URL是啥意思, 需要解释一下。我们从输出就可以看到 abc 就是application的名字,xyz是profile的名字, 注意这里的abc, xyz均是随便输入的名字, 并不需要真实存在,config server这个REST接口返回的只是应用名为abc, profile名为xyz时,GIT配置环境的结构。

    config server提供的REST接口,Spring Cloud官方文档提供了几个可选URL可以是如下几个:

    1. /{application}/{profile}[/{label}]
    2. /{application}-{profile}.yml
    3. /{label}/{application}-{profile}.yml
    4. /{application}-{profile}.properties
    5. /{label}/{application}-{profile}.properties

    比如 第三个格式,如果我们在GIT版本库中有一个配置文件 spring-cloud/helloworldConfig/config-client-dev.properties. 那么访问http://localhost:8888/config-client-dev.properties就可以显示配置文件内容。这个例子中, application的名字是"config-client"(也是下面我们即将创建的client), profile名字是dev, 文件后缀是.properties

    本例由于配置了eureka服务中心,所以这个config server作为一个eureka client注册到了 eureka server中, 可以从http://localhost:8761看到我们启动的config server, 如果不需要注册到服务中心, 也可把这个配置去掉

     二. 创建config client

    1.  创建maven工程, pom.xml如下:
    
    1 <?xml version="1.0" encoding="UTF-8"?>
     2 <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
     3     <modelVersion>4.0.0</modelVersion>
     4     <groupId>com.chry</groupId>
     5     <artifactId>Springcloud.helloworld.config.client</artifactId>
     6     <version>0.0.1-SNAPSHOT</version>
     7     <name>Springcloud.helloworld.config.client</name>
     8     <packaging>jar</packaging>
     9     <description>Demo Spring Config Client</description>
    10 
    11     <parent>
    12         <groupId>org.springframework.boot</groupId>
    13         <artifactId>spring-boot-starter-parent</artifactId>
    14         <version>1.5.3.RELEASE</version>
    15         <relativePath/> <!-- lookup parent from repository -->
    16     </parent>
    17 
    18     <properties>
    19         <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    20         <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
    21         <java.version>1.8</java.version>
    22     </properties>
    23 
    24     <dependencies>
    25         <dependency>
    26             <groupId>org.springframework.cloud</groupId>
    27             <artifactId>spring-cloud-starter-eureka</artifactId>
    28         </dependency>
    29         <dependency>
    30             <groupId>org.springframework.boot</groupId>
    31             <artifactId>spring-boot-starter-web</artifactId>
    32         </dependency>
    33         <dependency>
    34             <groupId>org.springframework.cloud</groupId>
    35             <artifactId>spring-cloud-starter-config</artifactId>
    36         </dependency>
    37         <dependency>
    38             <groupId>org.springframework.boot</groupId>
    39             <artifactId>spring-boot-starter-test</artifactId>
    40             <scope>test</scope>
    41         </dependency>
    42     </dependencies>
    43 
    44     <dependencyManagement>
    45         <dependencies>
    46             <dependency>
    47                 <groupId>org.springframework.cloud</groupId>
    48                 <artifactId>spring-cloud-dependencies</artifactId>
    49                 <version>Dalston.RC1</version>
    50                 <type>pom</type>
    51                 <scope>import</scope>
    52             </dependency>
    53         </dependencies>
    54     </dependencyManagement>
    55 
    56     <build>
    57         <plugins>
    58             <plugin>
    59                 <groupId>org.springframework.boot</groupId>
    60                 <artifactId>spring-boot-maven-plugin</artifactId>
    61             </plugin>
    62         </plugins>
    63     </build>
    64 
    65     <repositories>
    66         <repository>
    67             <id>spring-milestones</id>
    68             <name>Spring Milestones</name>
    69             <url>https://repo.spring.io/milestone</url>
    70             <snapshots>
    71                 <enabled>false</enabled>
    72             </snapshots>
    73         </repository>
    74     </repositories>
    75 
    76 
    77 </project>

    2. 创建一个spring boot应用作为client

     1 package springcloud.helloworld.config.client;
     2 
     3 import org.springframework.beans.factory.annotation.Value;
     4 import org.springframework.boot.SpringApplication;
     5 import org.springframework.boot.autoconfigure.SpringBootApplication;
     6 import org.springframework.web.bind.annotation.RequestMapping;
     7 import org.springframework.web.bind.annotation.RestController;
     8 
     9 @SpringBootApplication
    10 @RestController
    11 public class ConfigClientApplication {
    12 
    13     public static void main(String[] args) {
    14         SpringApplication.run(ConfigClientApplication.class, args);
    15     }
    16 
    17     @Value("${hello}")
    18     String hello;
    19     @RequestMapping(value = "/hello")
    20     public String hello(){
    21         return hello;
    22     }
    23 }

    这个应用非常简单,就是从Config Server中获取配置项hello的值,Client Server向Config Server提交REST请求后,Config Server将访问GIT服务器,并将取得的配置项hello的值返回给client.

    3. Config client需要一个应用配置文件, 定义config Server的URL,以及要访问的GIT具体分支。这个配置文件是bootstrap.yml (或者bootstrap.properties)

     1 spring:
     2   application:
     3     name: config-client
     4   cloud:
     5     config:
     6       label: master
     7       profile: dev
     8       uri: http://localhost:8888/
     9 server:
    10   port: 8881

    这个配置定义了应用的名字是config-client(这就是将要用于组装前面Config Server一节中题到的application), profile采用dev, GIT分支用master。url是config server的地址。那么问题来了,我们似乎没定义配置文件名, 那配置文件名是什么呢? 这点又体现了约定优于配置的思路, 这里Spring Cloud约定, 应用的配置文件名以如下方式组成:{application}-{profile}.properties(或者{application}-{profile}.yml)。比如我们这个应用的配置文件就是config-client-dev.properties. 所以只需要在GIT的中创建配置文件spring-cloud/helloworldConfig/config-client-dev.properties就可以了, 内容如下:

    hello=Hello World from GIT

     4. 启动config-client应用后, 可以访问http://locahost/8881/hello, 可以看到,应用本身并没有直接配置hello的具体内容, 也没指定具体配置文件,所欲这些都由spring cloud框架提交给config server了。

     

    5.  配置的更新

    至此,spring cloud的配置管理简单示例已经完成,但client 不能自动感知服务端的变化。 比如,我们修改了GIT中的文件内容,但无论如何刷新client端的页面,都不能反映配置的变化。下一节介绍Spring Cloud的配置自动更新机制

     

     

     

    博客:http://www.cnblogs.com/chry/p/7250584.html

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

    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了。要获得她的批准。

    展开全文
  • 总结Nacos配置管理操作流程 可以 做 ip hash定位使用哪台机器;每次都访问同一台机器 ,或者做共享session; 集群列表的配置文件,第3步通知的时候就是读取这里获取集群所有服务器列表 给配置文件中的集群列表发送给...
  •  配置管理(Configuration Management, CM)的目的,在使用配置识别、配置控制、配置状态记录及配置审计,来达到建立与维护工作产品的完整性。  配置管理提供了结构化的,有序化的,产品化的管理软件工程的方法...
  • 简述软件配置管理

    千次阅读 2005-09-03 06:43:00
    一、简述软件配置管理随着软件团队人员的增加,软件版本不断变化,开发时间的紧迫以及多平台开发环境的采用,使得软件开发面临越来越多的问题,其中包括对当前多种产品的开发和维护、保证产品版本的精确、重建先前...
  • 项目级配置管理员的职责: 1 制定配置管理计划 2 建立并维护配置管理库 3 建立并发布基线 4 物理审计(PCA) 5 跟踪并关闭变更申请 6 报告配置状态 组织级CM的职责: 1 为项目组建立初始的配置库 2 向项目组成员...
  • 配置管理系统浅析

    万次阅读 2013-06-13 21:42:29
    我们的程序常常有一些配置... 公司或者部门范围内构建统一的配置管理系统,应用通过API获取配置服务。 通过配置文件管理配置信息的方式存在一些问题,主要有: 1.部署和更新成本高 当前一个互联网服务常常部署在多台
  • 在大型集群和分布式应用中,配置不宜分散到节点中,应该集中管理,为各种业务平台提供统一的配置管理服务。 随着业务的发展,应用系统中的配置通常会越来越多,常见的一些应用配置大致会有数据源配置,数据源组件...
  • spring profile 多环境配置管理

    万次阅读 2016-09-12 21:48:23
    本地、测试、开发、产品等不同环境文件配置 现象  如果在开发时进行一些数据库测试,希望链接到一个测试的数据库,以避免对开发数据库的影响。  开发时的某些配置比如log4j日志的级别,和生产环境又有所区别。 ...
  • 软件配置管理

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

    万次阅读 2018-04-24 17:43:00
    曙光服务器自带的管理口默认没有配置IP,需要进到BIOS中先配置管理IP,再通过管理口管理服务器。下面简单介绍如何配置管理口IP以及如何登陆管理界面。一、配置管理口IP服务器开机后,在提示界面按DEL键进入BIOS界面...
  • 随着软件系统的日益复杂化和用户需求、软件更新的频繁化,配置管理逐渐成为软件生命周期中的重要控制过程,在软件开发过程中扮演着越来越来重要的角色。一个好的配置管理过程能覆盖软件开发和维护的各个方面,同时对...
  • 软件配置管理

    千次阅读 2008-06-23 15:22:00
    关键词:CMMI 配置管理 CM 配置项 基线 变更 在笔者进行CMMI咨询时,当问及软件技术人员什么是“配置管理”的时候,很多人的回答就是“版本管理”,而且很多人都会说出各种各样的版本管理工具,例如:VSS、TFS、CVS...
  • IT配置管理

    千次阅读 2007-04-12 11:30:00
    如果你都不知道自己的IT环境里有什么,就别指望控制、维护和提高它们,因此配置管理实施是IT服务管理的一个关键。配置管理的实施一般分为三步:定义配置管理的流程、定义配置管理角色和职责以及定义配置项对象。 在...
  • 配置管理流程

    千次阅读 2004-08-13 15:17:00
    配置管理流程 作者:龚云卿 撰写日期:2004年8月13日1 概要1.1 内容规范配置管理活动,确保配置项正确地唯一标识并易于存取,保证基准配置项的更改受控,明确基线状态,在贯穿整个软件生命周期中建立和维护项目...
  • 软件配置管理七重境界

    千次阅读 2014-12-21 10:16:44
    软件开发热点词汇不断推陈出新,cmmi,agile,精益,持续交付,持续集成,灰度……但有一个词其实一直在那里,支持着各种各样的新热点,它是#软件配置管理#。 它也是影响团队软件开发效率的重大因素。英文缩写SCMSCM...
  • 高效组织的配置管理计划

    千次阅读 2014-08-19 06:53:19
    根据IEEE 828和CMM/CMMI,配置管理计划常常被认为是一份文档,确实的,对于一个大项目而言,往往需要制定项目自身的配置管理计划。但不是所有的组织都是软件外包组织,不是每个项目针对的是不同的客户。在非软件外包...
  • SCM学习第二周,了解到软件工程的危机---------大量的代码无法统一,没有统一的管理 变更带来的大量的问题(费时 成本高 质量差),随着软件的发展,代码在失控,这时配置管理开始挽救整个软件业。 WHAT-----早在...
  • 项目管理中的配置管理

    千次阅读 2017-11-05 23:07:59
    配置管理的目标:为了系统地控制配置变更,在系统的整个生命周期中维持配置的完整性和可跟踪性,标识系统在不同时间点上的配置。配置管理的主要活动:制定配置管理计划、配置标识、配置控制、配置状态报告、配置审计...
  • 配置管理之三类配置库

    万次阅读 2018-02-22 15:19:13
    1 三库管理原则项目配置管理的库分为开发库、受控库、产品库。这三个库是相互独立的物理库,其中受控库在逻辑上分为配置库和基线库。1.1 开发库存放代码、脚本等开发过程中的产物。由开发人员使用。只有开发人员可...
  • 如何有效管理配置三库? 项目配置三库分别是开发库、受控库、产品库;针对三库的关系,概要总结就是:...受控库,保存已被批准的配置项(包括基线),由配置管理员管理与维护。信息分两类:受控基线和受控配置项。...
  • 配置管理之数据库版本控制策略

    千次阅读 2014-10-20 08:26:51
    数据库版本是研发过程中需要把控的一个方面,但实际操作上很多时候并没有使用配置管理的思路进行统一管理,尤其是对研发管理尚未完善的团队而言更是如此。本文围绕配置管理这个主题,针对研发过程中的数据库版本控制...
  • 百度分布式配置管理平台-Disconf

    千次阅读 2018-01-06 16:38:32
    Disconf专注于各种分布式系统配置管理的通用组件和通用平台, 提供统一的配置管理服务。 主要目标: 部署极其简单:同一个上线包,无须改动配置,即可在 多个环境中(RD/QA/PRODUCTION) 上线。 部署动态化:...
  • 下面来介绍一下通过windows命令来打开SQLSERVER配置管理器。 首先:windows键+R键 各个sqlserver版本在textbox中输入对应的命令如下: SQLServerManager13.msc(对于 SQL Server 2016 ) SQLServerManager12.ms...
  • [项目管理] 项目管理之配置管理

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

    千次阅读 2018-09-21 19:52:32
    软件环境 centos7 python2.7.6 etcd3.2.18 confd 0.16 nginx1.12.1 效果演示 拓扑图 ...1)安装 etcd(这里安装的单机,集群环境根据自己的需求选取) ... # sed -i 's/localhost/0.0.0.0/g' /etc/etcd/etcd.c...

空空如也

1 2 3 4 5 ... 20
收藏数 234,224
精华内容 93,689
关键字:

配置管理