Devops系统自动部署技术方案

DevOps系统自动部署项目技术方案目录TOC\o"1-5"\h\z\o"CurrentDocument"项目概述 3\o"CurrentDocument"项目背景 3\o"CurrentDocument"项目现状 4\o"CurrentDocument"项目目标 6\o"CurrentDocument"提高测试和部署的自动化水平 6\o"CurrentDocument"集中管理应用部署包 6\o"CurrentDocument"快速分享提交物 6\o"CurrentDocument"代码管理规范化 7\o"CurrentDocument"自动构建 7\o"CurrentDocument"方案设计原则 8\o"CurrentDocument"技术方案 10\o"CurrentDocument"业务架构 10技术架构 12\o"CurrentDocument"数据架构 14\o"CurrentDocument"集成架构 16\o"CurrentDocument"解决方案 17\o"CurrentDocument"总体方案 17\o"CurrentDocument"配置管理 18\o"CurrentDocument"持续集成 19\o"CurrentDocument"持续交付 20\o"CurrentDocument"控制台 21\o"CurrentDocument"部署方案 22\o"CurrentDocument"非功能性设计 24\o"CurrentDocument"性能 24\o"CurrentDocument"可靠性 26\o"CurrentDocument"可用性 27\o"CurrentDocument"可扩展性 27\o"CurrentDocument"可维护性 28\o"CurrentDocument"安全性 29项目概述企业级的配置管理和自动部署平台，从配置管理，构建管理等角度对软件开发中的各个细节进行改进和能力加强；集中有序管理应用代码和版本，确保资产自主可控，最大限度地保证资产可复用性。运用自动化工具，从部署包、部署环境、部署流程以及部署执行四个维度，提升应用软件系统部署的自动化水平，降低部署过程中的出错率、返工率，进而提高软件交付的效率和质量。基于该平台的研究和运用，以尽可能短的周期，高效可靠地构建、测试、发布应用软件。从而，为业务发展提供强有力的支撑，并从IT发展自身角度建立扎实的基础。项目背景谈到企业IT，就没有办法回避两种迥然不同的企业，一种是以传统制造业或者服务业为基础的，对生产资料进行加工的「传统企业」；另一种是以「信息互联」为基础的，对「人与人关系、人与物关系、物与物关系」进行信息加工的「互联网企业」。这两类，是两类极端的企业，一类企业的日常运行，可以没有信息系统；另一类企业，完全离不开信息系统。一般的信息系统，对于企业的价值，主要有三类渐进过度的典型类型。第一类，是将信息系统定位于「辅助和支撑」企业的产品制造以及企业运营部门，因为这类企业的生产资料系、生产力、生产关，都以实体制造为主，不以信息加工和处理作为企业产品核心。第二类，是将信息系统作为数据加工、传输作为主体，但业务模式来自于传统行业，信息系统主要完成已有业务规则的虚拟化，例如金融、电信行业。这类企业的信息或者数据，主要来自于业务受理，或者说数据的生产者和使用者是企业自身。第三类，是将信息系统作为企业唯一生产工具，并将企业的客户（个人或企业）所自发贡献的信息、数据，作为生产资料，形成新兴的业务模式。这里企业的典型，就是互联网企业。随着又一轮「互联网+」的概念席卷而来，非互联网企业所面临的更多针对用户和客户的思考和探索，都需要有更快交付能力的信息系统进行支撑，这也是传统企业互联网化，打开企业边界围栏需要迈出的第一步。随着云计算、容器/Docker、微服务、敏捷等相关概念和实施的成熟发展，DevOps已经基本成为互联网企业的标准配置，在DevOps的概念被炒热之前，众多互联网公司其实已经实践了DevOps。其中的原因也正是因为信息系统，是这些公司的生产工具，没有人比互联网公司的人更明白提高自身的办公效率，提高团队、企业的生产力，就是为提高企业产品的生产力进行有效的保障。DevOps的核心价值，是能够帮助企业快速交付变更，以便于快速响应企业对于市场的变化、用户的需求。包括7个主要过程：代码、构建、测试、打包、发布、配置、监控。相比传统企业尤其是制造业的产品制造工艺和制造流程，软件产品的制造，IT服务的交付，更多的是交付一些无形的软件产品和知识工作。正因为这些无形产品受制于不同的人认知所产生的多变，其管理复杂度远比制造业来的复杂，企业软件的设计、开发、发布、上线，缺乏标准化的管理过程。对于如今的非互联网企业而言，能够快速见效的DevOps实践，应当从（环境）配置的管理，以及自动化部署。在实施难度上，配置的管理要低于自动化部署。因为非互联网企业的技术路线由于供应商的竞争（甚至是恶意竞争），变得极其多样，架构离散化程度也很高。对比互联网企业，（环境）配置管理和自动化部署，由于IT技术从硬件到虚拟化/容器的自主可控，企业整体技术架构的收敛性就比较理想。项目现状目前企业级的配置管理和自动化部署系统还处于建设初期，大部份企业都面临着几大问题，包括缺乏统一的研发管理平台、项目管理有待规范化、配置和版本管理混乱、缺乏应用部署环境资源管理、手工操作导致低效率和高出错率。缺乏统一的研发管理平台自主开发和外包开发的项目众多，工具繁杂而不统一，各种工具往往只解决某一个点上的问题，例如配置管理，缺陷管理，计划任务管理，构建管理等。部分研发环节使用开源工具或非专业化工具，工具间缺乏集成性，数据无法连通，不同项目所使用的工具都存在差异，项目资产数据也分散在这些工具当中，无法有效加以利用，并大大增加了管理难度。现有的RTC，CQ等工具，使用量较少，并且没有整合为一个平台。例如RTC只用于个别项目的构建管理，CQ用于需求提出和故障流程管理。这些环节之间是断裂的，没有连通起来构成清晰的研发生命周期链条。项目管理有待规范化目前的研发项目管理处于较为粗放，落后的状态。既定的项目流程规定在各个项目当中并未很好地落实和执行，往往凭借项目经理的经验和习惯进行管理。信息汇总通过会议和文档进行，沟通传达通过邮件和口头等方式。流程仅仅落在纸面上并由手工监督执行，这种管理方式显然与我行建设先进高效的研发管理理念不符。配置和版本管理混乱现有代码分散在开发商自有的版本管理系统，对代码缺乏集中、有序的管理和维护。缺乏应用部署环境资源管理缺乏集中、规范并易于访问的软件发布包存储库。当前很多软件包的存储基于简单文件系统，这种存储方式不便于被不同应用环境的部署人员快速访问。手工操作导致低效率和高出错率采用手工操作界面或运行构建脚本形成发布包，手工记录和沟通每个环境所部署的应用版本，系统测试、用户验收测试、准生产、生产环境的应用部署基于手工操作（包括手工修改参数文件、手工执行部署命令）。在手工部署，通常手工操作包括把发布包拷贝到目标机器，根据部署环境的差异对客户化发布包，然后执行部署命令，最后对部署结果进行验证。部署相关流程基于手工进行沟通，沟通成本高，效率低：比如应用在测试环境部署完成后，需要通过邮件或电话通知测试人员；在部署生产环境前，需要人工完成审批。项目目标配置管理和自动部署平台从配置管理、构建管理等角度对软件开发中的各个细节进行改进和加强，并持续提升应用系统部署的自动化水平和效率，从而快速响应业务需求，本项目的主要目标包括：提高测试和部署的自动化水平作为发布人员，能制定跨环境、跨版本重用的标准化部署流程；作为部署人员，查看不同环境下部署的应用组件版本和部署日志，发起特定环境、特定流程和特定版本的部署请求。集中管理应用部署包作为发布人员，能管理发布包版本和版本文件，定义版本类型（增量或全量）和状态，有效的集中管理应用部署包。作为部署人员，能管理被部署服务器并关联需要部署的应用组件，获得已部署的应用组件版本信息。快速分享提交物作为项目成员，能快速获得和分享项目提交物，并能存储和获得修改历史。代码管理规范化作为开发人员，能获得所承担的工作项，完成相应的代码修改，提交新文件版本并自动关联工作项。自动构建作为发布人员，能运行自动构建，把发布包自动导入软件部署工具,并触发测试环境的自动部署。方案设计原则1．实用性原则在需求分析的基础上设计系统，确保系统满足需求；努力设计简单、方便、友好的用户界面，使用户易于理解、易学、易操作，保证系统发挥应有功效；充分考虑已有资源（软硬件设备及数据）的合理利用，与现有系统的兼容性，最大限度的保护现有设备的投资，实现系统操作上的一贯性；设计时考虑好新旧系统平稳过渡问题，避免出现不必要的浪费；2．先进性原则系统构造采用先进的B/S架构，简化客户端的支持工作；系统实现采用先进的云计算技术、容器技术、微服务架构技术；应用软件开发采用先进的软件工程方法，确保软件质量，并提供完整的技术文档；3．可行性原则采用的先进技术应是成熟的经过实践证明是成功的技术；设计的方案要科学、正确、严谨、且现实可行；4．开放可扩充性原则系统设计要采用结构化和模块化的设计方法，使系统逻辑结构清晰、易读，在功能的划分和设计时，使各模块尽可能相对独立、减少相关性以易于扩充、维护和修改；系统选型应遵循国际标准，具有一定的设备无关性，使设备配置和系统扩展有更大的自由度和灵活性；注重系统的设计具有一定的兼容性；系统设计要考虑到业务未来发展的需要，同时考虑系统建设的阶段性，要尽可能地设计得简明，各个功能模块间的耦合度小，便于系统的扩展，平滑地与其它应用系统自动接口；5．安全性原则建立完善的授权机制，主要为不同的用户提供合适的访问权限，使其不越权使用；保证系统操作的可记录性，以便对操作行为进行监督；6．可移植性、可延续性原则采用的开发技术不仅满足现在的应用需求，而且要适应未来的发展趋势，在以后的升级、移植工作方便；降低用户的二次开发成本，保证用户的投资利益；技术方案业务架构软件从需求收集到部署上线需要各种角色的人员共同协作，经过一系列专业过程，才能最终实现预期的产品功能，交付目标用户使用。这些活动可以使用不同的过程模型来描述和规范。软件过程模型就是一组开发策略，这种策略针对软件工程的各个阶段提供了一套范式，使工程的进展达到预期的目的。对一个软件的开发无论其大小，我们都需要选择一个合适的软件过程模型，这种选择基于项目和应用的性质、采用的方法、需要的控制，以及要交付的产品的特点。在整个软件工程的发展历史上，出现过多种软件过程模型。比较典型的开发模型有线性的瀑布模型、增量的迭代模型等。在这些模型中有一些共同的基本活动：需求、开发、构建、部署，通过按照时序完成这些活动（迭代模型中是多轮次完成），逐步完善一款软件的各个方面，并最终交付完整系统或者每个增量特性。现代软件系统规模越来越大，逻辑越来越复杂，开发一款软件需要的工程人员结构越来越复杂，但协作确越来越频繁和至关重要。由于不同角色的工程人员技术背景和职责不同，往往在协作过程中会产生协作不畅的现象，非常典型的开发团队和运维团队之间的协作问题。同时，由于软件本身的复杂度不断提高，完全依靠人工的处理就有不够稳定和高效。软件业界针对那些执行起来比较繁琐或者经常出现问题的活动，有一种方法论来处理：更加频繁、更加自动化地处理这些活动以便更快地得到反馈，尽快发现问题并快速将问题解决在萌芽阶段。DevOps敏捷软件交付方法就是这种方法论的具体实践。DevOps（英文Development和Operation的组合）是一组过程、方法与系统的统称，用于促进开发、技术运营和质量保障部门之间的沟通、协作与整合。可以进步划分为持续集成（CLcontinuousintegration的缩写）和持续交付（CD,continuousdelivery)DevOps软件过程图DevOps的工程实践一般采用快速迭代的模型。每个迭代依然主要由需求、研发、构建、部署四个阶段组成，但是每个阶段都有相应的实践来优化。需求和研发阶段属于持续集成，而构建和部署则属于持续交付。需求阶段，方案设计配置项以及工程代码集中管理，并规范配置项与代码之间的关联。当研发人员实现完工作项并将对应的代码提交进配置仓库时，用户可以关联代码集和相应的工作项，实现需求与实现的跟踪。研发阶段，设置自动化的代码集成测试，检查代码质量，并及时反馈团队；支持项目团队针对每一个代码修改在线协作改进，以及规范稳定版和研发版代码的组织结构。项目推荐用户保持一个随时可以用于部署的代码基，一般叫做主分支，没有完成的或者发现有缺陷的代码不能提交合并到该代码基。开发人员可以为每个工作项以最新的主分支为基础创建一个代码分支，用于临时保存针对该工作项的代码。这个临时分支也可以提交到集成配置库保存，防止所做代码修改意外丢失。更加重要的是，它可以用于开发人员之间随时进行代码评审和协作完善，且多个工作项可以并行处理，互不干扰。除了可部署代码基和临时特性开发分支，用户还可以创建用于质量保障测试、预发布、正式产品发布等用途的分支。这些分支会根据应用发布计划从某个时间点的主分支创建，并封闭一段时间，期间不再合并新的工作项代码集。如果进入下一轮发布或者需要修改封闭测试过程中发现的缺陷，用户仍然需要先使用临时分支开发并合并代码集到主分支，然后从主分支的代码集序列中合并需要的代码集。用户可以配置一个或者多个分支执行集成任务，一旦有代码集提交到该分支，系统就会执行所配置的集成任务，并将反馈集成结果到代码集。如果分支配置了集成任务，那么只有集成任务成功的代码集才可以合并到主分支，以保障主分支的质量。构建阶段，根据需要构建的分支的代码集变动，自动构建发布，并规范成品配置项的管理。用户可以配置一个或者多个分支执行构建任务，一旦有代码集提交到该分支，系统就会执行所配置的构建任务，并将生成的版本保存到统一的仓库。部署阶段，规范部署过程，实现复用，支持多套环境部署；与构建阶段对接。用户可以描述多套环境的部署配置，每个配置相互独立。可以选择自动或者手动执行部署。如果选择自动部署，当部署关联的版本有更新时，系统自动触发一个部署任务执行部署操作。如果选择手动部署，只有用户触发部署时，系统才会创建一个部署作业执行部署。技术架构为实现应用系统自动部署的业务目标，系统采用以下技术架构：门户苜理控制普DevOps持续策成引擎（JMkim）自动部署引擎(Puppet.SaltSteck)基础服务集中配置仓厚（GitLab}建中软件仓库（RPM、DEB.Docker）基础设施物理机阚机该系统主要由四个层次组成，分别是基础设施层、基础服务层、DevOps引擎层和用户门户。基础设施层由用于部署系统的基础设施资源组成，可以是物理机，也可以是虚拟机。这些主机需要配置一定的计算能力，足量、可靠的存储空间以及可以实现相互通信的网络连接。基础服务层主要由集中配置仓库、集中软件仓库、数据库、消息中间件、缓存服务构成，用于支撑上层DevOps各组件的运行和之间的协作。DevOps层是整个系统的核心，主要由持续集成引擎和持续交付引擎组成，相互协作处理上层用户请求，运用下层基础服务实现应用系统的自动部署功能。用户门户是用户与系统的交互界面，调整系统参数，管理应用相关的人员、权限、代码、主机等资源。系统主要由门户Web、API网关、授权管理器、工程管理器、集成管理器、构建管理器、部署管理器以及外部支持组件组成，它们之间的逻辑关系如下图：

