PaaS 平台的架构、现状及将来

PaaS 平台的架构、现状及将来

说起云计算平台，大家可能都晓得有IaaS、PaaS和SaaS。IaaS和SaaS的概念大部分人都能很明晰的认知。说到IaaS大多会讲：存储、计算和网络这三大根底资源，说到SaaS大家会想到各品种型的应用，但是说到PaaS就没有一个非常明确的共识。做大数据平台的厂商会数自己的大数据平台是PaaS，做容器云的厂商会数自己的容器平台是PaaS，甚至传统的IaaS厂商会数自己的平台也是PaaS。那么PaaS终究是什么呢？
PaaS的定义

云计算相关概念
我们来说PaaS的定义时就要先理解什么是云计算。云计算是指基于互联网等网络，通过虚拟化方式共享IT资源的新型计算形式。其核心思想是通过网络统一管理和调度计算、存储、网络、软件等资源，实现资源整合与配置优化，以效劳方式满足不同用户随时获取并扩展、按需使用并付费，最大限度地降低本钱等各类需求。

目前云计算提供的效劳形式主要包含三大类：根底设备即效劳（IaaS）、平台即效劳（PaaS）、软件即效劳（SaaS）。
根底设备即效劳（IaaS）
云计算效劳商提供虚拟的硬件资源，如虚拟的主机、存储、网络、安全等资源，用户无需购置效劳器、网络设备和存储设备，只需通过网络租赁即可搭建自己的应用系统。IaaS定位于底层，向用户提供可快速部署、按需分配、按需付费的高安全与高可靠的计算才干以及存储才干租用效劳，并可为应用提供开放的云根底设备效劳接口，用户可以根据业务需求灵敏定制租用相应的根底设备资源。在这种效劳形式下，用户无需考虑对琐碎的根底设备停止管理与维护，用户可直接在根底设备上面方便地加载应用。IaaS效劳对应的用户是系统管理员。
平台即效劳（PaaS）
PaaS提供商提供给用效劳引擎，将软件研发测试和运维的平台作为一种效劳提供，如应用程序接口（API）效劳或应用运行时效劳，用户基于这些效劳构建业务应用。从用户角度来说，这意味着他们无需自行搭建开发，测试和运维平台，也不会在不同平台兼容性方面遇到困扰。PaaS效劳对应的用户是应用的开发者和运维人员。
软件即效劳（SaaS）
用户通过规范的 Web 阅读器来使用网络上的软件。从用户角度来说，这意味着前期无需在效劳器或软件容许证受权上停止投资；从供给商角度来看，与常规的软件效劳形式相比，维护一个应用软件的本钱要相对低廉。SaaS供给商通常是依照客户所租用的软件模块来停止收费的，因而用户可以根据需求按需订购软件应用效劳，而且SaaS的供给商会负责系统的部署、晋级和维护。SaaS提供商对应的用户是应用软件使用的终端用户。
PaaS
平台即效劳（PaaS）与根底设备即效劳（IaaS）是不同的，PaaS并不是IaaS的一个扩展特性，对于根底设备即效劳（IaaS）来说，根底单元就是资源，这里的资源是指效劳器，磁盘，网络等，IaaS所做的一切就是依照需要提供这些资源。例如，亚马逊（amazon）的EC2效劳，所有的工具都以资源为中心，所有的文档都是关于资源的，所有的开发都是专注于资源，同时人们也因为需要这些资源而使用它。
对于平台即效劳（PaaS）来说，根底单元就是应用。那么什么是应用？就是一个系统，就是代码以及所有那些在任何时候都与这些代码通信的效劳。这不只仅是资源，事实上，一个应用是由很多单独的资源绑定在一起组成的。将所有这些资源连接在一起所需要付出的工作量通常被低估了。从一个单一的运行Apache和Mysql的效劳器转移到一个拥有单独的负载平衡效劳器，缓存效劳器，应用效劳器，数据库效劳器以及冗余的失效恢复的系统架构需要大量的工作，包括前期投入以及后期维护。一个成熟的PaaS平台可以为用户提供上述的所有功能，在减少用户大量工作的前提下，大幅度提升用户应用的开发速度，运行稳定性，可靠性，极大的降低了用户的开发，测试及运维的本钱。
利用PaaS可以做的另外一件事，就是从应用的角度来管理IaaS。通常情况下，使用者对于IaaS的资源需务实质上是来源于运行在IaaS之上的应用，如何根据应用的需求动态的使用IaaS资源又成为摆在云使用者面前的一个难题，PaaS作为SaaS与IaaS的沟通者，可以根据SaaS的需求动态的协调IaaS资源，使IaaS按需分配资源的理念变得更智能，更有实际意义。
IaaS为云使用者提供了按需分配的才干，用户可以依照自己的需求定制计算资源，存储资源，网络资源，并且利用云端的海量资源随时快速的开启资源，并在工作完成时，随时释放资源，在享受云带来的高可靠性的同时，也最大化的降低了使用本钱，提升了资源利用率。
但是IaaS为云使用者带来的便利只局限在资源这个层面上，云使用者可以快速，稳定，海量的使用资源，但是一旦获取到资源后，云使用者仍然要为运行在资源之上的应用搭建各种适配环境（部署），处置应用的各种依赖，装置应用要使用的各种效劳，维护应用的运行生命周期。这些问题IaaS都没有处置，或者说，这些问题实质上也不是IaaS需要处置的问题，而是PaaS需要处置的问题。
综上，IaaS关注与硬件的自动化管理，目的是人与机器的解耦合，提升了效率和性能，而PaaS关注与应用的自动化管理，目的是应用与操作系统的解耦合，提升了弹性和控制。
PaaS的分类
通过上面的介绍，大致可以明晰IaaS、PaaS和SaaS的关系以及面向的用户。在继续介绍PaaS的技术细节前，我们需要理解一下PaaS平台自身的分类。Gartner把它们分为两类，一类是应用部署和运行平台APaaS（Application Platform As a Service），另一类是集成平台IPaaS（Integration Platform As a Service）。

