PaaS未来世界

摘要：未来世界此屏幕截图是一个非常好的例子，它包含了通过或者命令行开始所需要的所有内容。未来世界架构元素核心系统架构系统的核心和的附加功能都围绕着控制器。而健康管理器的作用是识别任何可能产生的问题，并通过告知控制器或者其他机制来解决这些问题。

PaaS的未来会是什么样的呢?NoOps和DevOps又如何融入其中呢?PaaS将会让开发者生活的更加轻松。

实际上，PaaS是一些事物的混合体，它关注更快的部署用时、更低的准入门槛、更高的扩展性、高可用性和地理上分散的系统等。那么，如何为PaaS做好准备呢?首先，需要理解一些关键概念，而我们首先就会介绍这些概念。

本文将会深入介绍NoOps和DevOps以及它们和Paas之间的关系。然后会简短的描述导致PaaS技术产生的原因，同时会介绍第一个开源的解 决方案Cloud Foundry。我们会深入介绍它产生的原因、架构以及一个应用的简单部署。本文还将会介绍PaaS的核心概念。

NoOps和DevOps

首先，我们快速给它们下一个定义：

NoOps - 除了部署基于PaaS的应用(通常是一个SaaS应用)之外，不需要任何运维。这是具有独立开发和产品团队的小型、初创以及中大型企业的主要需求，它们需要能快速地部署原型或应用而不必为基础设施及其他系统相关的问题而操心。

DevOps - 开发者和运维人员的结合，形成满足双方需要的职业形象。DevOps通常维护网络、基础设施、平台及实际的代码库和应用部署。DevOps很少见、高度集中而且内涵丰富。

在NoOps成为开发者的选择之前，DevOps试图通过为开发者提供运维接口来解决问题。NoOps的前提是开发者在无需操心运维的情况下即可完 成工作。这并不意味着运维的消失。幕后的运维人员会微调一切，保持它的运行。这是他们所擅长的，他们也不会消失。我们仅需确保开发者为了完成工作需要“无 需运维”。

开发者不必关心网络，因为没有必要;他们不必处理路由问题、保持实例在线、崩溃或者如何存储，因为他们不需要。他们的责任和工作就是要关注应用及其业务价值。

源自何处?传统开发

传统开发通常包含很多乏味的任务，包括机器配置、资源分配、机器的规格、说明以及相关的沟通，有的还需要预估未来的负载，并预留相应的资金来采购机 器。然后是安装、配置、将机器资源放置在数据中心、主机托管中心或者在某些情况下放在公司大楼里。即使在较好的情况下，这些方法都是有挑战的，而在最坏的 情况下，则需要经过尝试和错误的考验。PaaS和未来的NoOps，甚至某种程度的DevOps都消除了这种传统软件开发的噩梦。

所有这些传统的环境问题多年来耗费了软件产业数十亿美元。但是，变革正在发生，并且已经改变了软件开发的模式。这种进步就像从汇编到C/C++再到 更高层次的Java、C#或Ruby等抽象语言的进步一样巨大。移植到PaaS，相应地消除了操作系统的障碍，极大地改善了软件开发方式。

　　PaaS和核心原则

PaaS的核心原则就是简化应用的生命周期管理，即应用的启动、停止和部署。

让我们对传统的部署过程和PaaS做一个比较。首先，深入了解一下传统的开发过程。

获取应用运行需要的机器或实例

　　加载操作系统

设置网络并做好将它放到目标环境的准备

设置托管的Web服务器或准备部署的服务文件及文件夹

从系统本身独立自主地构建/设置应用，推荐在开发机上进行

验证部署配置能够迁移到不同的环境

将代码块和应用依赖性加入源代码控制系统

在某些方式下，从源代码控制系统中获取应用，部署到之前创建的服务器，方法有move、x-copy、使用msi安装、bash脚本或者配置。

好了，一共需要八步。其中有些步骤很耗时，也很痛苦。接下来我们看看将同样的应用部署到Paas解决方案(在这里我们使用AppFog)中必须要做哪些事情?

把想要使用的域名告诉PaaS

将代码块和应用依赖性加入源代码控制Github一直都是一个好地方。

点击Create按钮或者使用简单的命令行工具，如af push，让代码上线(如图所示)

然后代码库会自动被推到PaaS提供商，自动地构建并部署到系统中。

这就是整个过程。只有三步，很简单。

此屏幕截图是一个非常好的例子，它包含了通过UI或者命令行开始所需要的所有内容。这是一个AppFog PaaS的预展，其核心利用了Cloud Foundry。

　　架构元素——客户端和插件

客户端和插件提供了UI和命令行能力，能够通过简单地将应用部署到PaaS。客户端命令行只有几步。例如：

sudo gem install vmc

vmc target api.cloudfoundry.com

现在，以创建了一个node.js应用为例，添加一个包含以下内容的app.js文件：

var vmc_port = (process.env.VMC_APP_PORT || 3000);

var vmc_host = (process.env.VCAP_APP_HOST || "localhost");

var vmc_http = require("http");