存储、消息、缓存

中间件组件逻辑架构图数据架构应用系统自动部署领域主要包含的数据模型以及它们之间的相互关系，可以用以下图表描述：应用系统自动部署领域模型一个应用系统可以包含一个或者多个工程，每个工程单独一个代码配置库。应用还会分配一个或者多个主机用于部署各个工程的发布版本。研发过程中，每个工程的需求由一个或者多个工作项组成，团队根据这些工作项进行研发，最终生成一个或者多个代码集并提交到工程对应的配置库。每个提交可以关联一个或者多个工作项，也可以不关联工作项。提交之间组织成链式关系，从一个提交可以查看它所基于的整个提交历史。为了方便团队的协作，一个工程可以创建一个或者多个分支，每个分支引用一个代码集及其上溯的整个提交历史。每个分支上可以创建不同的集成任务和构建任务，集成任务用于对分支的代码集执行集成测试并反馈结果。构建任务用于将分支的代码集构建成一个版本。版本是可以用于部署的组件，与一个代码集关联，并根据代码集关联的工作项得到该版本所实现的需求。版本一旦生成就不能修改了，并集中在一个版本库里管理。一个工程可以根据版本的成熟情况部署多次，得到不同的运行实例。每个部署关联一个版本、可选的多个配置参数以及一个或者多个目标主机。系统可以启动多个部署任务来执行部署，将指定版本安装在目标主机上，并使用配置参数启动版本。数据模型中涉及的实体根据不同特点采用了不同的存储技术，总体的数据存储架构如下图所示：缓存层 内存数据库 内存缓存服务层 I代码仓库I I消息队列I I关系型数据库基础层I文件系统I LUN 备份系统存储自动部署系统的组件主要使用代码仓库、消息队列以及关系数据库来存储系统的数据。系统业务模型的数据大部分通过关系型数据库存储。代码仓库是由GIT提供服务，存储代码文件到文件系统。组件之间协作是通过异步消息实现的，这些消息通过消息队列保存和堆积。其它文件类型的数据，比如文本格式的配置文件、二进制格式的版本包，统一采用文件系统进行存储。基础层的文件系统可以是在主机的本地磁盘上构建的，也可以是基于SAN存储系统的LUN构建的，或者是其它共享文件系统。整个系统的所有数据都可能部署到备份系统的存储上。集成架构应用自动部署系统需要与第三方开发商的代码仓库、测试管理软件、部署目的主机操作系统进行集成。系统采用分布式代码管理方式，不同的代码管理系统保存的相同项目的代码可以方便地相互比较和同步。第三方可以缓存应用的集中库中代码到本地，并在本地离线开发，提高研发效率。为了提高自动部署系统的自动化水平，代码系统的一些事件需要能够自动触发持续集成系统的处理。系统所采用的代码管理系统设计有hook机制，在代码集提交、分支合并等事件处设置了集成钩子。系统通过这些钩子，接收到代码管理系统的特定事件，并相应地启动持续集成任务。持续集成引擎需要支持不同的集成任务，有些集成任务需要对接测试管理软件执行特定的测试计划。持续集成引擎采用插件架构，通过专门为测试管理软件开发的插件可以与它实现集成。持续交付引擎执行部署任务时，需要能够从版本配置库获取应用的特定版本，保存到目标主机上并安装启动版本。版本配置库提供HTTP协议的API，方便引擎查询、下载版本。持续部署引擎可以通过目标主机上的代理插件远程执行命令来同步完成一些操作。解决方案总体方案应用自动部署平台通过搭建统一的配置管理以及持续集成和持续交付两个功能引擎，整合分布式代码管理系统、统一软件包管理系统、部署作业系统、容器技术以及第三方软件（如HPEALM），实现包含应用工作项管理、代码管理、自动化代码测试和分析、代码在线评审、自动化构建等持续集成实践，达到集中管理和规范应用系统研发，促进团队协作的目的；同时实现包括应用发布版本包的统一管理、规范部署方案管理、自动化部署多套环境、多个版本的应用等持续交付实践，达到标准化部署流程，提高部署自动化程度，实现应用可靠、快速交付上线，从而，为业务发展提供强有力的支撑，并从IT发展自身角度建立扎实的技术基础。整个系统的功能按照下图所示划分和组织。控制 参散管理 用户普建 校限昔谨 资源昔遵 工程管遵功能结构图系统核心是配置管理以及持续集成和持续交付核心引擎。配置管理的主要功能包括工作项管理和代码管理。持续集成引擎的主要功能包括集成配置、代码评审、自动测试、构建配置、自动构建和集成作业管理。持续交付引擎的主要功能包括版本管理、部署配置、自动部署和部署作业管理。系统面向用户提供管理控制台，主要功能包括参数管理、用户管理、权限管理、资源管理、工程管理。以下将按照功能模块详细说明解决方案。配置管理配置管理主要功能有工作项管理和代码管理。工作项管理作为开发人员，可以创建、编辑和删除工作项，根据实际研发进度更好工作项状态。作为开发人员，可以在提交一个代码集时，在代码集的描述信息中使用标记关联若干个工作项，对需求和实现进行跟踪。当一个代码集经过测试和评审，合并到主分支中时，系统会自动关闭代码集关联的工作项。代码管理作为项目成员，可以快速获得并存储项目代码，查看修改历史。系统采用git作为配置管理存储系统，可以按照工程存储代码，支持使用SSH、HTTP/HTTPS协议获取任何一个时间点的项目代码，支持查看任一纳入配置管理的代码文件的修改历史信息。对于异地进行开发的团队，可以从集中配置库签出代码，操作方式与内部访问一致。开发人员可以同时添加多个配置管理系统，拉取代码进行评审或者合并。系统支持创建任意多个分支。每个工程都默认创建一个主分支。分支只是一个代码集提交的别名，因此创建分支是非常轻量级的操作，速度很快。除了分支以外，配置管理支持设置标签来标识一个代码集提交。标签一般用于标记工程代码的一个特殊状态，可以将版本号与对应的代码关联起来。持续集成集成配置作为开发人员，可以设置自动集成相关策略和参数，以便当工程代码发生变更时触发系统的自动集成，快速得到有关所提交代码质量的反馈。工程创建时，系统会将工程的代码仓库和集成引擎间通过hook创建联系。一旦代码仓库有修改，集成引擎就会得到通知，如果工程配置了自动集成，系统执行集成作业，并反馈结果到代码集的关联事件列表中。代码评审作为项目成员，可以将自动还没有合并的代码集创建一个合并请求，改善给项目评审人员进行评审。评审人员可以使用对比视图查看需要合并的代码。如果有评审意见，双方可以直接在线交流修改意见。合并请求在接受合并前可以多次更新，以便包含更新的修改。自动测试作为项目成员，可以添加单元测试代码，以便保证代码逻辑正常和一定的质量标准。单元测试代码需要用户自己编写。目前主流编程语言都支持xUnit或者类似的单元测试框架。系统在自动集成过程中，默认都会执行自动化测试，并反馈测试结果给用户。一旦有失败的测试，那么本次自动集成作业失败。这需要提交该代码集的用户解决发现的问题后再次提交，直到测试通过。构建配置作为发布人员，可以设置构建配置和软件版本号，以便自动完成应用软件包的构建。软件的版本号通过创建以版本号命名的标签来实现，系统发现当前提交设置了标签，会优先使用它作为版本号。如果提交没有标签，系统默认会结合提交的唯一标识创建版本号。自动构建自动构建的触发机制与自动测试相同，当代码发生修改时，系统会根据构建配置执行构建作业，创建软件包并按照设置的版本号命名，最终存储到集中的软件包仓库。集成作业管理作为项目成员，可以查看各种集成作业的日志，以便了解集成作业的详细信息，辅助解决过程中的问题。持续交付版本管理作为发布人员，能够管理各个版本软件包，以便快速得到任意版本的软件部署包。系统设置一个站点存储软件包，每个软件包存储版本更新历史，对外提供HTTP协议的访问接口，支持上传、查看、下载软件包。部署配置作为部署人员，可以配置需要部署的版本、目标主机以及参数设置，以便系统能够自动完成部署。系统将部署配置信息作为代码纳入配置管理，方便团队成员统一管理和内容评审。配置中的目标主机，可以是明确指定主机名或者IP。这些主机需要是分配给应用使用的资源（有关资源管理，可以参见“控制台”的相关说明），否则无法部署到指定主机。如果指定多台主机，系统会并行执行相同的部署作业。这可以用于部署对等集群系统。系统支持同一个版本的应用部署到多套环境中。自动部署当系统自动触发或者用户请求执行自动部署时，系统创建部署作业，按照部署配置将相应的版本软件包部署到关联的主机上。部署成功后，系统会更新主机资源关联的应用版本信息。如果配置了多套环境，系统顺序执行每套环境的部署。如果配置指定了多台主机，系统会并行启动多个部署作业来执行部署。用户可以手动从控制台触发一套或者多套环境的部署。多套环境的部署策略和自动触发下的处理一致。部署作业管理作为项目成员，可以查看各种部署作业的日志，以便了解部署作业的详细信息，辅助解决过程中的问题。控制台参数作为系统管理员，可以修改参数设置，以便调整系统功能。用户作为系统管理员，可以管理系统的用户，以便工程人员可以使用系统。作为系统管理员，可以对用户进行分组，以便快速调整一组用户的设置。权限系统通过权限管理，设置不同用户在不同工程中的角色，从而控制用户可以执行的操作。资源作为应用管理员，可以为应用添加主机资源，以便控制自动部署可以使用的资源。工程作为应用管理员，可以创建一个或者多个工程，以便更好地组织整个应用的开发和部署。用户创建工程时，系统会自动为工程创建相关联的配置仓库、软件包仓库。部署方案应用自动部署系统以多个组件发布，各个组件力求无状态，以便集群部署，提高系统的可靠性和性能。系统主要组件可以采用的逻辑部署如下图所示。

