传统企业PaaS平台功能设计与业务上云思考

文/ 天云软件 技术总监 牛继宾

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

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

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

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

你们对这种架构耳熟能详，但也请作云计算或者容器技术的同事不要对这种架构嗤之以鼻，由于这种架构也包含不少对咱们有学习借鉴意义的技术模块：

• 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云平台有很强的指导意义。

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

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

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

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

弹性伸缩特色：

1. 在线快速扩容：系统扩容操做低耗时、无数据迁移、服务不间断；
2. 处理能力线性扩展：系统处理能力能够经过新增节点近线性提高，实现高吞吐、高并发处理能力，应对业务爆发式增加；
3. 故障自动接管：集群能够自动发现故障节点并调整任务调度策略，在不影响处理的同时接管故障节点，保持系统高可用。

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

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

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

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

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

1. 位置无关性：数据在远程仍是本地存储，对应用最好透明。
2. 分布无关性：数据分布在多个数据节点，对应用透明。好比查询某个客户的全部相关数据，虽然同一个用户信息分布在多个数据节点上，但对应用来讲就好像一个集中数据库进行查询。
3. 存储无关性：数据存储在内存库、物理库（关系型数据库、NoSQL数据库）、File仍是缓存等介质，对应用透明。

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

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

数据库拆分方式包括：

• 垂直（纵向）拆分：将数据库表按业务、功能拆分到不一样的数据库表，好比分为客户资料库、订单库、资源库、资料库等，这种方式多个数据库之间的表结构不一样；目的是下降业务之间的影响，减小系统承载压力。
• 水平（横向）拆分：将同一个表的数据进行分块保存到不一样的数据表中，这些数据库中的表结构彻底相同。

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

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

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

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

数据平台化特色：

• 应用轻量化：缩短开发周期，提高新业务响应速度；
• 应用无状态：实现应用的同质化，应用层处理能力的独立扩展，实现应用灵活调度和分配；
• 数据共享访问：逐步实现数据集中访问，跨地市的流量共享、流量统付、流量转移业务可以更高效支撑。

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

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

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

1. 垂直混搭架构：

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

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。

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

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

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

1. 能够实现应用编排与部署，可是编排的基础单元是虚拟机模板，模板比较重，并且镜像很难修改，编排、分发、运行、持续集成等都有很大的困难，所以构建在模板上的应用造成的服务很难用；
2. 基于虚拟机的弹性伸缩相应时间也比较慢，咱们尝试作过基于Cloudwatch+Autoscaling的虚拟机弹性伸缩功能，发现弹性伸缩对业务的响应时间有一个误差，这个误差大约在十几分钟，在抢购、秒杀等业务中基本不可接受；
3. 很难在企业内部造成一个统一的私有云集群来同时运行这两类业务，所以两个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个关键点的解决：

1. 系统弹性伸缩：经过Kubernetes RC+service实现；
2. 应用集群化部署：经过Mesos/Kubernetes构建x86集群，将应用分布式改造之后部署与集群；
3. 经过数据分级分类实现应用与数据分离：经过Big data PaaS的HDFS服务与Instance PaaS的DB服务能够提供部分数据分级服务的基础，可是数据分级与存储，以及访问透明性未能彻底实现，须要在业务层面进行适配；
4. 合理规划实现数据分布式部署：经过在Instance PaaS提供数据库服务，以及开开源数据路由服务，实现，注：须要DBA规划数据的存储；
5. 数据平台化：应用改造后便可实现。

OLAP云化的3个关键点的解决：

1. 数据计算引擎开源化：可由Bigdata PAAS直接提供MR、Spark服务；
2. 数据集市云化建设：可由Instance PaaS平台提供开源MySQL+TDDL实现；
3. 数据ETL云化建设：可由Instance PaaS提供Kafka、Big data PaaS提供MR、SPARK实现。

4、PaaS平台问题及传统应用上云改造的一些注意点

（一）基于Kubernetes、Hadoop、Spark on Mesos的问题

这种调度其实是两级的调度框架，Mesos自己只管资源（主要是CPU与MEM），提供offer给上层的调度框架使用。一级调度即Mesos层有两种调度模式：

1. Mesos粗粒度，这种模式下，一旦一台机器（一个Node）分配给某个框架，其余框架便不能使用；
2. Mesos细粒度，这种模式下，多个框架能够共享一台机器（一个Node）。

