第2章 PaaS模型与特征

                                                   第2章 PaaS模型与特征

2.1 主流PaaS平台架构

2.1.1 谷歌GAE

    GAE(Google App Engine) 可让你利用谷歌的基础设施构建和运行应用程序。基于GAE构建的应用程序能够

非常容易地应对访问量、存储空间的变化。GAE支持的编程语言包括Java、Python、PHP、Go。它包括以下特征:

    。具有查询、排序与事物控制的持久化存储

    。自动扩展和负载平衡

    。用了执行额外任务的异步消息队列。

    。按照指定时间与规划执行任务的事件触发器。

    。可与其它谷歌云服务和API集成。

    开发人员利用GAE简化了Web应用程序的开发和部署。使用自动伸缩计算的资源,同时可集成分布式缓存、任务队列、

数据存储等服务。GAE有自己的云平台SDK库,使应用程序能快速地部署和运行到云上。

2.1.2 AEB

    AEB(AS Elastic Beanstalk)提供了一套在亚马逊云上部署与管理应用的简单方法。用户可以简单地上传应用程序包,

AEB会对应用程序包自动进行容量评估、负载均衡、自动伸缩及健康检查。

    AEB的组件包括如下几种:

    1)Application

    Application是组件的逻辑集合,它包括了后面提到的Environment、Version和Environment Configuration,可以将一个

Application看作一个目录。

    2)Version

    在AEB中,Version代表一个Web应用的特定代码版本,它指向了亚马逊简单的存储服务上的一个对象,一般包含了可部署代码,

比如Java的war包。应用可以包含多个Version,这些可部署代码由用户上传并打上了版本标签。

    3)Environment

    Environment是部署在AWS平台上的一个可运行的Version,每一个Environment在一个时间点上只能运行一个Version,但是你

可以同时启动多个包含不同Version的Enviroment,以测试它们之间的差异。在创建Environment的时候,AEB就自动将资源分配给了

特定的Version。

    HM(Host Manager)是一个运行态的容器,在这个容器中包含了由用户定义的一组软件栈。

    Security Group为运行的EC2实例定义了防火墙策略,在默认情况下,AEB只运行用户访问示例的80(HTTP)端口,你可以依据业务

类型定义更多的策略。

2.1.3 Cloud Foundry

    Cloud Foundry是由VMware贡献的一个开源PaaS项目,它是一个基于Ruby on Rails的由多个相对独立的子系统通过消息机制组成的

分布式系统,支持多种框架、语言、运行时环境、云平台及应用服务,使开发人员能够在几秒内进行应用程序的部署和扩展。

2.1.4 Heroku

    Heroku是一个支持多种编程语言的公有PaaS平台,其成立于2007年,3年后被Salesforce.com收购。Heroku作为最初的云平台之一,

支持Ruby、Java、Node.js、Scala、Clojure、Python等多种编程语言。基础操作系统是Debian,最新的堆栈则是基于Debian的Ubuntu。

    Heroku的容器单元被称为dyno,dyno越多,应用系统就拥有越多的实例来保证其服务的有效性。

    Heroku的路由模块被称为Hermes,采用Erlang语言编写,其能够动态感知一个应用中包含多少个dyno,基于一定的策略进行任务分发,

另外我们还可以设置超时保护机制,在Hermes上就拒绝掉外部请求。

2.2 PaaS与12-Factor

    Heroku开发团队在收集与观察了大量运行在PaaS上的应用程序的开发、执行过程之后,整理出12条开发SaaS应用程序的规则,也是最

适合PaaS的应用程序方法论,统称为12-Factor,其目标是:

    。使用标准化流程自动配置,从而使新的开发者话费最少的学习成本加入这个项目;

    。和操作系统之间尽可能地华清界限,在各个系统中提供最大的可移植性;

    。适合部署在现代的云计算平台上,从而在服务器和系统管理方面节省资源;

    。将开发环境和生成环境的差异降至最低,并使用持续交付方式实施敏捷开发;

    。可以在工具、架构和开发流程不发生明显变化的前提下实现扩展。


2.2.1 基准代码(Codebase)

    应用代码使用版本控制器进行管理,这些版本控制器包括Git、Mercurial、Subversion等。在控制器中用来跟踪代码所有修订版本的

数据库称作代码库。在类似SVN这样的集中式版本控制系统中,基准代码就是指控制系统中的代码库;而在像Git那样的分布式版本控制系统

中,基准代码则是指最上游的代码库。

    基准代码和应用之间要求保持一一对应的关系:

    。一旦有多个基准代码,就不能称为一个应用,而是一个分布式。分布式系统中的每一个组件都是一个应用,每一个应用可以分别使用

12-FActor进行开发;

    。多个应用共享一份基准代码是有饽于12-Factor原则的。解决方案是将共享的代码拆分为独立的类库,然后使用依赖管理策略去加载它们。

2.2.2 依赖(Dependency)

    依赖清单在声明所需库文件的同时,可直接从打包管理系统中下载安装,但有一种情况是对于系统级的库文件,

多个应用程序可能同时引用了不同的版本,依赖隔离工具相当于给应用程序一个独立的环境变量来执行上下文,将

