面向云托管的全栈PaaS解析

面向云托管应用的全栈开发运维环境（平台即服务）

摘要

如果每个云托管应用的程序员都具备卓越的技术能力和无限的耐心，那么开发运维环境（也称为平台即服务，或PaaS）或许会变得无关紧要。然而，现实情况几乎总是相反。因此，IT工程师们渴望拥有一个可靠且易用的 DevOps环境，以显著促进其开发工作并简化运维操作。当前的DevOps环境包括Google App Engine、Docker、 Kubernetes、Mesos等。换句话说，PaaS弥合了活跃的IT工程师与僵化的云系统之间的差距。本文全面审视了云计算DevOps栈各个层级上的最先进的PaaS解决方案。在此基础上，我们分析了这些方案在理念与方法上的共识与差异。此外，我们还探讨了实现更细粒度、全栈DevOps环境的前沿解决方案。通过本文，读者将能够快速掌握平台即服务的核心内容、当前状况及未来前景。

关键词 : 云计算；平台即服务（PaaS）；开发运维；开发；运维；环境

1 引言

近年来，云计算的出现使IT行业发生了根本性变革。
云计算被广泛认为包含三个层次：基础设施即服务 （IaaS）、平台即服务（PaaS）和软件即服务 （SaaS）。在这三个层次中，IaaS系统（例如亚马逊网络服务和微软Azure）提供虚拟机（VM） 和对象存储等基础基础设施功能，并已获得IT市场的最多关注。因此，IaaS标准化已趋于成熟。相比之下，目前在线提供了多种多样的SaaS系统（例如Salesforce、Gmail和Office 365）。由于 SaaS系统最接近最终用户，大多数互联网用户都熟悉它们。介于 IaaS和SaaS之间的是PaaS系统（例如Google App Engine、Google Borg和Docker），它们连接了IaaS和SaaS系统。尽管许多云用户并未意识到PaaS的存在，但云开发者和运营商最近已将其视为日益重要[1]。此外，目前越来越多的初创公司正专注于PaaS项目和市场。

从技术角度来看，PaaS系统被视为云托管应用程序的开发运维（Development和 Operations的缩写）环境。换句话说，PaaS旨在提供高效的工具，帮助IT工程师快速构建云应用。云计算最初被提出是为了让程序员摆脱管理服务器、交换机和路由器等琐碎细节的负担。然而在实践中，由于云计算的技术复杂性，IT工程师的工作效率仍然受到影响。

云计算几乎涵盖了计算机科学与技术的各个领域，因此涉及全栈技术。然而，在就业市场上，熟练的全栈工程师十分稀缺；大多数工程师仅在堆栈的某一层级具备专长，例如Web服务。因此，云计算工程师必须应对涉及硬件、操作系统（OS）、容器（例如 cgroups[2], Docker和Rocket[3]）、数据库（DB）、传输控制协议/互联网协议（TCP/IP）、域名系统（DNS）以及防火墙等方面的复杂配置、部署和性能问题。因此，IT工程师梦想有一天能够拥有一个可靠且可用的开发运维环境，以显著促进其开发工作并简化运维操作，即弥合活跃的IT工程师与僵化的云系统之间的差距，如图1所示。

具体而言，如图2所示，面向云托管应用的全栈DevOps环境（或平台即服务）必须至少提供以下功能：（1）应用程序编码、构建和测试，（2）虚拟机/容器监控，（3）资源管理，（4）任务调度，（5）并发协调，（6）系统日志分析，以及（7）信息可视化。此外，还有一些高级和扩展功能，例如RESTful（其中REST代表表述性状态转移）的应用程序编程接口（APIs）、团队协作、服务集成、安全防护和隐私保护。简而言之，平台即服务（PaaS）总结并提炼了先驱云计算工程师在应用开发与运维方面的宝贵经验和共同努力。其关键目标是为IT工程师提供一个强大且智能的助手，使其能够快速发布具备多种理想特性的云托管应用，包括可扩展性、可靠性、安全性、并发性和成本效益。

