传统企业PaaS平台功能设计与业务上云思考(上云设计,关键词优化)

伴随着Docker技术的兴起，以及容器集群管理平台Mesos、Kubernetes、Swarm、Rancher等的大行其道，仿佛PaaS平台及其相关技术一下进入了黄金时期，各种各样的技术组合，各种各样的技术验证，以及伴随着容器相关的创业公司布道，仿佛只要有了PaaS平台及其相关的技术，就能解决一切的企业IT问题。但是，企业IT，尤其是非互联网传统企业，PaaS平台的构建与业务上云是一个长期的过程，绝不是一个Docker+kubernetes/Mesos/Swarm构建完以后就能完成的，IaaS年代是这样，PaaS年代也是这样。

在互联网公司或者自研发型的应用，开发环境与部署运行环境非常的类似，这也是Docker或者容器相关技术在应用上的一个很大的优势（比如构建开发、测试、部署的DevOps流水线），但是在传统企业便不一定能行得通，比如某个企业的IT应用开发维护是外包的，标准软件需要采购、应用开发需要在应用开发商完成、硬件是另外的硬件提供商，到货后需要硬件系统集成、标准软件部署、应用开发部署调试，需要很多供货商来完成，往往以项目经理统筹完成，很难由一套DevOps之类的平台来解决所有问题。

那么传统企业PaaS平台设计需要什么样的功能？上云时又需要进行如何改造？这是本文探讨的重点。

一、传统企业的应用架构与应用分类

大家对这种架构耳熟能详，但也请做云计算或者容器技术的同事不要对这种架构嗤之以鼻，因为这种架构也包含很多对我们有学习借鉴意义的技术模块：

SAN存储：包括高、低、中不同的存储，存储中磁盘的RAID配置、存储池配置、存储的集群配置、存储的容灾备份、数据的热点迁移、数据的缓存、存储之间的SAN交换机配置（划分Zoning，连接主机）等都需要专业的存储工程师（衍生出来了很多的认证），这种存储可以做到高IOPS、低延迟、高可靠性，是目前大多数的分布式存储难以匹敌的，且目前存储厂商在SAN上也做到了虚拟化；

主机：小型机、x86服务器，小型机以IBM小型机为例，小型机虚拟化比x86虚拟化出现的年代早了几十年，当时是硬分区技术，后来发展到逻辑分区+IO虚拟化，逻辑分区可以做到分配0.1个CPU的细粒度，同时也在2007年就推出了类似于容器的技术，做到了进程级别的隔离，但因为不开源、不方便打包、镜像管理没有Docker方便，最终只在少数客户处进行了部署使用；

DB：传统的数据库厂商比如Oracle为例，很早就推出了RAC技术，同时，2012年左右Oracle研发中心内部就开始使用Container技术搭建DB as a Service（这比我们目前大多数的Docker相关的创业公司还早）；

APP：以IBM WebSphere为例，十年之前就有WAS集群的概念，可以部分做到横向扩展。

传统企业这种架构统治了企业IT数十年之久，在大的行业，通常以商用中间件、商用DB、小型机、SAN存储部署。这种架构存在扩展性不足的问题，但是在传统企业架构中大量存在。

我们部署一个IT系统，最终的目的是为了解决传统的问题，所谓把线下业务线上化，这些业务最终的服务对象是数据，而数据处理大致可以分成两大类：联机事务处理OLTP（on-line transaction processing）、联机分析处理OLAP（On-Line Analytical Processing）。

当然还有其他的业务类型，比如银行或者运营商的每月出账系统，这种系统为也是一种批处理系统，但是实时性很强，跟Hadoop MR所谓的批处理不是一个概念，也不在一个层级。这种应用我们暂时不考虑。

OLTP，也叫联机事务处理（Online Transaction Processing）系统，表示事务性非常高的系统，一般都是高可用的在线系统，评估其系统的时候，一般看其每秒执行的Transaction以及Execute SQL的数量。典型的OLTP系统有客户关系管理系统、电子商务系统、银行、证券等。

要求：一致性、高可用性

OLAP，也叫联机分析处理（Online Analytical Processing）系统，有的时候也叫决策支持系统，就是我们说的数据仓库。在这样的系统中，语句的执行量不是考核标准，因为一条语句的执行时间可能会非常长，读取的数据也非常多。所以，在这样的系统中，考核的标准往往是磁盘子系统的吞吐量（带宽），如能达到多少MB/s的流量

下面我们分别分析一下这两类应用的云化需求与云化的分析。

