云计算PaaS平台总体设计说明书

1、PAGE 云计算PaaS平台 总体设计说明书第 PAGE I 页 共 NUMPAGES 17 页云计算PaaS平台总体设计说明书目 录 TOC o 1-4 h z u HYPERLINK l _Toc535245518 1.引言 PAGEREF _Toc535245518 h 4 HYPERLINK l _Toc535245519 1.1目的 PAGEREF _Toc535245519 h 4 HYPERLINK l _Toc535245520 1.2背景 PAGEREF _Toc535245520 h 4 HYPERLINK l _Toc535245521 1.3术语和缩略语 PAGEREF

2、 _Toc535245521 h 4 HYPERLINK l _Toc535245522 1.4参考资料 PAGEREF _Toc535245522 h 4 HYPERLINK l _Toc535245523 1.5约定 PAGEREF _Toc535245523 h 4 HYPERLINK l _Toc535245524 2.概述 PAGEREF _Toc535245524 h 5 HYPERLINK l _Toc535245525 2.1.产品描述 PAGEREF _Toc535245525 h 5 HYPERLINK l _Toc535245526 2.2.假设与约束 PAGEREF _

3、Toc535245526 h 5 HYPERLINK l _Toc535245527 2.3.环境、工具及相关约定 PAGEREF _Toc535245527 h 5 HYPERLINK l _Toc535245528 2.3.1.开发环境 PAGEREF _Toc535245528 h 5 HYPERLINK l _Toc535245529 2.3.2.运行环境 PAGEREF _Toc535245529 h 5 HYPERLINK l _Toc535245530 3.总体结构 PAGEREF _Toc535245530 h 7 HYPERLINK l _Toc535245531 3.1.总

4、体设计思路 PAGEREF _Toc535245531 h 7 HYPERLINK l _Toc535245532 3.2.系统逻辑图 PAGEREF _Toc535245532 h 7 HYPERLINK l _Toc535245533 3.3.子系统逻辑图 PAGEREF _Toc535245533 h 8 HYPERLINK l _Toc535245534 3.4.生产平台部署物理架构图 PAGEREF _Toc535245534 h 10 HYPERLINK l _Toc535245535 3.5.开发测试平台部署物理架构图 PAGEREF _Toc535245535 h 11 HYP

5、ERLINK l _Toc535245536 3.6.生产环境的灾备部署架构图 PAGEREF _Toc535245536 h 12 HYPERLINK l _Toc535245537 3.7.子系统设计 PAGEREF _Toc535245537 h 13 HYPERLINK l _Toc535245538 3.7.1.平台运行时设计 PAGEREF _Toc535245538 h 14 HYPERLINK l _Toc535245539 3.7.2.控制台 PAGEREF _Toc535245539 h 14 HYPERLINK l _Toc535245540 3.7.3.平台定时伸缩 P

6、AGEREF _Toc535245540 h 15 HYPERLINK l _Toc535245541 3.7.4.用户管理 PAGEREF _Toc535245541 h 16 HYPERLINK l _Toc535245542 3.7.5.租户管理 PAGEREF _Toc535245542 h 17 HYPERLINK l _Toc535245543 3.7.6.提醒服务 PAGEREF _Toc535245543 h 18 HYPERLINK l _Toc535245544 3.7.7.服务监控 PAGEREF _Toc535245544 h 18 HYPERLINK l _Toc53

7、5245545 3.7.8.平台监控 PAGEREF _Toc535245545 h 19 HYPERLINK l _Toc535245546 3.7.9.审计子系统架构设计 PAGEREF _Toc535245546 h 20 HYPERLINK l _Toc535245547 3.7.10.IaaS适配架构设计 PAGEREF _Toc535245547 h 20 HYPERLINK l _Toc535245548 3.7.11.应用弹性伸缩架构设计 PAGEREF _Toc535245548 h 21 HYPERLINK l _Toc535245549 3.7.12.日志处理架构设计 P

8、AGEREF _Toc535245549 h 22 HYPERLINK l _Toc535245550 3.7.13.MySQL Service Broker设计 PAGEREF _Toc535245550 h 23 HYPERLINK l _Toc535245551 3.7.14.Redis 服务设计 PAGEREF _Toc535245551 h 25 HYPERLINK l _Toc535245552 3.7.15.RabbitMQ 服务设计 PAGEREF _Toc535245552 h 25 HYPERLINK l _Toc535245553 3.7.16.Jenkins 服务设计

9、PAGEREF _Toc535245553 h 26 HYPERLINK l _Toc535245554 3.8.业务场景/流程设计 PAGEREF _Toc535245554 h 28 HYPERLINK l _Toc535245555 3.8.1.业务场景/流程清单 PAGEREF _Toc535245555 h 29 HYPERLINK l _Toc535245556 4.数据标准使用及数据结构设计 PAGEREF _Toc535245556 h 29 HYPERLINK l _Toc535245557 4.1.使用的信息项清单 PAGEREF _Toc535245557 h 29 HY