本文旨在作为PaaS的通俗易懂的入门介绍，同时简要概述现有及新出现的PaaS技术。读者无需具备云计算专业人士背景。首先，在第2节中，我们考察了跨越云计算DevOps栈各个层级的一系列最先进的 PaaS解决方案（例如Google App Engine、Google Borg、AWS Elastic Beanstalk、微软 Azure Stack、OpenStack Horizon和Magnum、 VMware Cloud Foundry、Docker、Puppet、 ZooKeeper以及Hadoop YARN）。在此基础上，我们在第3节中分析了这些方案在理念与方法上的共识与差异。此外，在第4节中，我们探讨了若干前沿解决方案（例如谷歌Kubernetes、Apache Mesos、 Heroku以及我们最近开发的Cloud Studio），以期构建更加细粒度的全栈DevOps环境。最后，我们在第5节中提出总结。

2 最先进的PaaS解决方案

所谓“最先进的”是指PaaS解决方案在其用户群中广受欢迎，或代表了最新的技术方法。我们首先考察三大国际市场巨头——谷歌、亚马逊网络服务 （AWS）和微软Azure的PaaS解决方案。接着，我们介绍来自OpenStack、VMware和 dotCloud的开源解决方案。最后，我们引入三种用于大规模系统配置、协调和资源管理的经典工具，即Puppet、ZooKeeper和Hadoop YARN。

Google App Engine(GAE)

Google App Engine 的主要优势在于它极大地简化了 Web 服务的开发和部署。凭借专为云应用程序设计和实现的软件开发工具包（SDK）库，Google App Engine 提供了一系列有用的功能，可使云应用快速上线。这些功能包括自动资源扩展、分布式缓存、任务和消息队列、可靠的数据存储等。此外，GAE 支持客户端同时访问应用程序的多个版本。根据应用程序开发者的特定设置，客户端请求（或工作负载）可自动路由（或转发）到不同的应用程序版本，从而便于在市场策略开发中常用的 A/B测试或分流测试。

GoogleBorg

尽管这一强大的基础“效率武器”已被用于谷歌的大多数服务中，但Borg一直保密，直到2015年题为“使用Borg在谷歌进行大规模集群管理”的论文发表于ACM EuroSys’15会议论文集[4]才被公开。该论文的发表明确表明了Borg对谷歌的重要意义，因为该公司很少向公众发布其最佳理念和系统。Borg旨在高效管理大规模分布式服务器集群并实现高利用率。具体而言，Borg被用来运行数十万个作业，服务于数千个谷歌服务/应用。它跨越多个集群，每个集群包含多达数万台物理服务器。

为了显著提高每台物理服务器的资源利用率，Borg 做出了三个关键选择。首先，Borg 不使用虚拟机，因为虚拟机会严重降低物理服务器的工作效率；相反，它采用轻量级的 Linux 容器（LXC 或 cgroups）。其次，所有在 Borg 上运行的作业被划分为两种异构工作负载之一：面向终端用户的 服务（或长时运行的服务）和批处理作业，以便应用不同的资源管理和任务调度策略。第三，应用程序以混合方式部署在物理服务器上，即多个逻辑隔离的应用可以在同一台服务器上运行，而传统做法是每个应用程序运行在专用独占的服务器集群上。

AWS Elastic Beanstalk和其他产品

作为云计算市场的开创者和主导力量，AWS提供了弹性Beanstalk系统，以帮助开发者在其平台上快速、便捷地部署和管理应用程序。从某种意义上说，AWS Elastic Beanstalk的方案在外观上与 Google App Engine类似。事实上，AWS提供的PaaS工具远不止弹性Beanstalk。例如，AWS已发布了多个用于应用程序的开发人员工具（如 CodeCommit、CodeDeploy 和 CodePipeline）以及系统运维人员工具（如 CloudWatch、CloudFormation、CloudTrail、Config、Console、OpsWorks 和 服务目录）。

MicrosoftAzure Stack