http.createServer(function (req, res) {

res.writeHead(200, {"Content-Type": "text/plain"});

res.end("Foo, I"m Alive!! ");

}).listen(port, host);

然后在该文件所在的目录下使用如下命令：

vmc push

你会看到一些反馈以及一些单击回车就能继续下一步的问题。初始部署时使ga用默认值就可以。我只有一处没有使用默认值，仅仅为了显示一些简单的应用到服务的绑定，这一处输入1，即选择mongodb服务。

Would you like to deploy from the current directory? [Yn]: Y

Application Name: some_app_name

Application Deployed URL: "you_test_subdomain.cloudfoundry.com"?

Detected a Node.js Application, is this correct? [Yn]: Y

Memory Reservation [Default:64M] (64M, 128M, 256M, 512M, 1G or 2G)

Creating Application: OK

Would you like to bind any services to "gvp_node_test"? [yN]: y

The following system services are available::

mongodb

mySQL

Redis

Please select one you wish to provision: 1

Specify the name of the service [mongodb-55666]:

Creating Service: OK

Binding Service: OK

Uploading Application:

Checking for available resources: OK

Packing application: OK

Uploading (0K): OK

Push Status: OK

Staging Application: OK

Starting Application: OK

即使实际上不需要安装数据库，我这样做的目的是为了说明安装一个服务是多么容易的一件事。此时，我们已经有了一个运行中的应用，可以使用curl证明它已经运行：

curl your_app_name.cloudfoundry.com

上面的命令会获得响应：“Foo,I’m alive!!”。就这样，应用部署完成了。一共只有安装、选择目标、推送这三步。

现在，让我们看看可以对应用程序做哪些事情以及Cloud Foundry 环境。

更新应用无需重启

有一些事情需要定期去做，如更新、重启和推送应用。具体工作包括：

推送应用：

vmc push blaghApp-v1 --url blaghApp-v1.cloudfoundry.com

检出实例：

vmc instances blaghApp-v1 1

取消映射应用实例：

vmc unmap blaghApp-v1 blaghApp-v1.cloudfoundry.com

通过下面的命令组合进行回滚：

vmc map blaghApp-v1 blaghApp-v1.cloudfoundry.com

vmc unmap blaghApp-v1 blaghApp-v1.cloudfoundry.com

停止同一已映射的应用程序：

vmc stop blaghApp-v1

还有很多其他的命令和选项。更多内容请访问： http://cloudfoundry.org.

与框架和服务相关的更多材料

对于PaaS来说，其关键特性之一就是要支持一个或者多个框架。下面是Cloud Foundry和Iron Foundry联合之后为用户提供的主要选择。

Node.js

GettingStartedwithVMwareCloudFoundry, MongoDB, andNode.js

Node.jsandCloudFoundry

CloudFoundryintrotoNode.js

Sinatra + Rails

SettingupRakeforSinatraw/ CloudFoundry

AddingRSpecw/ CloudFoundry & CloudFoundry

Sinatra, CloudFoundry, andTheDirtyDetails

PHP

SamplePHPSiteSetupw/ GithubRepo & CloudFoundry

Drupalw/ CloudFoundry

Java

GettingStartedw/ Sprint & RabbitMQ

Java + Spring + More

ASP.NET

IronFoundry + CloudFoundry

使用像AppFog这样的服务，我们能够进一步抽象PaaS，提供许多新的接口和命令。即使AppFog会提供Cloud Foundry的所有功能，AppFog PaaS也将会进一步的扩展Cloud Foundry以提供额外的功能。

工作原理

到目前为止，我们已经介绍了基础内容，概括了PaaS为那些准备使用它的公司真正提供的功能。下面我们深入介绍是什么造就了如此巨大的飞跃。

PaaS内部

作为服务提供者的平台内部含有很多底层的内容，这通常会让它变得非常复杂。它需要有自恢复能力，能够启动和停止服务器实例及相关的功能。所有的这些事情都需自动化，尽可能少的人工参与。.

下面是AppFog、Stackato等提供平台服务的公司所使用的Cloud Foundry和Iron Foundry软件的一个简单的图表。

架构元素——Cloud Foundry核心系统架构

Cloud Foundry系统的核心和Iron Foundry的附加功能都围绕着控制器。通常我们将其称之为“控制器的概念”，使之与其他十几个使用相似术语的模式区分开。控制器是自恢复的，能够在一个平台架构中多次使用。

围绕控制器有很多控制辅助技术，例如Resque和Stager。NATS提供的pub/sub功能可以充当这些组件之间的粘合剂，并赋予它在这样的系统中所需要的弹性。

　　架构元素——Droplet执行引擎

Droplet执行引擎(DEA)是一个程序，它能够简化部署并启动Apache或其他服务器上的代码。它们的工作是执行最终用户的代码。

DEA是跨平台运行整体架构的一部分。它可能包含Node.js、Java，Iron Foundry是为.NET扩展的DEA。DEA可以有很多，配置也不同，这样就能根据它们原定的用途完美地为特定的实例分配大小。

　　架构元素——路由和健康管理器

路由好比系统中的事件守护进程，其责任是监听将要激活的新应用。而健康管理器的作用是识别任何可能产生的问题，并通过告知控制器或者其他机制来解决这些问题。

架构元素——服务

在Cloud Foundry中服务是较好的扩展点之一。在这个领域内有很多扩展，例如MySQL、Redis、SQL Server等。

　　架构元素——将来

尽管Cloud Foundry是经过深思熟虑的，但是它依然有许多最终特性需要实现。例如，许多企业的用例依然需要诸如审计、认证和编排之类的功能。毫无疑问，有其团队在背后的支持，Cloud Foundry在不久的将来将会新增很多特性和功能。

如果想要更深入的了解架构，可以查看Derek Collison的描述"Cloud Foundry-技术内幕"。

　　DevOps，进入NoOps

从架构设计中我们能够发现，仍然有大量的需求，要求PaaS供应商提供强大的DevOps方面的支持。但是，随着这种形势的巩固，它会驱动 DevOps转向PaaS提供商所提供的更加精密和集中的价值。但是在小企业、中型或者任何PaaS用户的外部和内部，它能够提供一个条件使DevOps 角色转变成提供商，使业务的核心竞争力聚焦于应用和需求。随着这种转变，最终会进入NoOps的时代，更加专注于业务、干净的应用开发、更短的周期以及始 终难以捉摸的敏捷性提升。