粗粒度存在资源仍是不能彻底共享的问题，所以仍然有资源浪费的问题，细粒度模式能够改变这种问题，可是又带来新的问题：

1. Mesos集群运行多种框架，包括Spark，也运行着不少Web、中间件、数据库等服务，可是Mesos不支持抢占，没法设置任务优先级，而Spark默认是贪婪模式，这样就会出现Spark运行时没法发布其余Web任务到Mesos集群上的状况。
2. Hadoop与Spark在运行时，Shuffle阶段数据会交互写HDFS磁盘，这时网络资源会被大量占用（咱们称之为东西向流量），致使Web服务基本不能响应（咱们称之为南北向流量）。

（二）多租户的问题

目前多个框架之间每一个都有本身的用户管理模式，默认状况下，若是多个框架之间有交叉使用，须要在多个框架之间租户互相打通，涉及到Mesos、Hadoop、Kubernetes的帐号打通问题，须要开发独立的帐户中心，而且完成同步。

最后讨论一下应用上云时的考虑点，并给出一个例子：

1. 应用最好无状态，无状态化的应用天生适合上云。这时服务的注册于发现、应用的弹性伸缩彻底交给云平台来作，好比Mesos+Marathon的HAProxy+etcd+Confd或者Kubernetes8s的service+RC；
2. 已经集群化的应用组件部署相对困难，好比基于PaaS平台发布单个实例的Redis容器，可是发布Redis集群就比较困难，苦难就困难在Redis集群中的节点须要相互通讯，而容器若是重启或者IP发生变化都会对集群形成影响；
3. 服务注册与发现若是应用自己提供了，PaaS平台的服务注册与发现功能便不能使用，不能两套服务注册与发现同时使用。

这里给出一个应用上云部署的例子：

上图左边是某传统企业电商应用最初架构，Web部署于一台高配置x86服务器、APP部署于一台中端小型机、DB部署于一台中端小型机，右边是初步进行了改造后的架构，即迁移到PaaS平台以前应用已经作了模块化与集群化的初步改造：

1. 前台用负载均衡将流量引入到三个Web节点中，每一个Web节点部署于x86服务器，Session集中存在Redis集群（无状态化改造，交互用HTTP+JSON短链接）；
2. APP层也经过Redis集中存放状态信息，作到了无状态化，每一个APP节点部署于三台x86服务器；
3. Web与APP在流量大的时候能够作到手动扩容，可是须要配置固定的IP，APP服务（提供给）的注册发现是基于ZooKeeper完成（应用本身来完成服务注册于发现）；
4. DB层作了主从数据库，部署与x86服务器。

该应用里面还用到了Kafka，用来作数据总线，也采起了集群化部署。

针对目前的现状，如上图，应用迁移到PaaS平台须要作三方面的工做：

1. 完成Web层的服务注册与发现，在此基础上实现web层的自动扩缩容，此处基于Kubernetes的ingress service（一个改造后的Nginx，运行在一个Kubernetes的POD里面）实现软负载+RC控制节点伸缩实现（每一个Web部署于一个pod）；
2. APP层的自动扩缩容，因为已经完成了基于ZooKeeper的服务注册于发现，因此只需APP层可以弹性伸缩部署便可；此处基于RC控制节点伸缩实现；
3. DB层因为运行稳定，暂时不作PaaS化可是，基于访问路由作到分布式部署。

剩余一个问题须要探讨，Redis集群、ZooKeeper集群、Kafka集群（用做消息总线）要不要作PaaS化？如何作？

首先回答一个问题，Redis、Zookeeper、Kafka等集群PaaS化（容器化）的难点在哪儿？

主要是这些集群节点之间的互相通讯与数据传输即东西向流量，要求这些节点之间的IP配置须要固定IP，并且从新启动之后相应的配置信息不能改变。容器自身的启动、网络配置比较动态化，对须要固定的集群配置而言是一个挑战。

好比大多数的PaaS平台提供单个实例的Redis缓存服务不是问题，可是提供任意配置的Redis集群便不支持。咱们通过前期的测试，实现了容器平台下的此类应用的集群化部署，以ZooKeeper为例：

ZooKeeper自身部署要求：