10、PERLINK l _Toc535245558 4.2.数据结构设计 PAGEREF _Toc535245558 h 29 HYPERLINK l _Toc535245559 5.接口设计 PAGEREF _Toc535245559 h 30 HYPERLINK l _Toc535245560 5.1.系统外部接口 PAGEREF _Toc535245560 h 30 HYPERLINK l _Toc535245561 5.2.子系统间接口 PAGEREF _Toc535245561 h 30 HYPERLINK l _Toc535245562 6.复用设计 PAGEREF _Toc53524

11、5562 h 31 HYPERLINK l _Toc535245563 6.1.使用的复用资源 PAGEREF _Toc535245563 h 31 HYPERLINK l _Toc535245564 6.2.创建的复用资源 PAGEREF _Toc535245564 h 31 HYPERLINK l _Toc535245565 7.非功能性的设计 PAGEREF _Toc535245565 h 31 HYPERLINK l _Toc535245566 7.1.xxx指标设计 PAGEREF _Toc535245566 h 31 HYPERLINK l _Toc535245567 7.1.1.

12、设计思路 PAGEREF _Toc535245567 h 32 HYPERLINK l _Toc535245568 7.1.2.实现要点 PAGEREF _Toc535245568 h 32 HYPERLINK l _Toc535245569 7.1.3.对部署方案的约束 PAGEREF _Toc535245569 h 32 HYPERLINK l _Toc535245570 7.2.xxx指标设计 PAGEREF _Toc535245570 h 32 HYPERLINK l _Toc535245571 7.2.1.设计思路 PAGEREF _Toc535245571 h 32 HYPERLI

13、NK l _Toc535245572 7.2.2.实现要点 PAGEREF _Toc535245572 h 32 HYPERLINK l _Toc535245573 7.2.3.对部署方案的约束 PAGEREF _Toc535245573 h 32 HYPERLINK l _Toc535245574 8.详细设计文档规划 PAGEREF _Toc535245574 h 33引言目的 MACROBUTTON TableDeleteTable 双击此处添加本文档的目的 本文档对PaaS平台进行总体架构设计，目标用户为设计人员、开发人员、测试人员、项目管理人员。背景 MACROBUTTON Tabl

14、eDeleteTable 双击此处添加本文档的背景 目前银行IT并没有PaaS平台，应用的开发、测试、上线、试运行都是按照传统的金融IT发布流程进行。对于以需要快速响应、快速发布、迭代更新为特征的互联网应用来说，传统IT已经难以满足这种快速发布的需要，主要表现在：环境准备时间过长: 产品运行所需要的硬件、软件环境往往需要在上线前几个月就要申请、准备，在产品上线前就需要规划出产品今后可能用到的资源数量；无弹性扩展，扩容难：产品投产后很难再变更应用的部署规模及资源配给，难以应付突发流量，难以应对日益增长的数据量； 测试环境与生产环境差异较大：应用的测试环境和生产环境存在较大差异（例如生产环境是集群

15、部署，而测试环境则只是单节点部署），测试案例并不能完全模拟生产环境；应用的配置信息在不同的环境需要手工修改（例如修改配置参数），增加了出错几率；上线过程复杂：上线过程除了开发人员外，往往需要运维人员、DBA等各个环节的人员共同参与，或修改配置、或部署应用、或执行数据库脚本，增加了上线人力成本的投入，降低了上线投产的效率； 建设周期长：部署周期长，软件定制开发慢，与外围系统接口复杂，实施推广需要大量的实施人力完成。 通过PaaS云的建设解决以上问题。术语和缩略语 MACROBUTTON TableDeleteTable 双击此处添加本文档的术语和缩略语 PaaS： Platform as a S

16、ervice,平台服务，把应用平台作为服务提供PCF： Pivotal Cloud Foundry Pivotal的PaaS云平台 参考资料 MACROBUTTON TableDeleteTable 双击此处添加本文档所引用的参考资料 应完整列出本文档所参考或引用的资料，可包括项目其他文档。标识出每个文件的名称、编号（如果有）、日期、出版组织、获取来源，可以通过在此处定义、引用本文档的附录、或者引用其它文件的方式来提供。约定 MACROBUTTON TableDeleteTable 双击此处添加本文档的约定 说明在编写或阅读本文档时的一些约定，如需求编号的编码规则、图例规则等，可以通过在此处定

17、义、引用本文档的附录、或者引用其它文件的方式来提供。概述 MACROBUTTON TableDeleteTable 双击此处添加 银行PaaS平台建设，为应用提供统一的云平台，大量实现应用平台相关的自动化和可用性进一步提高，比如灰度发布、开发部门的持续集成(CI)和DevOps(开发运维)、应用监控、及进一步提升应用的可用性。这些功能大多属于PaaS功能，通过PaaS平台的建设，并且逐步把应用迁移到PaaS平台，可以进一步简化运维，特别是应用部署的标准化和简化；也可以进一步提高硬件资源池的使用效率，通过PaaS云的自动弹性伸缩、多重的应用故障自动恢复、平台的高可用性区等进一步提高平台的高可用性