尽管进入云计算市场的时间相对较晚，但微软Azure已稳居第二位，仅次于AWS。它明确将自己定位为云托管应用的全栈开发运维环境。从纯粹的PaaS视角来看，微软 Azure Stack中至少有数十种服务/系统值得关注。例如，Azure为开发者提供了多种工具：Visual Studio团队服务、Visual Studio应用洞察、开发测试实验室、Xamarin（用于更快地创建基于云的移动应用程序）以及存储资源管理器等。此外，Azure还提供了一些有用的监控和管理工具：Azure资源管理器、调度器、日志分析、自动化、站点恢复等。

OpenStack Horizon和Magnum

作为开源云计算解决方案的事实标准，OpenStack也已进入平台即服务（PaaS）层。自诞生以来，OpenStack提供了Horizon，这是一种用于云计算系统的信息或资源可视化工具（也称为仪表板）。如图3所示，通过OpenStack Horizon，用户可以清楚地看到自己拥有多少台服务器、每台服务器的资源水平以及每台服务器的运行状况。同时，OpenStack Horizon充当系统资源管理的粗粒度控制台，从而为用户提供了便捷的一键启动、关闭、待机和休眠操作。最近，OpenStack社区发布了一种名为 Magnum 的新工具，可有效支持容器的运行。

VMwareCloud Foundry

著名的虚拟化公司 VMware 近年来在“开源”计算领域似乎无关紧要（否则，开源的 VirtualBox 项目可能就不会出现）。然而，令许多人惊讶的是，VMware 在 2011年4月 发布了首个开源的完整平台即服务解决方案，名为 Cloud Foundry。基于 Ruby on Rails 构建，Cloud Foundry 作为一个由多个独立子系统组成的分布式系统，子系统之间通过消息传递进行通信。使用同一套代码库，该系统可以部署在大型数据中心、几台个人计算机或一组公有云虚拟机上。熟悉 OpenStack 理念设计的人可能会注意到 Cloud Foundry 与 OpenStack 之间存在相当大的相似性。

Docker

由于在短时间内获得了巨大的流行度，大多数人听说过Docker的人并不了解创建它的公司——dotCloud。作为近几年云计算市场中最热门的技术，Docker通过利用cgroups和命名空间等 Linux内核特性，使应用程序能够在独立（即逻辑隔离）的容器中运行。由于大量容器共享同一个 Linux内核，Docker的资源利用率和工作效率远高于虚拟机。Docker的设计理念与Google Borg明显相似。在IT行业中，效率与兼容性常常相互矛盾，Docker也不例外。尽管效率高，Docker在兼容性方面仍有一些不足，例如不支持32位架构或 Windows服务器。此外，Docker资源的共享程度增加导致其容器隔离性降低，因此有时会引发安全问题。

Puppet和ZooKeeper

对于从AWS EC2购买并维护100台虚拟机的用户而言，通常需要在这些虚拟机上执行相同或类似的运维操作。与其手动输入并运行数百条重复的Shell命令，用户可以考虑编写一个简短的Puppet脚本（例如100‐VM.pp）。Puppet是一种经典的适用于Linux、Unix和 Windows平台的集中式配置管理系统。通过 Puppet，系统管理员或运维人员可以轻松地管理大量重复且琐碎的配置细节。Puppet 采用简单的客户端/服务器（C/S）架构来组织系统节点，使得普通 IT工程师 能够顺畅且轻松地使用。然而，集中式的 C/S 架构可能会成为系统瓶颈。

ZooKeeper 近年来已成为分布式协调和配置管理的流行工具。尽管它比 Puppet 更复杂，但比 Paxos[5]要简单。它在分布式系统中提供了许多所需的功能，例如分布式锁、消息队列、主节点选举和动态配置。在分布式协调的科学理论中，理想的方案是莱斯利·兰波特设计的 Paxos 协议，Paxos 已在谷歌 Chubby 系统中得到实际实现。然而，由于 Paxos 全面考虑了各种可能的情况，因此非常复杂。作为一种日常现实世界的分布式系统，Paxos 常被视为“过度设计”。为此，尽管 ZooKeeper 遵循 Paxos 的基本原理，但它通过建立一个实用且高效的 ZooKeeper原子广播（ZAB）协议，简化了其在现实世界中的实现。目前，许多 PaaS系统 使用 ZooKeeper，例如 Apache Mesos 的资源管理器和 Apache Kafka 的消息队列。

