全栈PaaS开发运维一体化

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

摘要

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

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

1 引言

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

从技术角度来看，PaaS系统被认为是云托管应用程序的开发运维一体化（开发与运维的缩写）环境。换句话说，PaaS旨在提供高效的工具，帮助IT工程师快速构建云应用。云计算最初被引入是为了让程序员无需再操心服务器、交换机和路由器等繁琐细节。然而在实践中，由于云计算的技术复杂性，IT工程师的工作效率仍然受到影响。
云计算涵盖了计算机科学与技术的几乎所有领域，因此涉及全栈技术。然而，在就业市场上，熟练的全栈工程师十分稀少；大多数工程师仅在堆栈的某一层次具备专长，例如Web服务。因此，云计算工程师必须应对涉及硬件、操作系统（OS）、容器（例如cgroups、Docker和Rocket）、数据库（DB）、传输控制协议/网际协议（TCP/IP）、域名系统（DNS）以及防火墙等方面的复杂配置、部署和性能问题。因此，IT工程师梦想有一天能够拥有一个可靠且易用的DevOps环境，以显著促进其开发工作并简化运维操作，即弥合充满活力的IT工程师与僵化的云系统之间的差距，如图1所示。

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

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

2 最先进的PaaS解决方案

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

谷歌应用引擎 (Google App Engine)

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

Google Borg

尽管这一强大的基础性“效率武器”已被用于谷歌的大多数服务中，但直到2015年题为《通过Borg实现Google的大规模集群管理》的论文在国际计算机学会EuroSys’15会议论文集上发表后，Borg才被公开。此次发布明确表明了Borg对谷歌的重要意义，因为该公司极少向公众披露其最优秀的思想和系统。Borg旨在高效管理大规模分布式服务器集群并实现高利用率。具体而言，Borg被用来运行数十万个作业，服务于数千个谷歌服务/应用。它跨越多个集群，每个集群包含多达数万台物理服务器。

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

AWS Elastic Beanstalk 和其他服务

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

微软Azure Stack

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

OpenStack Horizon和Magnum

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

VMware Cloud Foundry

著名的虚拟化公司VMware过去似乎与“开源”计算无关（否则，开源的VirtualBox项目可能就不会出现）。然而，令许多人感到意外的是，VMware在2011年4月发布了首个开源的完整平台即服务解决方案，名为Cloud Foundry。Cloud Foundry基于Ruby on Rails，作为一个由多个独立子系统组成的分布式系统，这些子系统通过消息传递相互通信。使用相同的一套代码库，该系统可以部署在大型数据中心、几台个人计算机或一组公有云虚拟机上。熟悉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简单。它在分布式系统中提供了许多所需的功能，例如分布式锁、消息队列、主节点选举以及动态配置。在分布式协调的科学理论中，理想的方案是莱斯利·兰波特设计的Paxos协议，Paxos已在谷歌Chubby系统中得到实际实现。然而，由于Paxos全面考虑了各种可能的情况，因此非常复杂。作为一种日常现实世界的分布式系统，Paxos常被视为“过度配置”。为此，尽管ZooKeeper遵循Paxos的基本原理，但它通过建立一个实用且高效的ZooKeeper原子广播（ZAB）协议，简化了其在现实世界中的实现。目前，许多平台即服务系统使用ZooKeeper，例如Apache Mesos的资源管理器和Apache Kafka的消息队列。

Hadoop YARN

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

3 共识与多样性

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

• 没有一种平台即服务解决方案能够适用于所有场景或满足所有需求，即使它是功能齐全的或覆盖全栈的。因此，云应用程序开发者和运维人员必须针对特定场景开发具体解决方案，而不是试图打造一种万能的单一解决方案。
• 在实践中，可用性和可靠性远比其他性能指标重要。尽管学术解决方案（例如Spark）似乎在性能上远超工业级解决方案（例如Hadoop），但前者很可能在短期内无法取代后者。在现实场景中，用户界面、安全防护、代码审查、调试难度以及社区成熟度往往是主要因素。
• 虚拟机和容器都不能充当实际的物理机器。几乎所有虚拟机提供商（例如AWS EC2和阿里云ECS）都警告用户应仅以无状态方式使用虚拟机，即尽量不要在虚拟机中存储持久化数据，因为它随时可能崩溃甚至消失。毫无疑问，容器更加脆弱。
• 容器不太可能占据虚拟机的整个市场，因此两者之间的市场份额可能会保持一种动态平衡。一般来说，容器与效率和利用率相关，而虚拟机则具有更好的兼容性和隔离性。事实上，在虚拟机中运行容器很可能会成为开发和运营云托管应用程序的一种流行范式。
• 服务级别协议（SLA）对客户而言比对供应商更重要。SLA并不是法律，甚至许多法律在某些情况下也得不到遵守。此外，很少有云客户能够准确定义和测量SLA中列出的性能指标。大多数客户从未测量过相关的性能指标。因此，对于云客户来说，在与云供应商的讨论中，无需过于严肃地对待SLA，而应将其作为参考和指导。
• 公有云有助于初创企业，而私有云则有利于行业资深企业。对于一家初创公司而言，使用AWS EC2+S3+RDS可以在基础设施上节省大量时间和成本维护。然而，在优化系统效率方面会失去相当多的机会，因为在这种情况下，基础设施是一个“黑箱”。这就是为什么Dropbox在早期几年完全依赖亚马逊S3来存储文件内容，但此后已将其绝大部分文件内容数据迁移到其私有对象存储云Magic Pocket。

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

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

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

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

4 前沿探索

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

谷歌Kubernetes

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

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

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

Apache Mesos

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

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

此外，为了改进资源管理，Mesos团队提出了一种名为DRF（即主导资源公平）的新型资源分配策略。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要素。值得注意的是，2011年，Ruby的发明者加入Heroku担任首席架构师，这反映了编程社区对Heroku的积极态度。

Cloud Studio（目前处于内测阶段）

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

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

5 结论

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

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

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