APaaS是一种面向IT企业和机构的云计算应用开发与部署平台。APaaS主要为应用提供运行环境和数据存储，可以将本地部署的传统应用直接部署到APaaS上。IPaaS是用于集成和协同的PaaS平台，不只可以支持与现有云效劳间的连接性，而且可以以安全的方式提供企业应用的访问才干。IPaaS主要用于集成和构建复合应用。

大数据厂商的PaaS实际上是属于IPaaS，而容器厂商和IaaS厂商的PaaS大致为APaaS。
APaaS的一般特性
大规模分布式系统：

完全模块化的分布式系统，保证云平台可靠性；每个模块单独存在和运行，通过消息总线停止通讯；系统耦合度低，便于弹性动态扩展；

弹性伸缩框架：

平台自身组件支持实时横向扩展;根据应用的负载情况，动态加载应用实例；应用实例支持实时水平扩展；

运维自动化：

日常运维操作简化;故障自动恢复;

应用部署简单化：

一键式应用快速部署;支持多种应用开发框架，包括Spring、.NET、Ruby on Rails，Node.js等;通过buildpack扩展运行不同语言应用的才干;

支持多种效劳：

支持多种数据效劳，包括MySQL、mongodb、PostgreSQL等;通过service broker组件扩展多种应用效劳才干，包括数据库、中间件、缓存、云存储等。

主流PaaS平台架构及对比

理解了PaaS的分类，我们再来看看PaaS的详细技术对比。由于IPaaS具有很强的业务属性，因而这里我们主要来看一下更通用的APaaS，也是目前被大家最多提起的。说到PaaS，相信很多人都会把他和容器、Docker关联起来。下面来看几张图：

上面这张图可以看出来冷静器、编排、部署都自称为PaaS。

正如国内的容器厂商都自称为PaaS平台一样，目前大多数人提到PaaS都会想到容器。每过几年总会有新的概念出来。下面再来看一张图。

这张图很明晰的划分出了XaaS以及各种概念对应的平台。大家所熟知的容器平台在这里实际上是CaaS的一种。那么CaaS和PaaS有什么区别呢？我们接下来对比一下CaaS和PaaS里面最具代表性的两个平台：CaaS和CloudFoundry。
Docker/CaaS
Docker/CaaS 提供直接收理操作根底设备的性能，带来根底设备层面的灵敏性。用户 通过直接操作容器可以更灵敏的实现应用迁移、部署。但这个更加轻量的平台带来了用户学 习本钱和使用复杂度的增加。
容器云平台的搭建只依托 Swarm/Mesos/K8s 等容器编排调度系统就可以实现，还需 要引入大量的第三方处置方案，例如日志、监控、网络等。这就意味着一定的试错本钱，另 外第三方系统的成熟度开展不一，组成一套统一的云平台后进入消费环境的应用需要经过一 定周期的论证和验证。
Cloud Foundry 平台
Cloud Foundry 隐藏了根底设备层面的复杂度，提供给用层的管理操作，简化根底设 施和应用的构建管理，平台也使用容器技术，但仅仅是平台架构中的实现细节。通过 CF 可 以更加敏捷的实现应用开发、部署、业务实现等。
Cloud Foundry 的架构是一个相当完好的 PaaS 架构，模块丰富，平台自身可以提供 对于平台节点、应用的监控、管理，日志，自动化运维等完好的处置方案。每个模块都部署 在一个或多个虚拟机上。这些虚拟机是自动创建的，由 PaaS 管理他的生命周期。它的应用 部署跟 Docker 镜像部署不太一样，它是把程序包直接部署。一个命令行或是一个点击就可 以部署
在经过长时间的应用，Cloud Foundry 已有很多在消费环境的案例。Cloud Foundry 率先采用 RunC 作为容器运行时，而且刚刚做了一个 25 万个容器集群的测试，验 证了 PaaS+RunC 的大规模集群的支持。
可以这样来说：容器技术是PaaS平台的底层技术，是PaaS平台不可缺少的部分。但是把容器平台说成PaaS，难免会有点以偏概全了。