Hadoop YARN

YARN 是“Yet Another Resource Negotiator”的缩写，因此它显然是为 Hadoop 的资源管理而开发的。为什么是“Yet Another”？因为在 YARN 出现之前，Hadoop 原有的资源管理器具有可扩展性限制（例如，一个 Hadoop 服务器集群几乎无法容纳超过 4000 个节点）以及不理想的资源利用率。受这些困难的推动，YARN 开发人员设计了一个两层资源调度器，即 ResourceManager+ ApplicationMaster，其中特定任务的调度策略由相应的应用程序（即所谓的 Application Master）而非单一实体来决定。这些改变显著改善了 Hadoop 的规模限制和资源利用率。

3 共识与多样性

基于上述最先进的PaaS解决方案，我们识别出其中多数方案所遵循的一些共同原则。以下是几个关键的云托管应用开发与运维中的共识点：

• 没有一种平台即服务解决方案能够适用于所有场景或满足所有需求 ，即使它是功能齐全的或覆盖整个技术栈。因此，云应用程序开发者和运营商必须针对特定场景开发专用解决方案，而不是试图打造一种万能的单一解决方案。

• 在实践中，可用性和可靠性远比其他性能指标重要 。尽管学术界的解决方案（例如 Spark）似乎在性能上远超工业界的解决方案（例如 Hadoop），但前者短期内不太可能取代后者。在现实场景中，用户界面、安全防护、代码审查、调试难度以及社区的成熟度往往是主要因素。

• 虚拟机和容器都不能充当实际的物理机器 。几乎所有的虚拟机提供商（例如 AWS EC2 和阿里云ECS）都警告用户应仅以无状态方式使用虚拟机，即尽量避免在虚拟机中存储持久化数据，因为它可能随时崩溃甚至消失[6,7]。毫无疑问，容器更加脆弱。

• 容器不太可能占据虚拟机的整个市场，因此两者之间的市场份额可能会保持一种动态平衡 。一般来说，容器与效率和利用率相关，而虚拟机则具有更好的兼容性和隔离性。事实上，在虚拟机中运行容器很可能会成为开发和运营云托管应用程序的一种流行范式。

• 服务等级协议（SLA）对客户而言比对供应商更重要 。SLA并非法律，甚至许多法律在某些情况下也得不到遵守。此外，很少有云客户能够准确定义和衡量SLA中列出的性能指标。大多数客户从未测量过其相关的性能指标。因此，对于云客户来说，在与云供应商的讨论中，无需过于严肃地对待SLA，而应将其作为参考和指导。

• 公有云有助于初创公司，而私有云则有利于行业资深企业 。对于一家初创公司而言，使用AWS EC2+ S3+ RDS 可以在基础设施上节省大量时间和资金维护。然而，由于在这种情况下基础设施是一个“黑箱”，因此在优化系统效率方面会失去大量机会。这就是为什么Dropbox在最初几年完全依赖亚马逊S3进行文件内容存储[8,9]，但此后已将其绝大部分文件内容数据迁移到其私有对象存储云Magic Pocket[10]。

另一方面，我们发现PaaS解决方案在功能、流行度、成熟度和开放性方面存在显著差异。随着特定PaaS解决方案提供的服务变得更加细粒度，其对上层应用的限制也相应增加。因此，目前尚无一种被广泛认可的PaaS解决方案能够满足各方的需求。当一种PaaS解决方案在某些层级或指标上表现良好时，通常会在其他方面表现不佳。在两个极端上出现了受限的和开放的PaaS解决方案。

受限的平台即服务（PaaS）解决方案 会充分或主要利用底层资源，即计算、存储和网络资源。然而，应用程序开发者通常必须遵循特定的私有约束条件，涉及数据格式和API。有时，应用程序开发者可能被限制只能使用某些编程语言。Google App Engine（GAE）是受限PaaS的典型代表。当程序员基于GAE构建应用程序时，可以利用 Google 云计算平台内的技术和资源，但需受限于多种限制，例如库支持有限、编程语言支持受限、仅支持HTTP风格的API，以及缺乏持久会话状态。

