分布式核心DevOps平台概要设计Word格式.docx
《分布式核心DevOps平台概要设计Word格式.docx》由会员分享，可在线阅读，更多相关《分布式核心DevOps平台概要设计Word格式.docx（17页珍藏版）》请在冰豆网上搜索。
性能监控模块利用监控代理程序获取性能数据，服务器端收集性能数据，并利用持久化存储工具将数据存入数据库，利用这些数据实现物理机和虚拟机性能的监控。
故障监控模块配置监控主机与服务，并利用监控插件实现检测，将结果信息上传给服务器，服务器端实时监控并产生告警信息。
性能监控、故障监控、告警和统计报表共同构成DevOps平台的监控体系，使系统管理人员可以实时了解大并发服务引擎的运行状况，及时处理异常状况，提高DevOps平台的服务质量。
2.系统需求分析
2.1系统目标
公司股份公司是中国大陆第一家由民间资本设立的全国性商业银行，是我国金融行业的重要组成部分，也是我国银行界金融互联化化的先驱，其直销银行业务突破了传统实体网点经营模式，主要通过互联网渠道拓展客户，具有客群清晰、产品简单、渠道便捷等特点，其充分尊重互联网用户习惯，提供操作便捷的网站、手机银行和微信银行等多渠道互联网金融服务。
为了进一步适应直销银行互联化需求，
（1）用户访问难以预计，应用需要根据访问量调整自身的规模，比如类似淘宝“双十一”凌晨瞬时并发量超过1000万。
未来，随着直销银行业务的不断推进，系统应能承担大规模批量开户、促销活动等高并发交易量的场景。
（2）版本迭代频率高。
直销银行通过互联网直接为客户提供服务，应参考业界的互联网公司产品的推出速度，预计最少1-2周更新一次。
为满足以直销银行为代表的银行业务互联网化需求，分布式核心系统主要包含两个部分，一是将直销银行等应用由传统的IOE架构改造成分布式系统架构，解决应用本身的容量瓶颈；
而是优化直销银行等应用的基础架构，使得这些应用具有更好的扩展性，更便捷的交付能力，为按需可靠资源提供奠定基础，整体需求如图1所示。
图1分布式核心系统总览
本项目主要关注基础设施（资源易管理）、可视化和自动部署、可监测可预警，以应用为核心，关注其部署、配置、运行和运维，简化应用开发和运维的交付复杂度，即DevOps平台应，其具备以下功能：
●开发者进行新版本的应用开发后，应具有应用模板自动制作和发版，按需生成可运行的应用集群的功能。
●运维人员通过可视化界面，选择合适的部署策略，即可完成应用新版本的发布、审计和维护；
●在新版本发布后，系统具有应用监测的能力，并可根据预先设置的策略，完成应用的伸缩管理和容错管理。
为解决以上问题，云平台的构建引入业界先进的DevOps（英文Development和Operations的组合）思想。
DevOps是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。
云平台能够解决应用部署繁琐，开发和运维部门沟通耗时，人工部署复杂易错的问题，有效提升应用部署管理效率。
具体而言，研发基于Docker的云平台实现应用的快速发布、部署，运行与维护管理平台（简称DevOps平台）。
分布式核心系统的应用程序将运行在Docker云平台上。
该平台包含Docker集群管理、应用发布管理和一体化监控。
项目将使用最新的DevOps思想实现应用的快速开发投产，提升版本发布、维护的自动化水平，降低生产维护人员的工作成本和投产风险。
如图2所示，DevOps平台主要由三大子平台组成：
●基础设施平台：
采用Docker集群复用底层物理资源，其目的是实现物理资源的可编程，提高资源利用率；
利用Docker可固化应用运行环境的特点，简化应用部署的复杂度。
●应用发布平台：
应用发布平台用户构建应用和物理资源的映射关系，它采用可视化手段，在帮助运维人员在维护直销银行等应用时，屏蔽底层物理资源分配的复杂性。
●一体化监控：
一体化监控的作用是监测应用（运行在Docker容器上）的可用性，并采用预警机制，预先对可能出现问题的应用进行报警，帮助运维人员快速发现、定位问题，并将应用从失效状态进行恢复。
图2DevOps平台组成
2.2系统特点
a.基础运行平台
为应用提供运行基础环境，具有分时复用物理资源，提高资源利用率能力；
具有固化应用及其运行环境，简化应用部署的能力；
具备高可靠性、高伸缩性、高可用性特点，并提供Restful管理接口。
b.应用发布平台
提供协议接入与解析、负载均衡、生命周期管理、失效恢复与容错等基础服务，可视化整个应用部署流程、部署策略和维护管理。
c.监控管理平台
能够以分布式的方式对数据中心主机、操作系统、数据库、应用服务器和应用的性能数据进行自定义监控和展示。
通过定义复杂的报警逻辑，并采用基于邮件、SMS的报警机制来通知管理员，能够第一时间对问题采取应对措施。
2.3功能需求
（1）运行环境
组件
版本
备注
操作系统
CentOS/Redhat7.1
对比7.0和7.1版本
Docker
1.9.1
对比1.3.2，1.6.1和1.8.3版本
Swarm
1.0.0
对比0.3、0.4和1.0.0版本
Docker-registry
0.9.1
对比0.9.1和2.x版本
（2）兼容性
Swarm集群支持所有Docker指令。
图3列出了应用发布平台的6个子模块和17个功能模块：
图3应用发布平台功能需求
Ø
主机管理：
主机管理提供对物理服务器的管理，包括查看主机列表，连接主机，主机加入集群，主机移出集群，修改主机，删除主机功能；
集群管理：
集群管理是对服务器的统一规划和管理，包括查看集群列表，创建集群，修改集群，应用约束，添加主机，解绑主机，健康检查，恢复集群，删除集群功能；
镜像管理：
镜像管理是对镜像的统一管理，包括查看镜像列表，创建镜像，发布镜像，删除镜像，修正镜像功能；
容器管理：
容器管理是对容器的统一管理，容器中包含的是应用的具体实例。
包括查看容器列表，创建容器，启动容器，停止容器，删除容器，同步容器功能；
负载管理：
负载管理是负载服务器的逻辑实现，直接和负载服务器对接，目前采用nginx做负载均衡。
包括查看负载列表，添加负载，添加应用，移除应用，修改负载，删除负载功能；
仓库管理：
仓库管理是仓库服务器的逻辑实现，直接和仓库服务器对接。
包括创建仓库，修改仓库，删除仓库，同步镜像，查看镜像，查看仓库列表功能；
应用管理：
应用管理是对同一种类型应用的逻辑实现，应用和负载以及集群相关联。
包括查看应用列表，创建应用，修改应用，删除应用；
参数管理：
参数管理是根据不同的类型，在和服务器交互时需要传递的参数的集合。
包括查看参数列表，添加参数，修改参数，删除参数；
模板管理：
模板管理是对于容器提供时统一参数的管理，目前模板是对启动参数的集合，在容器启动时指定模板，即可按照模板指定的参数进行。
包括查看模板列表，添加模板，修改模板，删除模板；
日志管理：
日志管理是对用户操作行为以及用户操作请求的记录。
包括查询日志，日志展示；
用户管理：
用户管理是对平台用户的统一管理。
包括查看用户列表，创建用户，修改用户，删除用户，用户授权功能；
角色管理：
角色管理定义了平台中的角色，并且针对不同的角色赋予不同的权限，包括查看角色列表，角色授权，角色编辑功能；
权限管理：
权限管理定义了平台中可以操作的行为，并且限定了不同用户对同一个权限的可操作性，事项用户行为的隔离。
包括查看权限列表，编辑权限名称功能；
数据总览：
数据总览是对运行在发布平台中所有的资源汇总，包括主机数量，集群数量，负载数据量，仓库数量，镜像数量，容器数量等。
监控管理：
与监控平台互操作，将监控对象按需添加到监控平台中；
报表管理：
可查看周、月、季、年的资源监控信息，并可以按照一个格式导出，形成报表，比如PDF和excel格式；
预警管理：
为监控对象添加预警规则，防止应用因违反某条规则导致失效；
服务管控：
与中间件平台互操作，具有中间件服务升级和降级的能力；
异常处理：
具有流水的补偿和冲正操作客户信息查询、账户信息查询等能力。
c.一体化监控平台
一、容器内监控
状态监控：
状态监控功能需要监控的容器和中间件的状态包括：
✧运行状态
✧关闭状态
性能监控：
（1）Container监控数据主要包括：
✧CPU利用率
✧内存占用率
✧网络读速度
✧网络写速度
（2）DeviceMapper监控数据主要包括：
✧DeviceMapper数据总大小
✧DeviceMapper数据已使用量
✧DeviceMapper元数据总大小
✧DeviceMapper元数据使用量
（3）Dubbo监控（中间件提供接口）
（4）Zdal监控数据（中间件提供接口）
（5）Sequence监控（中间件提供接口）
（6）其它监控
二、中间件监控
（7）Zookeeper监控数据主要包括：
✧平均延迟
✧最大延迟
✧最小延迟
✧接收包数量
✧发送包数量
✧服务器角色
✧Znode数量
✧Watch数量
✧Ephemerals数量
✧数据大小
✧Follower数量
✧连接数
✧已打开文件数
✧最大文件数
（8）Redis监控数据主要包括：
✧client连接数
✧client阻塞数
✧内存使用量
✧Human内存使用量
✧Rss内存使用量
✧Peak内存使用量
✧Peak_human内存使用量
✧Lua内存使用量
✧数据加载量
✧Rdb数据改变量
✧Rdb数据保存量
✧Rdb数据正在写入量
✧集群有效性状态
✧客户端最大输入缓存
✧客户端最长输出缓存
✧客户端连接数
✧key命中次数
✧key未命中次数
✧内存碎片率
✧cpu使用率
（9）Nginx监控数据主要包括：
✧接收的请求数
✧活跃连接数
✧读取客户端的连接数
✧相应数据到客户端的数量
✧处理的请求数
（10）ActiveMQ监控数据主要包括：
✧主体数
✧队列数
✧最大队列长度
✧订阅节点数量
（11）Tomcat监控数据主要包括
✧最大连接数
✧并发线程数
✧内存使用
✧类加载个数
（12）Mysql监控数据主要包括
✧Key_writes将一个键值块物理写入磁盘的次数
✧Max_used_connections同时使用的连接的最大数目
✧Open_tables打开表的数量
✧Opened_tables已经打开的表的数量
✧Questions发往服务器的查询的数量
✧Slow_queries要花超过long_query_time时间的查询数量
✧Threads_connected当前打开的连接的数量
✧Threads_running不在睡眠的线程数量
三、监控报警
支持邮件和短信报警。
2.4非功能需求
支持大规模应用场景：
单个Docker集群可管理不小于100台物理机，且易于扩展；
性能需求：
能够快速响应系统的状态同步、查询等请求，同步间隔不超过30秒，查询响应延迟小于2秒；
安装与配置简单，学习成本低：
基础运行平台可以通过一键安装脚本进行安装。
支持多种客户端、跨异构平台：
支持多种客户端，如Web浏览器、Java客户端等；
可运行在多种操作系统上，如Linux、Unix和Windows等；
可定制和可扩展的安全机制：
提供可配置和可扩展的，满足公司需求安全实现；
灵活的应用部署机制：
支持本地、FTP和War上传等多种机制。
满足多租户部署应用的大规模使用场景，单个Docker集群实例的监控规模不小于100台物理机，且易于扩展，具备扩展支持到1000台物理服务器的能力；
能够快速响应系统的状态同步、查询等请求，同步间隔不超过30秒，查询响应延迟小于5秒；
可靠性需求：
监控系统不能存在单点故障，能够应对多种异常情况，可用性指标达到99.99%。
2.5技术指标
a.基础设施平台
1）私有软件仓库的搭建；
2）提供RestfulAPI接口；
1）支持多种客户端，包括，Web浏览器、Java客户端等；
2）支持多种操作系统，包括，Linux和Windows等；
3）提供RestfulAPI接口；
4）数据库设计满足第三范式；
1）能够从物理设施获取CPU、内存、磁盘、网络等资源的度量信息；
2）能够对度量以及关联性进行分析，发现异常并通知系统管理员；
3）能够维护至少1个月的集群运行数据信息和日志信息；
4）应用组件的加载速度小于3秒，组件更新造成的服务中断小于2秒。
2.6建设任务
研制DevOps平台为应用系统提供开发、部署、运行、维护的基础环境，从而提升具备大并发、高可用特性的应用服务系统的研制效率与质量。
DevOps平台软件主要分为基础运行平台，应用发布平台和一体化监控平台等核心组成部分，提供协议接入与解析、负载均衡、生命周期管理、错误容忍与失效恢复等基础服务，并具备高可靠性、高伸缩性、高可用性、易定制性等特点。
a.弹性服务
服务的规模可快速伸缩，以自动适应业务负载的动态变化。
用户使用的资源同业务的需求相一致，避免了因为服务器性能过载或冗余而导致的服务质量下降或资源浪费。
b.资源池化
资源以共享资源池的方式统一管理，将资源分享给不同用户，资源的放置、管理与分配策略对用户透明。
c.自主监控管理
提供监控和管理功能，用于统一管理集群中的各类软件及硬件，以自动化、图形化的方式完成各类基础服务的安装和配置，能够监控正在使用的应用服务信息、数据库及存储状态。
3.系统总体设计
3.1设计原则
系统方案设计将遵循以下原则：
a.先进性原则
系统架构先进，支持底层平台与业务应用的松耦合和彼此独立演化，并各自形成产品向外提供解决方案、具备未来面向社会服务的扩展能力。
b.扩展性原则
系统架构设计应适应未来社会化运营时用户规模大的特点，支持底层核心平台的平滑扩展，支持业务系统的标准化接入，支持软件功能的“即插即用”，提供规模化运营服务能力。
c.开放性原则
系统面向全社会开放，并将积极与其他相关信息系统互连，整合相关各方信息和数据，增加数据共享和数据交换的覆盖面，并通过二次开发转变为服务和应用。
d.易维护原则
系统架构设计应使系统的运行维护简单易行、可操作、成本低，提供对软硬件资源监控管理的一体化解决方案，操作简单，易于维护。
e.标准化原则
系统建设将严格遵循国家和行业现有标准规范，所有在系统中采用的技术、交换的数据都是基于通用技术标准。
3.2系统总体架构
系统的总体架构如图4所示，包括基础设施平台、应用发布平台和一体化监控平台三个部分：
负责将计算、网络和存储资源抽象成容器，并作为直销银行等应用的载体；
通过可视化、流程化和自动化方式，刻画出直销银行等应用的部署、运行和维护模型，屏蔽应用管理的复杂性；
●一体化监控平台：
监控容器、中间件和应用，采用预警和报警机制，保证直销银行等应用的可靠性。
图4总体架构
3.2.1基础设施平台功能模块
容器虚拟化组件：
安装和部署在物理服务器上，使得物理资源可编程，封装成容器作为物理资源的封装以及应用的运行支撑环境；
容器存储组件：
容器实例化后本地使用的devicemapper，它是容器运行时，数据持久化的物理载体；
容器网络组件：
即容器使用桥接或者OVS模块，它是容器于外界互联互通的基础；
容器镜像仓库组件：
它是容器镜像集中存储模块，用以解决本地容器镜像难以在其它容器节点复用的问题；
容器集群管理组件：
它将多个容器虚拟化抽象成一台逻辑上的实体，用户只需要访问该台服务器，即可完成与所有容器虚拟化服务器的交互。
集群管理组件主要包括4大功能：
（1）资源调度：
集群管理组件可自动将应用容器部署到空闲的物理服务器上；
（2）信息同步：
集群管理组件统一维护全局状态，即维护容器及其运行主机的关联关系；
（3）生命周期管理：
运行时可动态控制容器服务器的规模大小；
（4）配置信息：
容器集群组件需要将容器规模信息进行持久化，持久化支持文件、etcd等多种策略；
3.2.2应用发布平台功能模块
网络管理：
管理容器的虚拟网卡个数和类型；
其中，一台容器创建虚拟网卡的个数不得超过6个；
创建的类型可以是Native、NAT和OVS。
部署管理：
支持可视化应用部署，支持基于nginx的应用集群构建；
发布管理：
支持灰度发布等多种策略；
互操作管理：
支持与监控平台的互操作，可将监控对象按需添加到监控平台中；
运维和报表管理：
3.2.3一体化监控平台功能模块
主机监控及预警：
主机包括CPU、内存、网络等关键属性；
容器监控及预警：
容器包括CPU、内存、Devicemapper等关键属性；
中间件监控及预警：
主要涉及ActiveMQ、Mysql、Tomcat、Redis、Zookeeper、Nginx6类中间件；
应用监控及预警：
主要涉及Dubbo、Sequence和Zdal三类。
高可用保障：
包括监控平台数据库，采集器的高可用。
3.3业务\数据流程
3.3.1基础设施平台
基础运行环境主要是物理资源的抽象，是直销银行应用的资源载体，其目的是构建应用与其资源的映射关系。
当明确直销银行实例需求后，该请求会发送给Docker集群（Swarm），Swarm负责全局Docker服务器的资源管理，构建统一的资源视图。
并根据一定的均衡算法，将应用实例从Docker仓库从下载到指定Docker服务器上，并进行实例化，如图5所示，直销银行资源需求映射到容器（封装应用及其运行环境），其本质包含一系列步骤，如图5所示。
图5基础运行平台流程
执行步骤是同步操作，具体流程为：
用户请求Docker集群组件；
Docker集群维护Docker服务器的全局信息，采用一定的负载均衡算法，将用户对容器生命周期管理需求转发给具体Docker服务器；
Docker服务器接收到容器生命周期管理请求后，会主动和私有Docker仓库进行交互，比如说启动某一个应用容器镜像，其本质是Docker服务器对Docker仓库进行查询，并将相关容器镜像下载到本地；
Docker服务器获取容器镜像后，调用Docker本身API，对其进行生命周期操作；
Docker集群接收容器生命周期管理的执行结果，并将该结果返回给用户
3.3.2应用发布平台
应用发布平台采用典型的三层架构，包括Web服务器和数据库服务器，它是可视化、流程化和自动化管理应用得前提，其处理步骤如图6：
用户请求访问应用发布平台；
用户请求首先路由
升级会员 