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

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

《云计算PaaS平台总体设计说明书.docx》由会员分享，可在线阅读，更多相关《云计算PaaS平台总体设计说明书.docx（36页珍藏版）》请在冰豆网上搜索。

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

云计算PaaS平台

总体设计说明书

1.引言

1.1目的

本文档对PaaS平台进行总体架构设计，目标用户为设计人员、开发人员、测试人员、项目管理人员。

1.2背景

目前银行IT并没有PaaS平台，应用的开发、测试、上线、试运行都是按照传统的金融IT发布流程进行。

对于以需要快速响应、快速发布、迭代更新为特征的互联网应用来说，传统IT已经难以满足这种快速发布的需要，主要表现在：

环境准备时间过长:

产品运行所需要的硬件、软件环境往往需要在上线前几个月就要申请、准备，在产品上线前就需要规划出产品今后可能用到的资源数量；

无弹性扩展，扩容难：

产品投产后很难再变更应用的部署规模及资源配给，难以应付突发流量，难以应对日益增长的数据量；

测试环境与生产环境差异较大：

应用的测试环境和生产环境存在较大差异（例如生产环境是集群部署，而测试环境则只是单节点部署），测试案例并不能完全模拟生产环境；应用的配置信息在不同的环境需要手工修改（例如修改配置参数），增加了出错几率；

上线过程复杂：

上线过程除了开发人员外，往往需要运维人员、DBA等各个环节的人员共同参与，或修改配置、或部署应用、或执行数据库脚本，增加了上线人力成本的投入，降低了上线投产的效率；

建设周期长：

部署周期长，软件定制开发慢，与外围系统接口复杂，实施推广需要大量的实施人力完成。

通过PaaS云的建设解决以上问题。

1.3术语和缩略语

PaaS：

PlatformasaService,平台服务，把应用平台作为服务提供

PCF：

PivotalCloudFoundryPivotal的PaaS云平台

1.4参考资料

应完整列出本文档所参考或引用的资料，可包括项目其他文档。

标识出每个文件的名称、编号（如果有）、日期、出版组织、获取来源，可以通过在此处定义、引用本文档的附录、或者引用其它文件的方式来提供。

1.5约定

说明在编写或阅读本文档时的一些约定，如需求编号的编码规则、图例规则等，可以通过在此处定义、引用本文档的附录、或者引用其它文件的方式来提供。

2.概述

银行PaaS平台建设，为应用提供统一的云平台，大量实现应用平台相关的自动化和可用性进一步提高，比如灰度发布、开发部门的持续集成（CI）和DevOps（开发运维）、应用监控、及进一步提升应用的可用性。

这些功能大多属于PaaS功能，通过PaaS平台的建设，并且逐步把应用迁移到PaaS平台，可以进一步简化运维，特别是应用部署的标准化和简化；也可以进一步提高硬件资源池的使用效率，通过PaaS云的自动弹性伸缩、多重的应用故障自动恢复、平台的高可用性区等进一步提高平台的高可用性，实现应用的在线升级包括灰度发布等，并通过平台来实现应用日志的集中管理。

对开发部门来说，通过平台支持的敏捷开发、CI和DevOps来进一步提高开发效率，缩短从需求到IT实现的周期。

2.1.产品描述

PaaS平台构建了开发、测试、生产运行环境。

通过BuildPack构建包提供了银行主要的几种应用平台，包括dk1.6，jdk1.7，jdk1.8（分OpenJDK和OracleJDK两版本）、IBMJDK1.6、JBossEAP6.2、Tomcat7、Tomcat8等。

提供的服务包括mySQL、RabbitMQ、Redis、Jenkins等。

除了平台和服务，还提供了统一的日志聚合和日志管理，应用弹性伸缩、平台定时伸缩、应用监控、服务监控、平台监控、审计等功能。

2.2.假设与约束

列出可能影响设计的假设条件和约束条件。

这里不应包含人力资源、时间等项目管理类的约束条件。

此节需要具体包含什么内容尚不明确，须在后续试点项目重点跟进。

2.3.环境、工具及相关约定

2.3.1.开发环境

dk1.6，jdk1.7，jdk1.8（分OpenJDK和OracleJDK两版本）以及IBMJDK1.6的Buildpack；定制以JBossEAP6.2为应用服务器的Buildpack；定制以Tomcat7、Tomcat8为应。

Tomcat8等。

提供的服务包括mySQL、RabbitMQ、Redis、Jenkins等。

除了平台和服务，还提供了统一的日志聚合和日志管理，应用弹性伸缩、平台定时伸缩、应用监控、服务监控、平台监控、审计等功能。

2.3.2.运行环境

参照《可行性分析报告》，说明运行环境的软硬件要求。

例如数据库服务器的配置要求、应用服务器的配置要求等。

如果该系统对硬件敏感性高，则必须对硬件要求（如ＣＰＵ、内存、存储、带宽等）进行详细的说明。

Tomcat8等。

提供的服务包括mySQL、RabbitMQ、Redis、Jenkins等。

除了平台和服务，还提供了统一的日志聚合和日志管理，应用弹性伸缩、平台定时伸缩、应用监控、服务监控、平台监控、审计等功能。

3.总体结构

本章内容须在后续试点项目重点跟进。

3.1.总体设计思路

总体设计思路是以PCF提供的产品功能为基础，加上一定的定制和开发来实现所有的需求功能，同时，考虑主要的非功能要求，比如高可用性、灾备、性能、安全性等。