18、，实现应用的在线升级包括灰度发布等，并通过平台来实现应用日志的集中管理。对开发部门来说，通过平台支持的敏捷开发、CI和DevOps来进一步提高开发效率，缩短从需求到IT实现的周期。产品描述 MACROBUTTON TableDeleteTable 双击此处添加 PaaS平台构建了开发、测试、生产运行环境。通过BuildPack构建包提供了银行主要的几种应用平台，包括dk1.6，jdk1.7，jdk1.8 （分OpenJDK和Oracle JDK两版本）、IBM JDK1.6、JBoss EAP6.2、Tomcat7、Tomcat8等。提供的服务包括mySQL、RabbitMQ、Redis、Je

19、nkins等。除了平台和服务，还提供了统一的日志聚合和日志管理，应用弹性伸缩、平台定时伸缩、应用监控、服务监控、平台监控、审计等功能。假设与约束 MACROBUTTON TableDeleteTable 双击此处添加 列出可能影响设计的假设条件和约束条件。这里不应包含人力资源、时间等项目管理类的约束条件。此节需要具体包含什么内容尚不明确，须在后续试点项目重点跟进。环境、工具及相关约定开发环境 MACROBUTTON TableDeleteTable 双击此处添加 dk1.6，jdk1.7，jdk1.8 （分OpenJDK和Oracle JDK两版本）以及IBM JDK1.6的Buildpack

20、；定制以JBoss EAP6.2为应用服务器的Buildpack； 定制以Tomcat7、Tomcat8为应。Tomcat8等。提供的服务包括mySQL、RabbitMQ、Redis、Jenkins等。除了平台和服务，还提供了统一的日志聚合和日志管理，应用弹性伸缩、平台定时伸缩、应用监控、服务监控、平台监控、审计等功能。运行环境 MACROBUTTON TableDeleteTable 双击此处添加 参照可行性分析报告，说明运行环境的软硬件要求。例如数据库服务器的配置要求、应用服务器的配置要求等。如果该系统对硬件敏感性高，则必须对硬件要求（如、内存、存储、带宽等）进行详细的说明。Tomcat8

21、等。提供的服务包括mySQL、RabbitMQ、Redis、Jenkins等。除了平台和服务，还提供了统一的日志聚合和日志管理，应用弹性伸缩、平台定时伸缩、应用监控、服务监控、平台监控、审计等功能。总体结构 MACROBUTTON TableDeleteTable 双击此处添加 本章内容须在后续试点项目重点跟进。总体设计思路总体设计思路是以PCF提供的产品功能为基础，加上一定的定制和开发来实现所有的需求功能，同时，考虑主要的非功能要求，比如高可用性、灾备、性能、安全性等。在PCF现有的产品特性基础上，定制实现非功能性需求。系统逻辑图 MACROBUTTON TableDeleteTable 双

22、击此处添加 根据IT系统架构图编制标准，绘制系统逻辑图，说明本软件产品和其它软件产品的关联关系。如下图为银行PaaS双活架构图，在深圳和上海各部署一套PCF，通过一些双活的配置，实现两地PCF的双活。最前端是一个DNS实现两个PCF的域名解析，分别把PaaS应用访问域名(*假定是此域名)、深圳PaaS系统域名(*)和上海PaaS系统域名(*)统一泛域名解析到一个F5的负载均衡器，而F5把深圳PaaS系统域名(*)请求转发到深圳PCF，把上海PaaS系统域名(*)统一泛域名请求转发到上海PCF上。而应用域名*请求则配置转发策略，不同的应用可以配置不同的转发策略，比如90%的请求转发到深圳PCF，

23、10%的请求转发到上海的PCF，要求转化的时候配置Session亲和性，确保同一个Session只会转发到一个PCF。每个PCF都会需要配置自己的系统mySQL HA，可以选用PCF自带的mySQL服务，也可以采用外部的DBaaS数据库。而对PCF定制的应用，则主要访问银行DBaaS数据库。除了采用F5作为请求分发，也可以采用HA Proxy做请求分发。如下图采用HA Proxy做请求分发的逻辑架构图。配置两台高配的X86虚机做HA Proxy服务器，建议每台HAProxy服务器配置为8G内存，12vCPU。每台HA Proxy上安装HA Proxy和KeepAlive软件。两台HA Prox

24、y配置出虚拟IP(VIP)，在DNS中把应用访问域名、深圳PaaS系统域名和上海PaaS系统域名的都解析到VIP。通过对HA Proxy的负载算法进行配置(URI配分发权重)，可以对不同的应用分发不同的流量到深圳PCF集群或是上海PCF集群。根据对目前银行的F5使用情况的了解，主要是5000S型，可以支持每秒新建并发连接35万，最大的在线长连接为2400万。而采用HA Proxy的服务器，性能无法和F5同等，因为F5有专用的硬件加速芯片，根据一些测试经验，在高配的X86服务器上，记过优化，HA Proxy的最大在线长连接可能可以达到千万。本方案建议采用F5作为请求分发均衡器。 子系统逻辑图如下