在另一个极端， 开放的PaaS解决方案 对开发者的程序代码不施加侵入性限制，而是给予应用程序开发者尽可能保留其原始编程语言、系统框架、组件和容器的自由。Heroku（详见第4节）就是一种开放解决方案的代表，支持所有主流编程语言以及Ruby等相对“小众”的语言。

在这两个极端之间，存在一些半开放的PaaS解决方案，它们将源代码公开，例如OpenStack、Docker和Cloud Foundry。例如，为了提高 Docker的开放性，dotCloud将其开源，并为所有Docker用户维护一个集中式仓库[11]，以便用户自由上传他们的Docker镜像，并轻松查找所需的其他Docker镜像。

4 前沿探索

在明确了现有PaaS解决方案在哲学和方法论上的共识与差异之后，我们现在探讨一系列前沿解决方案，以实现更细粒度的全栈开发运维环境。

谷歌Kubernetes

“Kubernetes”不是一个常见的英文单词，因此许多人经常使用其缩写“K8s”。术语“Kubernetes”源自古希腊语，意为舵手或领航员。据说谷歌使用这个名字有其微妙的用意（如图4所示）：鉴于Docker将自身比作在海上航行并携带容器的鲸鱼，Kubernetes则在引导这一“容器时代”的方向。尽管Kubernetes的推出时间比本文撰写时间仅早一年左右，但如今它已占据比Docker略大的市场份额，并获得了多家云计算市场巨头的强力支持。

目前，大多数人倾向于将Kubernetes视为 Docker的上层框架。也就是说，Kubernetes团队基于Docker构建了一个以服务为中心的分布式系统，在该系统中，服务可以在需要时自动扩展并自我诊断。同时，为了摆脱对Docker的依赖，Kubernetes现在支持另一种由CoreOS开发的竞争性容器技术Rocket，如图5所示[3]。

Kubernetes 常被视为 Google Borg 的开源版本。除了其开源特性外，Kubernetes 在提升开放性方面也取得了显著进展。例如，无论使用哪种编程语言编写应用程序，该应用程序都可以直接映射到Kubernetes服务，然后通过基于标准TCP的协议与互联网或其他服务进行通信。最显著的是，Kubernetes在服务器节点与其上运行的容器之间新增了一个独特的Pod层，如图2所示。多个容器可以在同一个Pod中同时运行，从而有效提升这些容器之间的数据通信效率。最近，IT行业出现了一种新颖且热门的“微服务”理念，即将一个集成服务分解为多个通过网络通信连接的独立的微服务。从这个意义上讲，Kubernetes正是为支持微服务而量身打造的。

ApacheMesos

与Docker和Kubernetes相比，Mesos更加开放且具有更细的粒度，因此被称为“分布式系统的内核”。Mesos最初由加州大学伯克利分校著名的AMPLab[13]开发，随后在 Twitter得到广泛应用。Mesos项目启动一年后，其发起人本·欣德曼与其加州大学伯克利分校的团队成员访问了Twitter。当时只有八名工程师到场，这让本·欣德曼感到失望。然而，这八名工程师中有三人后来加入了Mesos项目，且均为前谷歌员工。他们告诉本·欣德曼，他们曾（遗憾地）错过了参与Google Borg的机会，这次不想再错过Mesos以及利用更好方法“重构”Google Borg的机遇。

为了实现更高的开放性，与 Docker 和 Kubernetes 相比，Mesos 具有两大主要变化。首先，Mesos 明确将资源管理与任务调度分离，从而使应用程序能够更好地获取其所需资源。其次，Mesos 提供弹性框架接口，以容纳来自其他系统的框架，例如 Marathon[14] 和 Spark[15]。

此外，为了改进资源管理，Mesos 团队提出了一种名为 DRF（即主导资源公平性[16]）的新型资源分配策略。DRF 的思想源于许多 IT 工程师的观察：当存在多种类型的资源时，合适的资源分配策略应关注用户所需资源的主导份额。例如，假设 Mesos 正在从一台物理服务器向两个用户 A 和 B 同时分配资源，其中用户 A 正在运行 CPU密集型任务，而用户 B 正在运行内存密集型任务。在这种情况下，DRF会努力为 A 的任务分配更多 CPU 资源，为 B 的任务分配更多内存。