注意：这些要求分析与要求是在Docker与各类容器管理平台火起来之前总结与做的，不是依据Docker或者容器相关技术的要求做的。所以，对我们跳出容器的惯性思维，构建一个适合传统企业的PaaS云平台有很强的指导意义。

二、传统企业的应用云化改造需求

（一）OLTP类应用云化的要求

云化关键点1：系统弹性伸缩

通过应用与数据分离和集群化部署，实现系统快速扩容、处理能力灵活水平线性扩展、故障自动隔离。对于独立的应用主机可以进行灵活弹性伸缩。

弹性伸缩特点：

在线快速扩容：系统扩容操作低耗时、无数据迁移、服务不间断；

处理能力线性扩展：系统处理能力可以通过新增节点近线性提升，实现高吞吐、高并发处理能力，应对业务爆发式增长；

故障自动接管：集群可以自动发现故障节点并调整任务调度策略，在不影响处理的同时接管故障节点，保持系统高可用

云化关键点2：应用集群化部署

将紧密耦合的大应用模块化拆分为多个模块化小应用，通过资源池提供系统资源的整体利用率，并将拆分后的子模块部署于资源池（后来我们搞Docker的称之为微服务化）。当硬件资源实施池化后，才具备了支撑应用的弹性伸缩，实现硬件的按需分配的基本需求，充分提高资源利用率。

云化关键点3：通过数据分级分类实现应用与数据分离

根据数据实时性、重要性、敏感性等因素，将数据分成数个级别，各个级别的数据对系统的作用、采用存储、保护方式也都有所不同。

通过对应用提供数据的透明访问，屏蔽数据的位置差异、数据分布差异、数据存储等差异：

位置无关性：数据在远程还是本地存储，对应用最好透明。

分布无关性：数据分布在多个数据节点，对应用透明。比如查询某个客户的所有相关数据，虽然同一个用户信息分布在多个数据节点上，但对应用来说就好像一个集中数据库进行查询。

存储无关性：数据存储在内存库、物理库（关系型数据库、NoSQL数据库）、File还是缓存等介质，对应用透明。

云化关键点4：合理规划实现数据分布式部署

对不同业务的数据、不同类型的数据进行有效规划部署。通过某种特定的条件，将存放在同一个数据库中的数据分散存放到多个数据库上，实现数据分布存储，通过路由规则路由访问特定的数据库

数据库拆分方式包括：

垂直（纵向）拆分：将数据库表按业务、功能拆分到不同的数据库表，比如分为客户资料库、订单库、资源库、资料库等，这种方式多个数据库之间的表结构不同；目的是降低业务之间的影响，减少系统承载压力。

水平（横向）拆分：将同一个表的数据进行分块保存到不同的数据表中，这些数据库中的表结构完全相同。

拆分以后，带来的问题，需要做到：对外提供统一访问，对应用屏蔽数据访问复杂度。数据访问层提供数据互访能力，拆分访问合并返回。

所以需要构建统一数据访问引擎，或者数据路由层（Data layer层）。开源的比如有Hibernate Shards、Ibatis-Sharding、淘宝TDDL等。

云化关键点5：数据平台化

数据平台化是指通过应用架构和数据架构的重新梳理、规划与调整，将业务处理中的业务数据和状态数据与应用分离，实现应用的轻量化、无状态；构建统一的数据访问层，实现数据的共享访问。数据平台化是数据处理水平线性扩展的前提和基础

数据平台化特点：

应用轻量化：缩短开发周期，提升新业务响应速度；

应用无状态：实现应用的同质化，应用层处理能力的独立扩展，实现应用灵活调度和分配；

数据共享访问：逐步实现数据集中访问，跨地市的流量共享、流量统付、流量转移业务能够更高效支撑。

（二）OLAP型应用云化的需求

首先看一下传统的数据仓库典型架构：

这种架构以处理结构化数据为主，基本部署于Oracle、小型机、SAN存储之上，扩展性不足，难以处理海量数据。大数据处理技术的兴起让这类应用的云化找到了思路。云化时总体推荐混搭架构，即采用多种技术架构建设大数据中心：

垂直混搭架构：

这种架构比较容易部署，但会形成多个相互独立的信息孤岛；未来缺乏可行的系统演进路；

2. 水平混搭架构：

企业级数据云平台：逐渐实现企业内数据的统一存储，承载数据的加工计算；未来提供企业数据的统一存储和计算能力；

数据仓库、集市和挖掘库：计算逐渐迁移到云平台实现轻载化；直接从云平台加载应用结果数据，实现上层应用的兼容性；

