出款系统维护不给出款处理方法 DevOps系统自动部署技术方案 | 周末送资料
APP宣发
作为项目成员，能快速获得和分享项目提交物，并能存储和获得修改历史。
1.3.4 代码管理规范化
作为开发人员，能获得所承担的工作项，完成相应的代码修改，提交新文件版本并自动关联工作项。
1.3.5 自动构建
作为发布人员，能运行自动构建，把发布包自动导入软件部署工具, 并触发测试环境的自动部署。
2方案设计原则
1．实用性原则
在需求分析的基础上设计系统，确保系统满足需求；
努力设计简单、方便、友好的用户界面，使用户易于理解、易学、易操作，保证系统发挥应有功效；
充分考虑已有资源（软硬件设备及数据）的合理利用，与现有系统的兼容性，最大限度的保护现有设备的投资，实现系统操作上的一贯性；
设计时考虑好新旧系统平稳过渡问题，避免出现不必要的浪费。
2．先进性原则
系统构造采用先进的B/S架构，简化客户端的支持工作；
系统实现采用先进的云计算技术、容器技术、微服务架构技术；
应用软件开发采用先进的软件工程方法，确保软件质量，并提供完整的技术文档。
3．可行性原则
采用的先进技术应是成熟的经过实践证明是成功的技术；
设计的方案要科学、正确、严谨、且现实可行。
4．开放可扩充性原则
系统设计要采用结构化和模块化的设计方法，使系统逻辑结构清晰、易读，在功能的划分和设计时，使各模块尽可能相对独立、减少相关性以易于扩充、维护和修改；
系统选型应遵循国际标准，具有一定的设备无关性，使设备配置和系统扩展有更大的自由度和灵活性；
注重系统的设计具有一定的兼容性；
系统设计要考虑到业务未来发展的需要，同时考虑系统建设的阶段性，要尽可能地设计得简明，各个功能模块间的耦合度小，便于系统的扩展，平滑地与其它应用系统自动接口。
5．安全性原则
建立完善的授权机制，主要为不同的用户提供合适的访问权限，使其不越权使用；
保证系统操作的可记录性，以便对操作行为进行监督。
6．可移植性、可延续性原则
采用的开发技术不仅满足现在的应用需求，而且要适应未来的发展趋势，在以后的升级、移植工作方便；
降低用户的二次开发成本，保证用户的投资利益。
3技术方案3.1 业务架构
软件从需求收集到部署上线需要各种角色的人员共同协作，经过一系列专业过程，才能最终实现预期的产品功能，交付目标用户使用。这些活动可以使用不同的过程模型来描述和规范。
软件过程模型就是一组开发策略，这种策略针对软件工程的各个阶段提供了一套范式，使工程的进展达到预期的目的。对一个软件的开发无论其大小，我们都需要选择一个合适的软件过程模型，这种选择基于项目和应用的性质、采用的方法、需要的控制，以及要交付的产品的特点。
在整个软件工程的发展历史上，出现过多种软件过程模型。比较典型的开发模型有线性的瀑布模型、增量的迭代模型等。在这些模型中有一些共同的基本活动：需求、开发、构建、部署，通过按照时序完成这些活动（迭代模型中是多轮次完成），逐步完善一款软件的各个方面，并最终交付完整系统或者每个增量特性。
现代软件系统规模越来越大，逻辑越来越复杂，开发一款软件需要的工程人员结构越来越复杂，但协作确越来越频繁和至关重要。由于不同角色的工程人员技术背景和职责不同，往往在协作过程中会产生协作不畅的现象，非常典型的开发团队和运维团队之间的协作问题。同时，由于软件本身的复杂度不断提高，完全依靠人工的处理就有不够稳定和高效。
软件业界针对那些执行起来比较繁琐或者经常出现问题的活动，有一种方法论来处理：更加频繁、更加自动化地处理这些活动以便更快地得到反馈，尽快发现问题并快速将问题解决在萌芽阶段。敏捷软件交付方法就是这种方法论的具体实践。
（英文和的组合）是一组过程、方法与系统的统称，用于促进开发、技术运营和质量保障部门之间的沟通、协作与整合。可以进一步划分为持续集成（CI， 的缩写）和持续交付（CD， ）。
软件过程图
的工程实践一般采用快速迭代的模型。每个迭代依然主要由需求、研发、构建、部署四个阶段组成，但是每个阶段都有相应的实践来优化。需求和研发阶段属于持续集成，而构建和部署则属于持续交付。
需求阶段，方案设计配置项以及工程代码集中管理，并规范配置项与代码之间的关联。
当研发人员实现完工作项并将对应的代码提交进配置仓库时，用户可以关联代码集和相应的工作项，实现需求与实现的跟踪。
研发阶段，设置自动化的代码集成测试，检查代码质量，并及时反馈团队；支持项目团队针对每一个代码修改在线协作改进，以及规范稳定版和研发版代码的组织结构。
项目推荐用户保持一个随时可以用于部署的代码基，一般叫做主分支，没有完成的或者发现有缺陷的代码不能提交合并到该代码基。开发人员可以为每个工作项以最新的主分支为基础创建一个代码分支，用于临时保存针对该工作项的代码。这个临时分支也可以提交到集成配置库保存，防止所做代码修改意外丢失。更加重要的是，它可以用于开发人员之间随时进行代码评审和协作完善，且多个工作项可以并行处理，互不干扰。
除了可部署代码基和临时特性开发分支，用户还可以创建用于质量保障测试、预发布、正式产品发布等用途的分支。这些分支会根据应用发布计划从某个时间点的主分支创建，并封闭一段时间，期间不再合并新的工作项代码集。如果进入下一轮发布或者需要修改封闭测试过程中发现的缺陷，用户仍然需要先使用临时分支开发并合并代码集到主分支，然后从主分支的代码集序列中合并需要的代码集。
用户可以配置一个或者多个分支执行集成任务，一旦有代码集提交到该分支，系统就会执行所配置的集成任务，并将反馈集成结果到代码集。如果分支配置了集成任务，那么只有集成任务成功的代码集才可以合并到主分支，以保障主分支的质量。
构建阶段，根据需要构建的分支的代码集变动，自动构建发布，并规范成品配置项的管理。
用户可以配置一个或者多个分支执行构建任务，一旦有代码集提交到该分支，系统就会执行所配置的构建任务，并将生成的版本保存到统一的仓库。
部署阶段，规范部署过程，实现复用，支持多套环境部署；与构建阶段对接。
用户可以描述多套环境的部署配置，每个配置相互独立。可以选择自动或者手动执行部署。如果选择自动部署，当部署关联的版本有更新时，系统自动触发一个部署任务执行部署操作。如果选择手动部署，只有用户触发部署时，系统才会创建一个部署作业执行部署。
3.2 技术架构
为实现应用系统自动部署的业务目标，系统采用以下技术架构：
该系统主要由四个层次组成，分别是基础设施层、基础服务层、引擎层和用户门户。
基础设施层由用于部署系统的基础设施资源组成，可以是物理机，也可以是虚拟机。这些主机需要配置一定的计算能力，足量、可靠的存储空间以及可以实现相互通信的网络连接。
基础服务层主要由集中配置仓库、集中软件仓库、数据库、消息中间件、缓存服务构成，用于支撑上层各组件的运行和之间的协作。
层是整个系统的核心，主要由持续集成引擎和持续交付引擎组成，相互协作处理上层用户请求，运用下层基础服务实现应用系统的自动部署功能。
用户门户是用户与系统的交互界面，调整系统参数，管理应用相关的人员、权限、代码、主机等资源。
系统主要由门户Web、API网关、授权管理器、工程管理器、集成管理器、构建管理器、部署管理器以及外部支持组件组成，它们之间的逻辑关系如下图：
组件逻辑架构图
3.3 数据架构
应用系统自动部署领域主要包含的数据模型以及它们之间的相互关系，可以用以下图表描述：
应用系统自动部署领域模型
一个应用系统可以包含一个或者多个工程，每个工程单独一个代码配置库。应用还会分配一个或者多个主机用于部署各个工程的发布版本。
研发过程中，每个工程的需求由一个或者多个工作项组成，团队根据这些工作项进行研发，最终生成一个或者多个代码集并提交到工程对应的配置库。每个提交可以关联一个或者多个工作项，也可以不关联工作项。提交之间组织成链式关系，从一个提交可以查看它所基于的整个提交历史。
为了方便团队的协作，一个工程可以创建一个或者多个分支，每个分支引用一个代码集及其上溯的整个提交历史。每个分支上可以创建不同的集成任务和构建任务，集成任务用于对分支的代码集执行集成测试并反馈结果。构建任务用于将分支的代码集构建成一个版本。版本是可以用于部署的组件，与一个代码集关联，并根据代码集关联的工作项得到该版本所实现的需求。版本一旦生成就不能修改了，并集中在一个版本库里管理。
一个工程可以根据版本的成熟情况部署多次，得到不同的运行实例。每个部署关联一个版本、可选的多个配置参数以及一个或者多个目标主机。系统可以启动多个部署任务来执行部署，将指定版本安装在目标主机上，并使用配置参数启动版本。
数据模型中涉及的实体根据不同特点采用了不同的存储技术，总体的数据存储架构如下图所示：
自动部署系统的组件主要使用代码仓库、消息队列以及关系数据库来存储系统的数据。系统业务模型的数据大部分通过关系型数据库存储。代码仓库是由GIT提供服务，存储代码文件到文件系统。组件之间协作是通过异步消息实现的，这些消息通过消息队列保存和堆积。其它文件类型的数据，比如文本格式的配置文件、二进制格式的版本包，统一采用文件系统进行存储。
基础层的文件系统可以是在主机的本地磁盘上构建的，也可以是基于SAN存储系统的LUN构建的，或者是其它共享文件系统。
整个系统的所有数据都可能部署到备份系统的存储上。
3.4 集成架构
应用自动部署系统需要与第三方开发商的代码仓库、测试管理软件、部署目的主机操作系统进行集成。
系统采用分布式代码管理方式，不同的代码管理系统保存的相同项目的代码可以方便地相互比较和同步。第三方可以缓存应用的集中库中代码到本地，并在本地离线开发，提高研发效率。
为了提高自动部署系统的自动化水平，代码系统的一些事件需要能够自动触发持续集成系统的处理。系统所采用的代码管理系统设计有hook机制，在代码集提交、分支合并等事件处设置了集成钩子。系统通过这些钩子，接收到代码管理系统的特定事件，并相应地启动持续集成任务。
持续集成引擎需要支持不同的集成任务，有些集成任务需要对接测试管理软件执行特定的测试计划。持续集成引擎采用插件架构，通过专门为测试管理软件开发的插件可以与它实现集成。
持续交付引擎执行部署任务时，需要能够从版本配置库获取应用的特定版本，保存到目标主机上并安装启动版本。版本配置库提供HTTP协议的API，方便引擎查询、下载版本。持续部署引擎可以通过目标主机上的代理插件远程执行命令来同步完成一些操作。
3.5 解决方案3.5.1 总体方案
应用自动部署平台通过搭建统一的配置管理以及持续集成和持续交付两个功能引擎，整合分布式代码管理系统、统一软件包管理系统、部署作业系统、容器技术以及第三方软件（如HPE ALM），实现包含应用工作项管理、代码管理、自动化代码测试和分析、代码在线评审、自动化构建等持续集成实践，达到集中管理和规范应用系统研发，促进团队协作的目的；同时实现包括应用发布版本包的统一管理、规范部署方案管理、自动化部署多套环境、多个版本的应用等持续交付实践，达到标准化部署流程，提高部署自动化程度，实现应用可靠、快速交付上线，从而，为业务发展提供强有力的支撑，并从IT发展自身角度建立扎实的技术基础。
整个系统的功能按照下图所示划分和组织。
功能结构图
系统核心是配置管理以及持续集成和持续交付核心引擎。配置管理的主要功能包括工作项管理和代码管理。持续集成引擎的主要功能包括集成配置、代码评审、自动测试、构建配置、自动构建和集成作业管理。持续交付引擎的主要功能包括版本管理、部署配置、自动部署和部署作业管理。
系统面向用户提供管理控制台，主要功能包括参数管理、用户管理、权限管理、资源管理、工程管理。
以下将按照功能模块详细说明解决方案。
3.5.2 配置管理
配置管理主要功能有工作项管理和代码管理。
作为开发人员，可以创建、编辑和删除工作项，根据实际研发进度更好工作项状态。
作为开发人员，可以在提交一个代码集时，在代码集的描述信息中使用标记关联若干个工作项，对需求和实现进行跟踪。
当一个代码集经过测试和评审，合并到主分支中时，系统会自动关闭代码集关联的工作项。
作为项目成员，可以快速获得并存储项目代码，查看修改历史。
系统采用git作为配置管理存储系统，可以按照工程存储代码，支持使用SSH、HTTP/HTTPS协议获取任何一个时间点的项目代码，支持查看任一纳入配置管理的代码文件的修改历史信息。
对于异地进行开发的团队，可以从集中配置库签出代码，操作方式与内部访问一致。开发人员可以同时添加多个配置管理系统，拉取代码进行评审或者合并。
系统支持创建任意多个分支。每个工程都默认创建一个主分支。分支只是一个代码集提交的别名，因此创建分支是非常轻量级的操作，速度很快。
除了分支以外，配置管理支持设置标签来标识一个代码集提交。标签一般用于标记工程代码的一个特殊状态，可以将版本号与对应的代码关联起来。
3.5.3 持续集成
作为开发人员，可以设置自动集成相关策略和参数，以便当工程代码发生变更时触发系统的自动集成，快速得到有关所提交代码质量的反馈。
工程创建时，系统会将工程的代码仓库和集成引擎间通过hook创建联系。一旦代码仓库有修改，集成引擎就会得到通知，如果工程配置了自动集成，系统执行集成作业，并反馈结果到代码集的关联事件列表中。
作为项目成员，可以将自动还没有合并的代码集创建一个合并请求，改善给项目评审人员进行评审。评审人员可以使用对比视图查看需要合并的代码。如果有评审意见，双方可以直接在线交流修改意见。合并请求在接受合并前可以多次更新，以便包含更新的修改。
作为项目成员，可以添加单元测试代码，以便保证代码逻辑正常和一定的质量标准。
单元测试代码需要用户自己编写。目前主流编程语言都支持xUnit或者类似的单元测试框架。
系统在自动集成过程中，默认都会执行自动化测试，并反馈测试结果给用户。一旦有失败的测试，那么本次自动集成作业失败。这需要提交该代码集的用户解决发现的问题后再次提交，直到测试通过。
作为发布人员，可以设置构建配置和软件版本号，以便自动完成应用软件包的构建。
软件的版本号通过创建以版本号命名的标签来实现，系统发现当前提交设置了标签，会优先使用它作为版本号。如果提交没有标签，系统默认会结合提交的唯一标识创建版本号。
自动构建的触发机制与自动测试相同，当代码发生修改时，系统会根据构建配置执行构建作业，创建软件包并按照设置的版本号命名，最终存储到集中的软件包仓库。
作为项目成员，可以查看各种集成作业的日志，以便了解集成作业的详细信息，辅助解决过程中的问题。
3.5.4 持续交付
作为发布人员，能够管理各个版本软件包，以便快速得到任意版本的软件部署包。
系统设置一个站点存储软件包，每个软件包存储版本更新历史，对外提供HTTP协议的访问接口，支持上传、查看、下载软件包。
作为部署人员，可以配置需要部署的版本、目标主机以及参数设置，以便系统能够自动完成部署。
系统将部署配置信息作为代码纳入配置管理，方便团队成员统一管理和内容评审。
配置中的目标主机，可以是明确指定主机名或者IP。这些主机需要是分配给应用使用的资源（有关资源管理，可以参见“控制台”的相关说明），否则无法部署到指定主机。
如果指定多台主机，系统会并行执行相同的部署作业。这可以用于部署对等集群系统。
系统支持同一个版本的应用部署到多套环境中。
当系统自动触发或者用户请求执行自动部署时，系统创建部署作业，按照部署配置将相应的版本软件包部署到关联的主机上。部署成功后，系统会更新主机资源关联的应用版本信息。
如果配置了多套环境，系统顺序执行每套环境的部署。如果配置指定了多台主机，系统会并行启动多个部署作业来执行部署。
用户可以手动从控制台触发一套或者多套环境的部署。多套环境的部署策略和自动触发下的处理一致。
作为项目成员，可以查看各种部署作业的日志，以便了解部署作业的详细信息，辅助解决过程中的问题。
3.5.5 控制台
作为系统管理员，可以修改参数设置，以便调整系统功能。
作为系统管理员，可以管理系统的用户，以便工程人员可以使用系统。
作为系统管理员，可以对用户进行分组，以便快速调整一组用户的设置。
系统通过权限管理，设置不同用户在不同工程中的角色，从而控制用户可以执行的操作。
作为应用管理员，可以为应用添加主机资源，以便控制自动部署可以使用的资源。
作为应用管理员，可以创建一个或者多个工程，以便更好地组织整个应用的开发和部署。
用户创建工程时，系统会自动为工程创建相关联的配置仓库、软件包仓库。
3.6 部署方案
应用自动部署系统以多个组件发布，各个组件力求无状态，以便集群部署，提高系统的可靠性和性能。系统主要组件可以采用的逻辑部署如下图所示。
系统逻辑部署图
系统每个组件的所需要的资源规格如下表：
节点类型
指标
备注
控制台节点
4C8G
管控节点
8C16G
配置库节点
4C8G，300G数据存储
引擎节点
8C16G
基础服务节点
8C16G
3.7 非功能性设计3.7.1 性能
系统的性能是一个系统成败的关键所在，在架构设计初期就一定要把系统性能考虑在内，否则等开发完成以后测试发现性能不好就比较难办，通常要花费较长的时间来诊断性能瓶颈，找到提升的办法，甚至要改变架构，伤筋动骨，往往造成项目延期。所以性能设计首先要有明确的性能目标，根据用户和软件本身的性能要求来设计，合适的就是最好的。其次，要有适当的度量标准和量化的性能指标。最后，要有相应的设计策略，具体的测试方法。
影响系统性能主要瓶颈在I/O，包括数据库，，网络通信，文件等，例如频繁查询数据库并返回大量结果集，频繁操作大文件等，这些昂贵的操作会占用大量的CPU时间。拿系统响应和服务一个事务来说，有几个Round trip，要通过哪几层I/O，如何合理的分配这些I/O的调用，降低不必要的I/O，都是进行系统性能设计要考虑的。而有些性能问题在初期并不会表现出来，但当拿到实际上线环境下，存在多用户并发、大数据量的情况下就会暴露出严重的问题。所以性能设计时一定要考虑到I/O，同步，并发，资源争用，以及大数据量等因素。通常，I/O操作、网络响应、差的算法、数据库、以及其他的低效的资源使用都会导致低劣的性能。
在性能设计上，我们的主品主要考虑了以下的设计策略：
（1） 缓存以及缓存层( layer)
在数据层和应用层之间增加数据缓存层，提供全局数据服务。可以大大减少数据库往返次数。与读取数据库和读取大文件（如XML文件）比，读取内存的速度无疑要快的多。所以对经常要访问的数据进行缓存是非常好的实践方法。因为现在系统往往内存很大，可以充分利用大内存，而共享内存更能实现数据并发访问。
（2） 多线程(multi-)
现在基本上大部分软件实现多线程或多进程，多线程对单CPU系统还只是顺序利用CPU时间和改善用户体验，多CPU系统才是真正的并行。要注意的是多线程不要争抢访问同一资源而导致部分串行操作，要做到真正的并行操作多线程并不容易。另外，在多线程间同步一个庞大的资源，过多创建线程又没有实现线程池也会导致系统性能下降。
（3） 负载均衡(load )
物理上增加地位对等的集群服务器（），通过负载分配算法分配相应服务器来相应客户端请求，我们的产品设计充分考虑了系统的可扩展性，所有节点都支持负载均衡，以实现整个系统的无限扩展。
（4） 数据库优化（ ）
数据库的优化是一个持续的过程，在架构上，我们支持数据库的读写分离，能对CPU利用率、IOPS、连接数、磁盘空间等实例信息实时监控，并给出相应的SQL语句优化意见，根据需要建立相应的数据库索引。
（5） 文件系统优化
有时候系统性能不好，但当你关闭写log的功能，性能一下子提高很多。因为频繁的打开关闭大log文件时I/O开销非常大，同样记录log到数据库也一样。所以，版尽量减少写log，或干脆移到**设备上。
频繁打开关闭文件对系统性能下降程度是惊人的，可以通过一些变通办法来减少文件的频繁操作。
例如，原来的缓存持久化实现是保存在XML文件，每次要获得一个配置项，都打开XML文件，通过XPath拿到这个配置项的值，这样效率不高，而且容易把这个XML文件lock住；改进的方法是：通过比较XML文件的修改时间(.IO.File.)判断是否要再次打开文件，大大提高了效率；另一个可以改进的方法是：启动时读取所有配置到一个静态的，每次要获得一个配置项都从内存获取，在最后或适当的时候持久化到XML。
通过以优化，我们的软件能达到用户要求的以下性能指标：
大类
指标
备注
稳定性测试
稳定运行时间
一周
指标
系统峰值的60%
系统资源
CPU使用率