基础服务节点顶层包::数据库服务顶层包::消息队列服务顶层包::缓存服务系统逻辑部署图系统每个组件的所需要的资源规格如下表：节点类型指标备注控制台节点4c8G管控节点8C16G配置库节点4c8G,3006数据存储引擎节点8C16G基础服务节点8C16G非功能性设计性能系统的性能是一个系统成败的关键所在，在架构设计初期就一定要把系统性能考虑在内，否则等开发完成以后测试发现性能不好就比较难办，通常要花费较长的时间来诊断性能瓶颈，找到提升的办法，甚至要改变架构，伤筋动骨，往往造成项目延期。所以性能设计首先要有明确的性能目标，根据用户和软件本身的性能要求来设计，合适的就是最好的。其次，要有适当的度量标准和量化的性能指标。最后，要有相应的设计策略，具体的测试方法。影响系统性能主要瓶颈在I/O,包括数据库，socket,网络通信，文件等，例如频繁查询数据库并返回大量结果集，频繁操作大文件等，这些昂贵的操作会占用大量的CPU时间。拿系统响应和服务一个事务来说，有几个Roundtrip，要通过哪几层I/O,如何合理的分配这些I/O的调用，降低不必要的I/O,都是进行系统性能设计要考虑的。而有些性能问题在初期并不会表现出来,但当拿到实际上线环境下,存在多用户并发、大数据量的情况下就会暴露出严重的问题。所以性能设计时一定要考虑到I/O,同步，并发，资源争用，以及大数据量等因素。通常，I/O操作、网络响应、差的算法、数据库、以及其他的低效的资源使用都会导致低劣的性能。在性能设计上,我们的主品主要考虑了以下的设计策略：(1)缓存以及缓存层(cachinglayer)在数据层和应用层之间增加数据缓存层,提供全局数据服务。可以大大减少数据库往返次数。与读取数据库和读取大文件(如XML文件)比，读取内存的速度无疑要快的多。所以对经常要访问的数据进行缓存是非常好的实践方法。因为现在系统往往内存很大，可以充分利用大内存，而共享内存更能实现数据并发访问。(2)多线程(multi-threading)现在基本上大部分软件实现多线程或多进程，多线程对单CPU系统还只是顺序利用CPU时间和改善用户体验，多CPU系统才是真正的并行。要注意的是多线程不要争抢访问同一资源而导致部分串行操作，要做到真正的并行操作多线程并不容易。另外，在多线程间同步一个庞大的资源，过多创建线程又没有实现线程池也会导致系统性能下降。(3)负载均衡(loadbalancing)物理上增加地位对等的集群服务器(Cluster)，通过负载分配算法分配相应服务器来相应客户端请求，我们的产品设计充分考虑了系统的可扩展性，所有节点都支持负载均衡，以实现整个系统的无限扩展。(4)数据库优化(databaseoptimization)数据库的优化是一个持续的过程，在架构上，我们支持数据库的读写分离，能对CPU利用率、IOPS、连接数、磁盘空间等实例信息实时监控，并给出相应的SQL语句优化意见，根据需要建立相应的数据库索引。文件系统优化有时候系统性能不好，但当你关闭写log的功能，性能一下子提高很多。因为频繁的打开关闭大log文件时I/O开销非常大，同样记录log到数据库也一样。所以，release版尽量减少写log，或干脆移到裸设备上。频繁打开关闭文件对系统性能下降程度是惊人的，可以通过一些变通办法来减少文件的频繁操作。例如，原来的缓存持久化实现是保存在XML文件，每次要获得一个配置项，都打开XML文件，通过XPath拿到这个配置项的值，这样效率不高，而且容易把这个XML文件lock住；改进的方法是：通过比较XML文件的修改时间(System.IO.File.GetLastWriteTime)判断是否要再次打开文件，大大提高了效率；另一个可以改进的方法是：启动时读取所有配置到一个静态的HashTable，每次要获得一个配置项都从内存HashTable获取，在最后或适当的时候持久化到XML。通过以优化，我们的软件能达到用户要求的以下性能指标：大类指标备注稳定性测试稳定运行时间一周指标系统峰值的60%系统资源CPU使用率＜二75%内存使用率＜二75%磁盘繁忙率＜=75%可靠性软件系统规模越做越大越复杂，其可靠性越来越难保证。应用本身对系统运行的可靠性要求越来越高，软件系统的可靠性也直接关系到设计自身的声誉和生存发展竞争能力。软件可靠性意味着该软件在测试运行过程中避免可能发生故障的能力，且一旦发生故障后，具有解脱和排除故障的能力。软件可靠性和硬件可靠性本质区别在于：后者为物理机理的衰变和老化所致，而前者是由于设计和实现的错误所致。故软件的可靠性必须在设计阶段就确定，在生产和测试阶段再考虑就困难了。软件系统必须是可靠的，一般的人为和外部的异常事件不会引起系统的崩溃；同时系统有较高的可用性，当系统出现问题后能在较短的时间内恢复，而且系统的数据是完整的，不会引起数据的不一致。主机系统能够保持7*24稳定的不间断运行，从系统软硬件平台及网络等方面来保证系统的稳定性；对于所采用的主备服务器方式，若主服务器宕机时，可实时地切换到备用服务器上，用户的应用不受影响。我们的软件目前可靠性可达到如下指标：系统易恢复，RPO<10分钟,RTO<30分钟。具备对交易超时构建、部署异常情况的容错处理。可用性系统采用多个组件单独部署运行的方式组成整个应用，每个组件支持集群部署，可以通过横向扩展来确保系统服务可用性和必要的性能。只要集群中任一实例能够正常运行，就可以保证系统功能基本可用。如果一旦运行中的实例出现故障，可以快速启动新实例并加入集群，从而恢复整个集群的处理能力，进一步保证应用的可用性。系统自身组件的部署采用容器化技术，可以在秒级完成系统启动，实现故障快速恢复。同时结合系统服务管理框架，当服务异常退出时触发自动重启，缩短故障时间窗口。综合采用以上措施可以全面保障系统可用性在评估期内（试运行期间）保证99.9以上（MTTF/（MTTF+MTTR）*100%