它所需要引用的第三方库路径从默认的系统级别路径指定到应用路径。

2.2.3 配置(Config)

    配置是指将配置信息存储在环境变量中。基础资源、应用代码、应用逻辑在多套部署环境中是可以完全一致的。

而各套环境间的最终差异体现在应用与外部组件的通信上,这些通信内容包括:

   。数据库,如Memcached及其他后端服务的配置;

   。第三方服务的证书,如Amazon S3、Twiter等;

   。每份部署特有的配置,如域名等。

   这些差异会反应在配置中。有些应用代码中使用常量保存配置。

2.2.4 后端服务(Backing Services)

    1.把后端服务当作附加资源

    后端服务是指程序运行所需要的通过网络调用的各种服务,如数据库、消息/队列系统、SMTP邮件发送服务,以及缓存

系统。

    2.12-Factor应用不会区别对待本地或第三方服务

    对应用程序而言,本地都是附加资源,通过一个URL或者其他存储在配置中的服务定位/服务证书来获取数据。本地SMTP

服务应该也可以和第三方SMTP服务相互转换。

    部署可以按需加载或卸载资源。

2.2.5 构建(Build)、发布(Release)、运行(Run)

    基准代码转换为一份部署(在非开发环境下)需要以下三个阶段。

    。构建阶段是指将代码仓库转换为可执行包的过程。在构建时会使用指定版本的代码来获取和打包依赖项,编译成二进制

文件和资源文件。

    。发布阶段会将构建的结果和当前部署所需的配置相结合,并能够立刻在运行环境中投入使用。

    。运行阶段(或者说"运行时")指针对选定的发布版本,在执行环境中启动一系列应用程序的进程。

2.2.6 进程(Process)

2.2.7 端口绑定(Port Binding)

2.2.8 并发(Concurrency)

    任何计算机程序一旦启动,就会生成一个或多个进程。互联网应用采用多种进程运行方式。

2.2.9 快键性(Disposable)

    快速启动和优雅终止可最大化健壮性。

2.2.10 开发/生产环境等价(Dev/Prod/Parity)

    从以外经验看,开发环境和线上环境之间存在着很多差距,这些差距表现在以下三个方面。

    。时间差距

    。人员差距

    。工具差距

    。缩小时间差异

    。缩小人员差距

    。缩小工具差异

2.2.11 日志(Log)

    1.把日志当作事件流

    2.12-Factor应用本身从不考虑存储自己的输出流

2.2.12 管理进程(Admin Process)

    进程组指用来处理应用的常规业务(比如处理Web请求)的一组进程。与此不同,开发人员经常希望执行一些管理

或维护应用的一次性任务。

    。运行数据移植

    。运行一个控制台,执行一些代码或者针对先生数据库做一些检查。

    。运行一些提交到代码仓库的一次性脚本。

2.3 PaaS与Reaction宣言

2.3.1 响应(Responsive)

    系统应尽可能第及时响应。响应是可用性与有效性的基石,除此之外,响应意味着问题被今早发现、及时处理。响应

系统聚焦在保证快速而一致的响应时间,建立可靠的时间上限,从而交付一致的服务质量。这种一致性反过来又简化了错误

处理,建立终端用户信心,并鼓励进一步互动。

2.3.2 韧性(Resilient)

    韧性通过复制、封闭、隔离和委派来实现。故障存在于每一个组件中,组件之间的相互隔离可保证局部故障及其恢复不会

影响到整体。节点的恢复被委派到另一个(外部)组件负责。高可用通过节点间的复制实现。客户端组件不参与到异常处理中。

    组件在不同位置同时运行被称之为复制。它可以是在不同线程或线程池、进程、网络节点或数据中心。

    隔离(或封闭) 能被定义为再时间和空间上的解耦。

    委派的目的在于将一个任务的执行保证交由另一个组件负责。这个组件可以执行其他工作,或随意地观察委托任务的进展情况,

进一步动作需要的话。

2.3.3 弹性(Elastic)

    系统在变化的工作负载下保持响应。Reactive Systems能够感知外部输入请求速率的变化,通过减少与增加资源来做出反应。

    组件用于执行任务所依赖的任何东西都称为资源,它们必须按照组件需要而分配,包括CPU、主存、存储、网络带宽、任务调度、

时钟、输入输出以及类似于数据库、网络文件系统外部服务。

2.3.4 消息驱动(Message Driven)

    Reactive Systems依赖于异步消息传送,以在组件之间建立起边界,从而实现松耦合、隔离、位置透明,以及提供将错误委派给

消息处理的手段。明确的消息传送机制通过创建、监控消息队列,并在必要时应用背压(back pressure)使负载处理、弹性伸缩、流量

控制得以实现。位置透明消息作为一种通信手段,使得故障的管理可以在一个集群或一个主机上以相同语义结构工作。非阻塞(non blocking)

通信允许接收者只在活动时消耗资源,导致系统开销更少。
博主

让学习成为习惯,坚持-共享-开源-自由! 成功者决不放弃,放弃者绝不成功!

相关推荐

嗨、骚年、快来消灭0回复。