1. ZooKeeper client依赖固定ZooKeeper server IP来完成服务；
2. ZooKeeper server配置（全部成员IP必须固定）；
3. 至少3个独立节点；

解决方案（基于Kubernetes）：

1. Client经过固定3个service IP链接ZooKeeper server；
2. 构建3个单POD的RC；
3. 配置DeamonSet，指定ZooKeeper的POD所启动运行的主机；
4. ZooKeeper自身配置使用Service DNS name；
5. 存储进行持久化。

最后，须要说明的是，应用上云后一个很重要因素，PaaS平台（Docker为基础的构建），稳定性与可靠性也是相当重要的，咱们在部署迁移应用时，每次都会针对应用作较为详细的测试，测试案例包括：

• 无负载的POD并发测试；
• 频繁建立带业务的POD及其稳定性；
• 业务的并发性测试；
• 不一样业务的IO并发性能测试；
• 容器间网络性能测试；
• 几类常见的数据库性能测试；
• Nginx集群性能测试；
• Kubernetes Rc机制测试；
• Docker对MEM资源限制能力的测试；
• Docker对进程数量限制能力的测试；

等等。这些测试方面供你们参考，具体测试方法与步骤可针对应用自行设计，不在这里具体分享。

Q&A

Q：在你的新一代PaaS平台中，我怎么对公司的不少个不一样的应用作不一样的集群，有些集群偏向于大量的IO占用，有些集群偏向于大量的网络占用，有些集群偏向于大量的内存占用，而且启用的集群间还有通讯和交互，针对这些不均衡现象该如何处理？

A：因此PaaS平台硬件资源会针对不一样应用去作区分，在企业私有云建设时，须要对应用进行梳理，将不一样的应用分类，底层采起相应集群支撑，好比计算密集型、IO密集型等，同时综合考虑波峰波谷与业务特性进行配置。

Q：公司有不少Web系统，每个Web系统都有本身的存储、数据库，因此若是融入PaaS平台的话，首先第一点软硬件问题如何作到所有知足，其次就是就算把个人DB层整合迁徙到你的PaaS的DB层，我是否是还要作其它方面的投入，好比开发成本等等，还有就是DB的兼容性是否是会有问题？

A：Web层咱们推荐作无状态化，且要作应用与数据分离，session信息集中存放。DB迁移到PaaS层是一个比较慎重的过程，PaaS层优先考虑开源数据库。若是原先是MySQL基于PaaS平台也提供的MySQL数据库服务，那么开发成本基本比较小，只需考虑版本问题。

Q：请问MySQL部署数据应用能承载多大数据量，响应速度如何？

A：咱们一个项目中，采用读写分离的MySQL架构，几千万的数据表，及时查询没问题，这也要看硬件配置与数据索引的创建等。

Q：有些传统公司，有些软件设备是以序列号安装使用的，因此这一块融入PaaS平台是否是不太可能？

A：比较困难，另外还有一个问题是License限制的问题，在弹性架构中也比较难。

Q：请问架构改造会不会致使应用要从新开发？

A：会，从IOE架构到x86架构，从x86物理机到虚拟机到Docker，应用须要以愈来愈小的模块化分布式部署，也就是说逐步向微服务化过渡。

Q：为何Kubernetes和Mesos要一块儿用呢，考虑点在哪里？

A：针对单个应用Docker化，咱们开始的选型定位在Kubernetes，主要考虑了POD的应用场景更相似虚拟机，另外Kubernetes的模块比较丰富，像负载均衡、服务发现等已经成熟，后来用Mesos是由于须要把大数据之类的应用进行整合。须要Kubernetes/Spark on Mesos。

Q：开发周期过长或者客户开发能力弱会致使整个架构流产 有配套的应用改造方案吗？

A：对传统企业而言，一开始就搭建一个大而全PaaS方案是不现实的，咱们推荐从某一个典型应用作起。咱们针对交易性应用、分布式应用、批处理应用等应用都有配套改造方案。

Q：Mesos使用集中式存储和分布式存储效率上有什么不一样吗？

A：这个看应用，集中式存储在集群中应用时，若是针对单一与应用划分Volume，性能会好一些，若是是分布式应用，好比MR类的应用，分布式存储反而会好。

Q：容器弹性伸缩策略具体怎么考虑的，CPU？

A：CPU、内存、IO、用户链接数等均可以做为弹性伸缩的策略依据。