25、为模块逻辑图： MACROBUTTON TableDeleteTable 双击此处添加 根据IT系统架构图编制标准，绘制各子系统的模块逻辑图，说明各子系统的模块划分及模块间关系。列出所有模块，依次说明各模块的功能以及该模块与其他模块间的协作方式。如：交易处理模块负责接受渠道提交的投保、撤单等业务请求，通过网关对接模块最终发送到保险公司系统，所记录的交易记录为清算等其它模块提供数据基础。如下图，为基于PCF的银行PaaS系统逻辑架构图，包括银行用到的PCF内置模块，定制模块，以及和外部模块的接口。这是对PCF现有模块的裁剪，有些需要定制，有些可以直接用，有些需要和银行的系统集成，如和用户目录、日

26、志集中处理等模块的集成。根据银行的需求在对PCF模块进行裁剪后，需要定制的子系统分为如下三大群，分别是应用运行时、服务和PCF自身功能的定制：应用运行时，为应用提供运行环境，包括：Tomcat 7/8JDK 1.6(OpenJDK,IBM JDK,Oracle JDK)JDK 1.7(OpenJDK, Oracle JDK)JDK 1.8(OpenJDK, Oracle JDK)JBOSS EAP V6.2PCF的应用运行时基于PCF的应用平台构建规范BuildPack的规范进行构建。服务，基于PCF自身提供或是定制的服务，为应用的运行提供服务支撑：MySQLRedisRabbitMQJenk

27、insPCF提供了Service Broker API V2，通过对这些Service Broker的API来实现每个服务，同时通过PCF BOSH API来实现服务虚机的部署。PCF平台自身定制功能，针对银行的需求，对PCF平台进行定制，包括：提醒服务服务监控平台监控审计租户管理用户管理平台定时伸缩应用弹性伸缩集中日志管理控制台IaaS适配PCF的自身定制功能是在PCF现有提供的功能基础上，通过PCF提供的API进行定制，实现和需求相结合的功能。生产平台部署物理架构图 MACROBUTTON TableDeleteTable 双击此处添加 根据IT系统架构图编制标准，绘制应用部署图，说明程序

28、实体和数据实体的部署情况，以及各部署节点的软硬件环境要求。物理架构设计原则如下：3系统部署分为生产环境和开发测试环境。如下为物理部署逻辑架构图：。PaaS在深圳和上海分别部署一套PCF集群，深圳5台X86服务器配置为一个PCF集群，一个集群又分两个高可用性区，3台X86为组成一个vSphere集群1，做成一个PCF的高可用性区A，另外2台X86为组成一个vSphere集群2，做成一个PCF的高可用性区B。通过配置两个高可用性区， PCF的部署自动分布在两个高可用性区，无论是PCF部件、还是应用实例还是服务，都分布在两个高可用性区，确保没有单点故障根据逻辑架构设计，物理资源分为三大池，一个是应用

29、资源池，二是PCF部件池，第三的服务池。PCF部件池部署PCF的各个部件，每个部件都做HA或是集群，确保每个部件有2份以上，考虑到未来并发访问量会比较大，要至少配5个Router部件。应用资源池为DEA池，作为PaaS应用容器，根据资源的容量计算每个DEA的CPU、内存、磁盘额度，至少运行16个以上DEA。服务资源池部署Redis、RabbitMQ、mySQL等服务，所有的服务都支持HA或是集群，确保高可用性。通过资源池的方式提供资源共享程度，提高资源利用率。通过资源分池，提高安全隔离性开发测试平台部署物理架构图 MACROBUTTON TableDeleteTable 双击此处添加 根据IT

30、系统架构图编制标准，绘制应用部署图，说明程序实体和数据实体的部署情况，以及各部署节点的软硬件环境要求。如下为开发测试环境的物理部署逻辑架构图：。和生产平台的部署不一样，开发测试环境只在深圳部署一套PCF，但是一套PCF也做两个高可用性区，5台X86服务器做成一个vSphere集群，同时配置为一个PCF高可用性区。和生产平台的部署不一样，开发测试环境需要配置更多的存储，因为不同的部门都会来使用开发测试环境，每个部门都会部署开发测试的应用。另外，因为以管理的方式访问PCF的更多，需要多配置PCF的Cloud Controller实例数，实现应用生命周期管理的大并发量访问。DEA在测试环境也需要配置

