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

1、云计算PaaS平台总体设计说明书云计算PaaS平台总体设计说明书1.引言1.1目的本文档对PaaS平台进行总体架构设计，目标用户为设计人员、开发人员、测试人员、项目管理人员。1.2背景目前银行IT并没有PaaS平台，应用的开发、测试、上线、试运行都是按照传统的金融IT发布流程进行。对于以需要快速响应、快速发布、迭代更新为特征的互联网应用来说，传统IT已经难以满足这种快速发布的需要，主要表现在：环境准备时间过长: 产品运行所需要的硬件、软件环境往往需要在上线前几个月就要申请、准备，在产品上线前就需要规划出产品今后可能用到的资源数量；无弹性扩展，扩容难：产品投产后很难再变更应用的部署规模及资源配给

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

3、略语PaaS： Platform as a Service,平台服务，把应用平台作为服务提供PCF： Pivotal Cloud Foundry Pivotal的PaaS云平台 1.4参考资料 应完整列出本文档所参考或引用的资料，可包括项目其他文档。标识出每个文件的名称、编号（如果有）、日期、出版组织、获取来源，可以通过在此处定义、引用本文档的附录、或者引用其它文件的方式来提供。1.5约定说明在编写或阅读本文档时的一些约定，如需求编号的编码规则、图例规则等，可以通过在此处定义、引用本文档的附录、或者引用其它文件的方式来提供。2.概述银行PaaS平台建设，为应用提供统一的云平台，大量实现应用平台

4、相关的自动化和可用性进一步提高，比如灰度发布、开发部门的持续集成(CI)和DevOps(开发运维)、应用监控、及进一步提升应用的可用性。 这些功能大多属于PaaS功能，通过PaaS平台的建设，并且逐步把应用迁移到PaaS平台，可以进一步简化运维，特别是应用部署的标准化和简化；也可以进一步提高硬件资源池的使用效率，通过PaaS云的自动弹性伸缩、多重的应用故障自动恢复、平台的高可用性区等进一步提高平台的高可用性，实现应用的在线升级包括灰度发布等，并通过平台来实现应用日志的集中管理。 对开发部门来说，通过平台支持的敏捷开发、CI和DevOps来进一步提高开发效率，缩短从需求到IT实现的周期。2.1.

5、产品描述PaaS平台构建了开发、测试、生产运行环境。通过BuildPack构建包提供了银行主要的几种应用平台，包括dk1.6，jdk1.7，jdk1.8 （分OpenJDK和Oracle JDK两版本）、IBM JDK1.6、JBoss EAP6.2、Tomcat7、Tomcat8等。提供的服务包括mySQL、RabbitMQ、Redis、Jenkins等。除了平台和服务，还提供了统一的日志聚合和日志管理，应用弹性伸缩、平台定时伸缩、应用监控、服务监控、平台监控、审计等功能。2.2.假设与约束列出可能影响设计的假设条件和约束条件。这里不应包含人力资源、时间等项目管理类的约束条件。此节需要具体包

6、含什么内容尚不明确，须在后续试点项目重点跟进。2.3.环境、工具及相关约定2.3.1.开发环境dk1.6，jdk1.7，jdk1.8 （分OpenJDK和Oracle JDK两版本）以及IBM JDK1.6的Buildpack；定制以JBoss EAP6.2为应用服务器的Buildpack； 定制以Tomcat7、Tomcat8为应。Tomcat8等。提供的服务包括mySQL、RabbitMQ、Redis、Jenkins等。除了平台和服务，还提供了统一的日志聚合和日志管理，应用弹性伸缩、平台定时伸缩、应用监控、服务监控、平台监控、审计等功能。2.3.2.运行环境参照可行性分析报告，说明运行环境

7、的软硬件要求。例如数据库服务器的配置要求、应用服务器的配置要求等。如果该系统对硬件敏感性高，则必须对硬件要求（如、内存、存储、带宽等）进行详细的说明。Tomcat8等。提供的服务包括mySQL、RabbitMQ、Redis、Jenkins等。除了平台和服务，还提供了统一的日志聚合和日志管理，应用弹性伸缩、平台定时伸缩、应用监控、服务监控、平台监控、审计等功能。3.总体结构本章内容须在后续试点项目重点跟进。3.1.总体设计思路总体设计思路是以PCF提供的产品功能为基础，加上一定的定制和开发来实现所有的需求功能，同时，考虑主要的非功能要求，比如高可用性、灾备、性能、安全性等。在PCF现有的产品特性

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

9、，比如90%的请求转发到深圳PCF，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和Kee

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

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

12、行的需求在对PCF模块进行裁剪后，需要定制的子系统分为如下三大群，分别是应用运行时、服务和PCF自身功能的定制：1、应用运行时，为应用提供运行环境，包括：a)Tomcat 7/8b)JDK 1.6(OpenJDK,IBM JDK,Oracle JDK)c)JDK 1.7(OpenJDK, Oracle JDK)d)JDK 1.8(OpenJDK, Oracle JDK)e)JBOSS EAP V6.2PCF的应用运行时基于PCF的应用平台构建规范BuildPack的规范进行构建。2、服务，基于PCF自身提供或是定制的服务，为应用的运行提供服务支撑：a)MySQLb)Redisc)RabbitM

13、Qd)JenkinsPCF提供了Service Broker API V2，通过对这些Service Broker的API来实现每个服务，同时通过PCF BOSH API来实现服务虚机的部署。3、PCF平台自身定制功能，针对银行的需求，对PCF平台进行定制，包括：a)提醒服务b)服务监控c)平台监控d)审计e)租户管理f)用户管理g)平台定时伸缩h)应用弹性伸缩i)集中日志管理j)控制台k)IaaS适配PCF的自身定制功能是在PCF现有提供的功能基础上，通过PCF提供的API进行定制，实现和需求相结合的功能。3.4.生产平台部署物理架构图根据IT系统架构图编制标准，绘制应用部署图，说明程序实体

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

15、池，二是PCF部件池，第三的服务池。PCF部件池部署PCF的各个部件，每个部件都做HA或是集群，确保每个部件有2份以上，考虑到未来并发访问量会比较大，要至少配5个Router部件。应用资源池为DEA池，作为PaaS应用容器，根据资源的容量计算每个DEA的CPU、内存、磁盘额度，至少运行16个以上DEA。服务资源池部署Redis、RabbitMQ、mySQL等服务，所有的服务都支持HA或是集群，确保高可用性。通过资源池的方式提供资源共享程度，提高资源利用率。通过资源分池，提高安全隔离性3.5.开发测试平台部署物理架构图根据IT系统架构图编制标准，绘制应用部署图，说明程序实体和数据实体的部署情况，以及各部署节点的软硬件环境要求。如下为开发测试环境的物理部署逻辑架构图：。和生产平台的部署不一样，开发测试环境只在深圳部署一套PCF，但是一套PCF也做两个高可用性区，5台X86服务器做成一个vSphere集群，同时配置为一个PCF高可用性区。和生产平台的部署不一样，开发测试环境需要配置更多