特性	Cloudfoundry	Docker／CaaS
应用部署方式	直接部署程序Release包	需要制作Docker镜像
监控	完好处置方案	需要集成第三方工具
日志	完好处置方案	需要集成第三方工具
网络	完好处置方案	需要集成第三方工具
自动化运维	可以和IaaS联动	不支持IaaS联动

PaaS平台和SaaS应用市场的关系

大家有没有发现一个现象？10年以前，SaaS应用市场是非常少的。如今各大平台都会有自己的SaaS应用市场。呈现这种现象的原因无外乎技术的进步，搭建SaaS应用市场的本钱降低了。更确切的说：SaaS应用市场是PaaS平台的一种外延。在底层PaaS技术的支撑下，SaaS应用的开发、交付、运营的门槛大幅度的降低了。
基于PaaS平台构建的SaaS应用市场会逐步加快SaaS应用生态的开展。
PaaS平台下停止云原生应用开发

有了PaaS平台帮我们处置底层平台的问题，那么我们的应用开发者要怎么做才干开发出云原生应用呢？12-Factor 为构建如下的云原生应用提供了方法论：

使用规范化流程自动配置，从而使新的开发者花费最少的学习本钱参与这个项目。和操作系统之间尽可能的划清界线，在各个系统中提供最大的可移植性。适宜部署在现代的云计算平台，从而在效劳器和系统管理方面节省资源。将开发环境和消费环境的差别降至最低，并使用持续交付施行敏捷开发。可以在工具、架构和开发流程不发生明显变化的前提下实现扩展。

这套理论适用于任意语言和后端效劳（数据库、消息队列、缓存等）开发的应用程序。
下面我们一起来看看详细包含哪些要素：

基准代码：一份基准代码，多份部署依赖：显式声明依赖关系配置：在环境中存储配置后端效劳：把后端效劳当作附加资源构建，发布，运行：严格分别构建和运行进程：以一个或多个无状态进程运行应用端口绑定：通过端口绑定提供效劳并发：通过进程模型停止扩展易处置：快速启动和优雅终止可最大化强健性开发环境与线上环境等价：尽可能的坚持开发，预发布，线上环境相同日志：把日志当作事件流管理进程：后台管理任务当作一次性进程运行

PaaS的将来开展

先抛一个结论：PaaS是云的将来。
IaaS是一个资源转售的生意，PaaS代表了云计算的将来，PaaS处置的是平台架构的问题，同时也是真正做到按需付费。对于业务客户而言，底层技术不会给他们带来直接的业务价值，这也就决定了软件开发商更应该聚焦在业务层。高并发、高可靠、存储效劳、应用自身维护等和业务不直接关联的平台效劳都可以借助PaaS技术来完成。如今的创业团队可以借助各类PaaS技术快速的创建高并发、高可靠的应用，将来这种形式也会进一步普及。

更交融的调度 物理机、虚拟机和容器各有优势，一个复杂的应用场景会用到各计算平台的优势，交融调度将来必然会成为主流框架。更交融的编排 说到调度，就离不开编排。当前阶段上云是大趋势，私有云加公有云的形式会长期持续。那么交融的编排框架也必然会成为处置本钱问题的一个重要选择。更细粒度的弹性 IaaS处置了根底设备的弹性，但是还不够。技术的开展会进一步细化弹性的粒度，往更节约的方向开展。更高的资源利用率 当前的技术及架构下，计算资源很大一部分时间都是闲置的。以有限的资源来应对更高的数据处置要求，资源利用率会随着云技术的开展进一步进步。