31、的更多，可以容纳更多的应用实例。开发测试环境的服务池也需要配置的更大，因访问为不同的租户要PCF服务池，要为不同的租户配置服务实例。和生产环境不一样，在测试环境有Jenkins服务，而在生产平台没有Jenkins服务。 生产环境的灾备部署架构图 MACROBUTTON TableDeleteTable 双击此处添加 根据IT系统架构图编制标准，绘制应用部署图，说明程序实体和数据实体的部署情况，以及各部署节点的软硬件环境要求。如下为生产环境的灾备部署架构图：。在深圳和上海分别部署一套PCF，深圳的生产部署环境如3.5章节，上海的环境和深圳部署架构一样。设置不同的域名，预留不同的IP地址池。应用部

32、署是，在应用部署的Web Console中分别往深圳PCF和上海PCF部署应用，等两地的应用均部署成功再返回。配置Service和Service Broker的时候两边一样配置，生产一样的Service名和Service Broker的Service Plan。用户管理统一链接到银行的AD上。MySQL Service使用外部的银行MySQL as a Service,做一个Broker即可。Redis服务两边不复制。RabbitMQ通过脚本实现两边的元数据同步。平台监控采用Zabbix，在监控数据采集的时候分别往上海和深圳两个Zabbix服务器发一份。PCF采用两个内部mySQL数据库PCF

33、的系统数据库，由于mySQL有HA功能，可以避免数据库的单点故障。深圳和上海两个PCF分别用各自的内置mySQL HA集群。子系统设计 MACROBUTTON TableDeleteTable 双击此处添加 根据银行总行信息技术部IT系统清单管理规范），定义出子系统，说明本软件产品和其它软件产品的关联关系。子系统清单子系统编号子系统名称配置系统的单元名称(可选)关联系统编号/子系统编号关联关系的描述PASS.01平台运行时PASS.02控制台PASS.01控制台应用部署在平台运行时PASS.03平台定时伸缩PASS.01平台定时伸缩应用部署在平台运行时PASS.04用户管理PASS.05租户管

34、理PASS.06提醒服务PASS.07服务监控PASS.08平台监控PASS.09审计PASS.10IaaS适配PASS.11应用弹性伸缩PASS.12集中日志管理PASS.13MySQL服务BrokerPASS.14Redis服务PASS.15RabbitMQ服务PASS.16Jenkins服务平台运行时设计应用运行时，为应用提供运行环境，包括以下运行时：Tomcat 7/8JDK 1.6(OpenJDK,IBM JDK,Oracle JDK)JDK 1.7(OpenJDK, Oracle JDK)JDK 1.8(OpenJDK, Oracle JDK)JBOSS EAP V6.2以上平台运

35、行时均是通过PCF的BuildPack来实现的，而PCF的BuildPack有相应的规范，根据规范即可实现相应的Buildpack。buildpack是工作在CloudFoundry这个大框架下的，尊从一些规范，规范要求buildpack至少含有一个bin目录，bin目录下有三个文件，文件名固定，分别是：detect # 这个文件的作用是侦测你的项目，比如是个Java项目 or php项目，用的什么Runtime和Framework之类的compile # 这是buildpack的核心文件，一般作用就是去拉取相应的Runtime（e.g. python2.7/ruby1.9.3）下来，做一下配

36、置放到指定位置，拉取相应的Framework（e.g. Flask/Django）下来，做一下配置，放到指定位置release # 这个文件最终要求输出一个yaml，来描述如何启动app之类的三个脚本由Cloudfoundry顺次执行。根据Buildpack的规范，我们可以从OpenJDK/Oracle JDK/IBM JDK等生产相应的Buildpack。控制台控制台是部署在PCF上的一个应用，供不同的角色登录使用，如管理员登录到控制台进行系统管理、设定等，租户管理员登录控制台设置权限、分配资源，普通用户登录控制台部署应用、监控应用、绑定服务、管理应用等。控制台分别在深圳和上海两个PCF上部

37、署，访问同一个DBaaS数据库。平常只访问深圳PCF上部署的console应用，在Console应用中如果有对PCF的操作，会通过CF SDK分别访问深圳PCF和上海PCF，使得在两边都有操作，比如通过console部署应用或是绑定服务，console会控制分别在深圳PCF上和上海PCF上部署同一应用，绑定同一服务名，虽然深圳的服务和上海的服务名字相同，但是各自运行在各自的PCF上。虽然角色不一样，但是Console是一个独立的应用，部署在PCF中，如下为控制台的技术架构。控制台开发为一个war包应用，部署在PCF DEA，作为PCF的一个应用。控制台应用分为3大模块，一个是GUI，也即Web

38、界面，符合招呼Web风格的界面，主要是基于jQuery界面控件和JavaScript实现。第二是基于Spring MVC的业务逻辑模块，界面各个业务功能的Java实现，其中部分业务会访问数据，这部分还包括审计模块，详见审计架构设计。第三是把控制台要用到的CF API封装为一个CF SDK，直接提供java接口供MVC业务逻辑实现部分实现，CF SDK调用PCF提供的标准的Restful的API。数据库采用银行提供的DBaas数据库服务。由于银行现有基于AD的用户目录，一方面PCF可以配置和AD的SSO，也即AD的用户可以登录到PCF，但是登录到PCF以后，还需要选择用户在什么组织架构，用户在A