在PCF现有的产品特性基础上，定制实现非功能性需求。

3.2.系统逻辑图

根据《IT系统架构图编制标准》，绘制系统逻辑图，说明本软件产品和其它软件产品的关联关系。

如下图为银行PaaS双活架构图，在深圳和上海各部署一套PCF，通过一些双活的配置，实现两地PCF的双活。

最前端是一个DNS实现两个PCF的域名解析，分别把PaaS应用访问域名（*假定是此域名）、深圳PaaS系统域名（*）和上海PaaS系统域名（*）统一泛域名解析到一个F5的负载均衡器，而F5把深圳PaaS系统域名（*）请求转发到深圳PCF，把上海PaaS系统域名（*）统一泛域名请求转发到上海PCF上。

而应用域名*请求则配置转发策略，不同的应用可以配置不同的转发策略，比如90%的请求转发到深圳PCF，10%的请求转发到上海的PCF，要求转化的时候配置Session亲和性，确保同一个Session只会转发到一个PCF。

每个PCF都会需要配置自己的系统mySQLHA，可以选用PCF自带的mySQL服务，也可以采用外部的DBaaS数据库。

而对PCF定制的应用，则主要访问银行DBaaS数据库。

除了采用F5作为请求分发，也可以采用HAProxy做请求分发。

如下图采用HAProxy做请求分发的逻辑架构图。

配置两台高配的X86虚机做HAProxy服务器，建议每台HAProxy服务器配置为8G内存，12vCPU。

每台HAProxy上安装HAProxy和KeepAlive软件。

两台HAProxy配置出虚拟IP（VIP），在DNS中把应用访问域名、

深圳PaaS系统域名和上海PaaS系统域名的都解析到VIP。

通过对HAProxy的负载算法进行配置（URI配分发权重），可以对不同的应用分发不同的流量到深圳PCF集群或是上海PCF集群。

根据对目前银行的F5使用情况的了解，主要是5000S型，可以支持每秒新建并发连接35万，最大的在线长连接为2400万。

而采用HAProxy的服务器，性能无法和F5同等，因为F5有专用的硬件加速芯片，根据一些测试经验，在高配的X86服务器上，记过优化，HAProxy的最大在线长连接可能可以达到千万。

本方案建议采用F5作为请求分发均衡器。

3.3.子系统逻辑图

如下为模块逻辑图：

根据《IT系统架构图编制标准》，绘制各子系统的模块逻辑图，说明各子系统的模块划分及模块间关系。

列出所有模块，依次说明各模块的功能以及该模块与其他模块间的协作方式。

如：

交易处理模块负责接受渠道提交的投保、撤单等业务请求，通过网关对接模块最终发送到保险公司系统，所记录的交易记录为清算等其它模块提供数据基础。

如下图，为基于PCF的银行PaaS系统逻辑架构图，包括银行用到的PCF内置模块，定制模块，以及和外部模块的接口。

这是对PCF现有模块的裁剪，有些需要定制，有些可以直接用，有些需要和银行的系统集成，如和用户目录、日志集中处理等模块的集成。

。

根据银行的需求在对PCF模块进行裁剪后，需要定制的子系统分为如下三大群，分别是应用运行时、服务和PCF自身功能的定制：

1、应用运行时，为应用提供运行环境，包括：

a）Tomcat7/8

b）JDK1.6（OpenJDK,IBMJDK,OracleJDK）

c）JDK1.7（OpenJDK,OracleJDK）

d）JDK1.8（OpenJDK,OracleJDK）

e）JBOSSEAPV6.2

PCF的应用运行时基于PCF的应用平台构建规范BuildPack的规范进行构建。

2、服务，基于PCF自身提供或是定制的服务，为应用的运行提供服务支撑：

a）MySQL

b）Redis

c）RabbitMQ

d）Jenkins

PCF提供了ServiceBrokerAPIV2，通过对这些ServiceBroker的API来实现每个服务，同时通过PCFBOSHAPI来实现服务虚机的部署。

3、PCF平台自身定制功能，针对银行的需求，对PCF平台进行定制，包括：

a）提醒服务

b）服务监控

c）平台监控

d）审计

e）租户管理

f）用户管理

g）平台定时伸缩

h）应用弹性伸缩

i）集中日志管理

j）控制台

k）IaaS适配

PCF的自身定制功能是在PCF现有提供的功能基础上，通过PCF提供的API进行定制，实现和需求相结合的功能。

3.4.生产平台部署物理架构图

根据《IT系统架构图编制标准》，绘制应用部署图，说明程序实体和数据实体的部署情况，以及各部署节点的软硬件环境要求。

物理架构设计原则如下：

3

系统部署分为生产环境和开发测试环境。

如下为物理部署逻辑架构图：

。

PaaS在深圳和上海分别部署一套PCF集群，深圳5台X86服务器配置为一个PCF集群，一个集群又分两个高可用性区，3台X86为组成一个vSphere集群1，做成一个PCF的高可用性区A，另外2台X86为组成一个vSphere集群2，做成一个PCF的高可用性区B。

通过配置两个高可用性区，PCF的部署自动分布在两个高可用性区，无论是PCF部件、还是应用实例还是服务，都分布在两个高可用性区，确保没有单点故障

根据逻辑架构设计，物理资源分为三大池，一个是应用资源池，二是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高可用性区。

和生产平台的部署不一样，开发测试环境需要配置更多