Heroku

Heroku成立于2007年，于2010年被Salesforce收购，在云计算市场经历了数年的挣扎。然而，近年来Heroku因其中立、开放的 PaaS平台而受到关注。为了应对或缓解大量 PaaS解决方案对用户应用程序代码的侵入及其引发的“云锁定”问题，Heroku设计并实现了一个高度可移植的PaaS平台，力求“兼容所有主流 PaaS解决方案”，如图6所示。此外，通过全面的观察和技术实践，Heroku团队提炼出智慧地开发和运营云托管应用所需的12要素[17]。值得注意的是，2011年，Ruby的发明者加入Heroku担任首席架构师，这反映了编程社区对Heroku的积极态度。

Cloud Studio（目前处于Alpha阶段）

几乎所有主流的PaaS系统都是由谷歌和亚马逊等大型企业开发的。然而，这并不意味着小型企业和组织无法为PaaS做出贡献。事实上，小型团队可以构建特定的PaaS解决方案以满足特殊要求。例如，本文作者（与清华大学的其他几位团队成员一起）设计并部署了一个名为Cloud Studio的开源PaaS系统，该系统在 http://thucloud.com上公开提供，不久也将在 http://cloudcomputing.studio上提供。Cloud Studio最近发布了一系列针对云托管应用的实用 DevOps工具：VirtualPool（用于容纳虚拟机和容器）、iDashBoard（用于显示系统信息和方便用户操作）、双云Web加速（特别针对谷歌、 Gmail、GitHub和Dropbox）、云盘（用于存储用户文件）、iRecommend（基于大数据分析推荐专业人士）等。

关于iDashBoard工具，我们首次实现了针对虚拟机操作的细粒度进度条（见图7），取代了现有PaaS解决方案中使用的简单粗粒度旋转圆圈（见图3）。该实现并非易事，因为其准确性高度依赖于物理服务器、虚拟机和虚拟机管理器（VMM）之间的紧密协调。如图8所示，iDashBoard在物理服务器中部署了一个代理，在虚拟机中部署了一个客户端，通过该代理与虚拟机监控器和客户端读取虚拟机信息。同时，代理和客户端向外部的iDashBoard服务器报告。在不久的将来，我们计划为云计算系统实现一个实时、可视化的拓扑图，以取代当前PaaS解决方案中使用的繁琐的线性列表。

5 总结

如今，云计算是一个快速发展的行业，竞争激烈，其开发运维环境或平台即服务（PaaS）也不例外。目前尚不存在统一的PaaS API或数据格式，三大市场巨头（即AWS、谷歌云和微软Azure）仍坚持各自的PaaS标准。因此，Heroku所提出的统一的PaaS愿景尚未实现。为了开发出合适的“最佳”解决方案，许多开发运维团队正以当前最先进的 PaaS解决方案为参考，并利用开源PaaS相关工具构建自身最优的PaaS解决方案。对于当今急需解决方案的IT工程师而言，这一过程是否过于复杂？

在我们看来，答案是否定的。正如我们反复提到的，云计算技术正在快速而显著地发展，因此不断产生新的概念和工具。例如，当IT工程师刚刚掌握Hadoop（MapReduce）时，Spark被引入，据说其性能比Hadoop高出100倍。此外，当IT工程师掌握了Docker的运维操作后，Kubernetes 和Mesos又随之出现，提供了更细的粒度和更高通用性。如果工程师试图掌握所有新技术，他们很快就会筋疲力尽。

幸运的是，尽管云计算已经创造了一种在这一新兴市场中，实际上涉及的全新技术并不多。一旦我们审视云计算的技术栈，就会发现大多数云计算工作都集中在系统架构和资源管理上，而其核心资源问题始终是计算、存储和网络。换句话说，IT行业关键技术的本质从未改变。这些技术包括程序的编译、链接、加载和执行；操作系统对中央处理器、内存和磁盘I/O的管理；以及基于TCP/IP的协议。明智的工程师能够识别出纷繁复杂的新技术背后简单基础，从而主动适应而非被其牵制。