39、D的组织架构和在PCF的组织架构的映射关系可以保存在mySQL数据库中，用户第一次登录PCF的时候要选择相应的PCF组织架构。而在MVC的业务逻辑实现部分，也可以实现和AD的SSO，这样用户在现有的应用环境中登录以后可以直接进入Console。平台定时伸缩平台定时是部署在Ops上的一个应用，也即根据Ops安装包规范开发的的一个Ruby程序，由管理员登录使用。平台定时伸缩Ruby应用分为两大模块，一个是设置部分，包括配置定时伸缩的界面，如伸缩起始结束时间，伸缩多少虚机。另外就是伸缩的实现，通过调用Ops提供的API把伸缩的虚机配置发送给Ops,同时调用BOSH API，通过BOSH API来实现

40、虚机的增加和减少，从而实现预定的平台伸缩。程序包还包括一个定时器，根据预定的时间定时调用伸缩的BOSH API和Ops API。另外，平台定时伸缩还需要配置一个数据库服务，采用PCF内置的mySQL数据库服务，伸缩策略、伸缩时间、伸缩记录等均需要写如数据库。用户管理用户管理子系统技术架构和控制台类似，也是部署在PCF上的一个应用，主要供管理员登录到控制台进行用户管理。用户管理分为两大逻辑模块，一个是和AD域的集成，一个是非AD用户管理，包括用户创建、停用、删除、权限分配等。由于银行现有基于AD的用户目录，一方面PCF可以配置和AD的SSO，也即AD的用户可以登录到PCF，但是登录到PCF以后，

41、还需要选择用户在什么组织架构，用户在AD的组织架构和在PCF的组织架构的映射关系可以保存在mySQL数据库中，用户第一次登录PCF的时候要选择相应的PCF组织架构或是根据组织架构映射确定用户在PCF的组织架构。而在MVC的业务逻辑实现部分，也需要实现和AD的SSO，这样用户在现有的应用环境中登录以后可以直接进入Console。系统要用创建数据库，采用PCF内置的PCF mySQL数据库，数据库包括组织架构关系等，目前的组织架构关系如如下的二级架构：此组织架构的三级部门和PCF的Org对应，四级部门和Space对应。对于非AD的用户，通过PCF的API可以创建用户、分配到组织架构和项目中去、配置

42、资源权限、停止用户、删除用户等。非AD的用户一方面要在数据库中配置组织架构关系，另外，在通过PCF API创建用户、配置PCF角色以后，要把相应的信息写入数据库，用于统一的用户管理。租户管理租户管理子系统技术架构和控制台类似，也是部署在PCF上的一个应用，主要供管理员登录到控制台进行租户管理。租户管理的主要功能通过PCF API实现，如创建租户、修改租户信息等。由于部门信息PCF不内置支持，比如磁盘额度控制，需要再写数据库，把额度配置信息写入数据库。同时每次部署应用的时候，把应用的磁盘信息更新到租户表，如果在Push应用的发现Push应用的用户所属租户磁盘额度不够，需要告警，并终止应用Push

43、。如果可以Push应用，要把应用所占有的磁盘信息更新到租户磁盘实际用量表。另外，按照需要分析，把租户的基本信息写入数据库，便于查询，支持需求的各种模糊查询条件。管理员删除租户的时候要查询数据库表的租户信息，如果租户的内存实际用量或磁盘实际用量不为零，这提示不能删除，同时通过PCF API查询有什么应用部署在此租户。管理员查看租户的详细信息时，通过PCF API检索租户的详细信息页，除了显示租户的基本信息外，还需检索显示租户的工作空间列表、用户列表、应用列表等信息提醒服务PCF内置有提醒服务，需要配置，目前只支持Email的方式。PCF提供了基于Web页面和命令行的配置方式，配置提醒服务，包括提

44、醒服务的Email模板，哪些情况进行提醒，比如应用故障了，弹性伸缩了等。PCF需要配置Email服务器，才能安装提醒服务。PCF的提醒服务还提供了API，可以定制开发一个提醒配置应用。本期只实施基于PCF内置提供的Web配置和命令行配置，不通过提醒服务的API定制节目。如下图是配置哪些信息需要提醒。提醒服务也可以配置发送给特定的人员，或是发给某Space或是某组织。服务监控如下图为服务监管的技术架构，服务监管主要基于Zabbix的监控方案。PCF内置的P-metrics可以采集PCF安装的所有虚机的监控信息，包括各个服务的监控信息，以及各个部件的监控信息。对于Service Broker，如果

45、是PCF内置的Service,会有专门的虚机运行相应的Service Broker,如果是定制开发的Service Broker，相应的Service Broker程序在PCF DEA上以PCF应用的方式运行。本方案中，也会对系统的Java Buildpack打包一个Zabbix Agent,可以采集到应用运行的各种状态信息。Zabbix包括5大部分，核心是Zabbix Server，Zabbix Server：负责接收agent发送的报告信息的核心组件，所有配置、统计数据及操作数据均由其组织进行Zabbix Database：专用于存储所有配置信息，以及有zabbix收集的数据，在本设计中采