流处理平台：实时计算结果存储到云数据平台，可通过能力开放平台的消息中间件直接供应用访问

OLAP云化关键点1：数据计算引擎开源化

M/R计算引擎：用HDFS文件保证每一步计算结果，避免硬件故障导致重头执行。

优点：可靠性高；

缺点：数据处理任务是一系列M/R任务的串行执行，输入和输出都是HDFS文件，导致频繁的磁盘I/O，执行速度慢；

局限性：原始单一的编程模型和数据结构，导致开发效率低，限制更多应用的产生。

Spark计算引擎：RDD是分布式内存的抽象。

优点：执行效率比起M/R提升100倍以上；提供丰富的操作算子增强编程能力，简化应用开发；

缺点：对内存等资源要求高；可靠性不如M/R；

Yarn实现资源调度和分配：一个节点上可同时执行M/R和Spark任务，资源相互隔离、执行互不干扰。

OLAP云化建设关键点2：数据集市云化建设

建设现状：传统小机+Oracle数据库和新建的MPP数据库两种建设模式。

演进策略一：用MPP数据库来取代小机+Oracle数据库；

演进策略二：用数据云平台+开源MYSQL/PGSQL集群来代替小机+Oracle数据库。

数据云平台完成所有的后台计算。

OLAP云化关键点3：数据ETL云化建设

传输的实时化：支持MQ等分布式实时消息传输机制；

基于内存的计算：数据不落地，避免海量数据的两次重复加载；

计算的轻量化：清单级的过滤、排重、规则化，更多的计算任务由大数据存储和计算平台来完成；

分布式并行执行：高可用性、分布式调度、资源分配；

技术实现：Kafka+HDFS+MR/Spark。

三、基于容器的PaaS平台架构的构建

我们提到了传统企业中两类核心的应用，并且在Docker流行之前便规划了一些云化的关键点，并形成了PaaS平台，使之运行于IaaS平台与Hadoop YARN集群之上。

基于此架构有以下几个主要问题：

可以实现应用编排与部署，但是编排的基础单元是虚拟机模板，模板比较重，而且镜像很难修改，编排、分发、运行、持续集成等都有很大的困难，因此构建在模板上的应用形成的服务很难用；

基于虚拟机的弹性伸缩相应时间也比较慢，我们尝试做过基于Cloudwatch+Autoscaling的虚拟机弹性伸缩功能，发现弹性伸缩对业务的响应时间有一个偏差，这个偏差大约在十几分钟，在抢购、秒杀等业务中基本不可接受；

很难在企业内部形成一个统一的私有云集群来同时运行这两类业务，因此两个PAAS集群实际上是两个独立的集群，都是按照业务最高峰配置，存在资源浪费的现象，运维也是分开运维。

Docker及其相关技术兴起之后，我们基于容器的相关生态圈技术，构建了新一代PaaS平台。

使用容器+容器镜像管理替代服务目录管理+虚拟机模板管理。

在Instance PaaS（iPaaS）平台上除了基于Kubernetes的容器管理、镜像管理、应用管理等功能，还构建了如下子系统：

日志子系统：基于ELK实现；

计算子系统：集成OpenStack与自研的Skyform CMP；

存储子系统：通过Cinder，支持ISCSI、NFS、Ceph三类存储，与IaaS打通；

网络子系统：我们选用了Netron+OVS的SDN解决方案；

监控子系统：通过Ceilometer+MongoDB进行实施数据的监控、Phoenix+Hadoop进行历史数据分析；

用户交互子系统：基于Node.js开发

整体的PaaS平台构建基于Kubernetes、Hadoop、Spark on Mesos，构建完整的DCOS平台。

需要说明的是，在传统企业在云平台还需要对接大量的系统，比如ITIL、4A/3A、人力资源系统、审计系统等，这些系统与云平台的接口集成不在本次讨论范围内。

下面说一下基于以上的PaaS平台对传统应用云化关键点的解决

针对OLTP类应用云化的5个关键点的解决：

系统弹性伸缩：通过Kubernetes RC+service实现；

应用集群化部署：通过Mesos/Kubernetes构建x86集群，将应用分布式改造以后部署与集群；

通过数据分级分类实现应用与数据分离：通过Big data PaaS的HDFS服务与Instance PaaS的DB服务可以提供部分数据分级服务的基础，但是数据分级与存储，以及访问透明性未能完全实现，需要在业务层面进行适配；

合理规划实现数据分布式部署：通过在Instance PaaS提供数据库服务，以及开开源数据路由服务，实现，注：需要DBA规划数据的存储；

数据平台化：应用改造后即可实现。