46、用PCF内置的mySQL 数据库服务，根据银行现有需求的估计，每个月可能会产生上百G的数据，可以给mySQL配置较大的服务计划，同时定时的把数据转储出去。Web interface（frontend）：zabbix的GUI接口，通常与server运行在同一台机器上。根据招呼的界面风格，对Zabbix的Web界面进行定制。Proxy：用于分布式监控环境中，代理Server收集部分被监控数据并统一发往Server端Agent：部署在被监控主机上，负责收集本地数据并发往Server端或者Proxy端平台监控和服务监管技术架构类似，PaaS的监控平台统一采用Zabbix,分别监控PCF的三大资源池：P

47、CF部件池、服务池、应用DEA池。一方面可以监控各个服务的状态信息，另外一方面可以监控PCF各个部件模块的状态信息，也可以监控PCF上运行的应用状态信息。对于服务监管和PCF部件监控而言，都是通过PCF内置的P-metrics把所有的状态信息采集到P-Metrics服务器上，然后通过JMX的方式传送到Zabbix Server。由Zabbix Server进行存储、分析、处理和展示。审计子系统架构设计审计子系统作为一个应用部署到PCF DEA。审计子系统作为控制台的一部分，分为两个模块，第一是操作记录模块，把所有对Console的操作写入数据库，审计子系统的数据库部署在。IaaS适配架构设计P

48、CF 1.5已经支持了OpenStack，目前我们在PCF 1.5的Beta版本已经安装在OpenStack环境下了，而青云会直接支持OpenStack的API。PCF是通过CPI(Cloud Programming Interface)来和下面的IaaS接口，如下图。只要实现了BOSH的CPI接口即可。如下图，CPI只要实现下面的10个API即可。对于招呼目前的IaaS接口，我们的方案建议是采用PCF已经指出的OpenStack标准接口，无论是青云还是华为的FusionSphere，都可以提供标准的OpenStack API接口，只要这些接口完全兼容OpenStack API，就可以直接接口

49、，如果有不完全兼容的地方，可以对IaaS层的接口再做一层封装，使之完全兼容即可。应用弹性伸缩架构设计应用弹性伸缩作为一个PCF应用部署在PCF的DEA上运行。系统架构如下图： 。弹性伸缩需要获取伸缩策略所需的实时数据。数据采集分为两个来源：应用弹性伸缩的子系统由三部分组成，一是指标采集，如上所述，第二是控制界面，对弹性伸缩策略的配置，第三是伸缩控制，包括定时控制(根据预先设定的时间进行伸缩)，伸缩的实际控制是通过PCF API直接访问Cloud Controller,实现应用实例的扩张或是收缩。另外，应用伸缩需要把应用伸缩策略的配置、伸缩操作等写入数据库，采用DBaas的mySQL数据库，创建

50、一个mySQL的服务即可。日志处理架构设计如下图为PaaS日志处理子系统的架构设计，子系统主要分为两部分：1、PCF日志采集聚合服务，通过PCF内置的Doppler模块负责采集日志，日志的来源有三种：A、PCF各个部件的日志，在PCF的OPS通过配置就可以把日志都采集到DopplerB、PCF各个服务的日志，在PCF的OPS通过配置各个服务日志输出的就可以把日志都采集到DopplerC、PCF的各个应用日志，PCF缺省会把所有的应用日志都输出到DopplerDoppler采集的日志包括监控日志、错误日志和其他等日志。2、日志处理采用IBM SmartCloud Analytics，Dopple

51、r可以把所有的日志通过syslog协议输出到IBM SmartCloud Analytics，由IBM SmartCloud Analytics进行统一处理。对于PCF的外置服务，通过标准的日志协议采集到IBM SmartCloud Analytics。通过对IBM SmartCloud Analytics（简称ISCA）的定制，系统管理员和开发人员能够登录ISCA平台查看日志；通过对ISCA的定制把监控日志和错误日志实时导出并显示到机房监控界面上。 MySQL Service Broker设计mySQL的服务设计分两个，一个是生产环境的mySQL服务，一个是开发测试环境的mySQL服务。开发

52、测试环境不需要灾备，是一个标准的服务设计方法。但是生产环境的mySQL要考虑深圳和上海两个PCF的灾备，所以设计方法和常规不一样。如下为开发测试环境的mySQL服务：开发测试环境也采用银行的DB as a Service数据库服务池，开发一个mySQL Service Broker的应用程序，部署在PCF的DEA上运行。此Service Broker要实现Service Broker V2的规范，包括Fetch Catalog、Provision Instance、Create Binding、Remove Binding、Remove Instance等。比如Provision Instan

53、ce的时候要调用数据库的API去创建数据库的实例，并创建相应的用户，在remove instance的时候做反操作，调用数据库的API去删除数据库的实例，并删除相应的用户。对于生产环境的mySQL服务架构如下图： mySQL的Service Broker作为一个PCF应用分别部署在深圳的PCF和上海的PCF，两个Service Broker完全一样，访问同一个Service Broker的数据库，这个数据库目前建议是采用现有的DB as a Service，保存Service Broker的一些数据，比如Service Instance的元数据信息、用户名口令等。同时，在深圳和上海的控制台上调

54、用PCF来创建服务、绑定服务。在深圳控制台创建服务的时候，会调用深圳的Service Broker去真正创建服务实例、创建用户等，如果调用深圳的Service Broker故障，则转向调用上海的Service Broker去真正创建服务实例、创建用户等,并确保只会调用一次创建数据库实例。当深圳PCF故障，切换到上海PCF的时候，上海的PCF MySQL Service Broker正常运行，而且上海PCF的Console也正常运行，原有的所有数据库Instance都在上海的Service Broker中有创建，只是通过Console创建数据库实例的时候会控制只创建一份。Redis 服务设计Re

55、dis服务的设计是基于PCF现有的Redis服务，增加集群功能。要改造现有的PCF的Redis服务，一方面是改造PCF OPS上的Redis配置，增加集群相关的配置。第二是对Service Broker的改造，要增加Service Broker创建Redis集群实例的实现，以及绑定Service Instance的实现。Redis采用多台虚机，部署Redis集群，同时也提供单机Redis服务。也即两个Service Plan,一个是在Redis集群中创建一个Redis服务实例，另外一个是单独创建一个Redis虚机。预先通过OPS安装好一批Redis独享虚机，如果Redis独享虚机不够，需要通过

56、OPS再加配Redis独享虚机。RabbitMQ 服务设计RabbitMQ的服务的设计是基于PCF现有的RabbitMQ服务，增加HA Proxy VIP自动切换功能。PCF的RabbitMQ已经支持了HA架构，可以配置多个RabbitMQ节点做成HA模式，同时前端可以配置HA Proxy做RabbitMQ切换。PCF的RabbitMQ服务的HA Proxy的IP不能自由浮动，我们在本次设计中配置KeepAlive来实现VIP，并实现HAProxy故障之后的IP自动切换。Jenkins 服务设计Jenkins的服务设计是基于现有的开源Jenkins定制为支持HA的Jenkins服务。如下为银行

57、Jenkins服务的使用场景：用户使用Eclipse，安装PCF的插件，可以把应用直接部署在PCF上，同时安装RTC插件，代码和RTC同步。而一旦提交代码到RTC，然后就可以触发Jenkins对项目进行构建，比如通过Mavin构建，然后通过Jenkins做测试，然后再通过Jenkins自动部署到PCF上。用户操作的时序图如下：如下图为Jenkins服务的技术架构。Jenkins分为两类机器，一个是Master机器，整体负责Jenkins的运行，第二是Slave的任务机，Jenkins Master机器可以把任务分发给不同的Jenkins Slave任务机处理，Master会监控每台Slave机

58、器的运行状态，如果Slave机器故障，不会把任务分发过去。在本架构中，配置一台Jenkins Master虚机，同时配置一台Jenkins Master的热备机器，如果主Jenkins机故障，我们直接访问热备的Jenkins机器即可。在Jenkins Master和热备机器之间配置了ssh + rsync + inotify的数据同步机制，Master的任何数据变化会同步到热备机器上去。角色分类：（人机交互产品建议填写，用于UAT测试案例编写）角色分类角色细分相关子系统系统管理员生产平台系统管理员开发测试平台系统管理员租户管理员开发测试平台Org管理员开发测试平台Space管理员普通用户生产平

59、台普通用户开发测试平台普通用户业务场景/流程设计 MACROBUTTON TableDeleteTable 双击此处添加 以模块为最小单位来说明系统主要功能的实现流程，可以用时序图或泳道图的方式来表示。例子，以“积分业务总图”-“积分使用”“积分直接消费”进行描述业务场景如下，为PaaS的总业务场景图，从3个不同的角色的角度分为不同的业务场景业务场景/流程清单序号业务场景/流程名称业务场景/流程功能描述业务场景/流程图名1管理员配置生产平台2管理员创建租户管理员3管理员创建普通用户4租户管理员监控管理5租户管理员配置租户6普通用户使用控制台7普通用户应用监控8普通用户申请资源9普通用户部署应用10普通用户的提醒服务数据标准使用及数据结构设计 MACROBUTTON TableDeleteTable 双击此处添加 对照业务需求书数据标准章节，进一步分析需求，补充和完善CMB DS-业务数据标准制定中相关联的业务对象和信息项，在此基础上进行数据库设计。使用的信息项清单 MACROBUTTON TableDeleteTable 双击此处添加 信息项清单，直接通过一事通专业系统