当前位置:主页 > 计算机电子书 > 程序设计 > PaaS下载
PaaS程序设计

PaaS程序设计 PDF 超清扫描版

  • 更新:2019-05-31
  • 大小:113 MB
  • 类别:PaaS
  • 作者:卡尔森
  • 出版:机械工业出版社
  • 格式:PDF

  • 资源介绍
  • 相关推荐

PaaS程序设计

PaaS程序设计

读者评价

当PaaS实施手册的快速check list,五星。当PaaS学习手册
感觉粗略看就可以了 没有看具体实施的部分 其实想看到对PaaS的理解 但很可惜大部分只是实战部分
有点过时了,连最近那么容器,docker都没有涵盖,细节还是太少,相对还是粗浅了点,了解下概念还行
资产托管:对象存储 over 文件存储 - 会话管理:加密会话cookie,NoSQL会话存储,SQL会话存储 - 缓存:分布式缓存,Redis,MangoDB over 磁盘访问 (建立中心缓存存储) - 异步处理 - SQL与NoSQL

内容介绍

PaaS(平台即服务)正在对Web和移动开发者产生巨大的吸引力。但是,随着新PaaS供应商的出现,以及现有供应商对其产品特性的持续升级,要知晓PaaS可以提供什么就成为一件比较困难的事情。本书从开发者的视角对PaaS进行了透彻介绍,带领读者领略不同的PaaS模型,并且对Google App Engine、Windows Azure、Heroku、Cloud Foundry等供应商的不同类别的服务进行分解和分析。

《O'Reilly精品图书系列 PaaS程序设计》全面展示PaaS如何帮助你专注于创造性的应用开发,而不是将时间花费在担心那些技术的运维问题上,不管你是创业家还是大型企业研发团队的成员,都会从中受益。

■ 介绍云从IaaS和DevOps到PaaS的发展轨迹。
■ 学习如何通过PaaS将共享Web托管的简便性和专有主机托管的可控性结合在一起。
■ 探讨可移植和不可移植PaaS方案的利弊。
■ 将最佳实践应用于迁移遗留代码到PaaS,并且理解这个过程中可能遇到的挑战。
■ 从头开始为PaaS编写REST风格的元服务。
■ 采用PaaS构建移动应用,并且通过后端服务进行扩展。
■ 审视主流PaaS供应商当前可以提供的核心服务。
■ 了解PaaS不能发挥作用的场合。

目录

  • 前言 1
  • 第1章 开发者的云 7
  • 1.1 开发者的困境 8
  • 1.2 云能为创新做什么 8
  • 1.3 云:发展历程简介 9
  • 1.4 云的核心技术 14
  • 1.5 管理平台与产品化平台 15
  • 1.6 云计算的承诺(或者炒作) 16
  • 1.7 云技术的未来5年 16
  • 1.8 兑现承诺 17
  • 第2章 什么是PaaS 18
  • 2.1 魔术网站 18
  • 2.2 开发者早期的选择 19
  • 2.3 PaaS:综合两种方式的最佳方案 24
  • 2.4 PaaS:现代应用的虚拟工具 28
  • 2.5 重建信心 29
  • 第3章 PaaS类型 30
  • 3.1 不可移植的PaaS:遵照一个模板 30
  • 3.2 可移植性:不再繁琐 33
  • 3.3 走向公开标准 39
  • 第4章 遗留应用迁移到PaaS 41
  • 4.1 初步考虑 41
  • 4.2 概述 43
  • 4.3 资产托管 44
  • 4.4 会话管理 49
  • 4.5 缓存 52
  • 4.6 异步处理 56
  • 4.7 SQL 57
  • 4.8 NoSQL 58
  • 4.9 各种陷阱 59
  • 第5章 在PaaS上开发新应用程序 61
  • 5.1 分解庞然大物 61
  • 5.2 将API应用于移动开发 63
  • 5.3 JSON和REST的出现 64
  • 5.4 使用基于REST的元服务 69
  • 5.5 PaaS的独特贡献 72
  • 5.6 摩尔定律的影响力 74
  • 第6章 PaaS上的移动应用 76
  • 6.1 移动应用开发简史 76
  • 6.2 未来应用 77
  • 6.3 数据结构 78
  • 6.4 调用移动客户端的元服务 79
  • 6.5 PaaS如何让移动后端开发更容易 83
  • 6.6 服务于更多用户 85
  • 第7章 核心服务简介 86
  • 7.1 非PaaS核心服务 86
  • 7.2 评估PaaS服务 87
  • 7.3 采用托管的数据库和PaaS以节省时间 88
  • 7.4 缓存和PaaS: 冗余 92
  • 7.5 解决Email的挑战 93
  • 7.6 监控的重要性 94
  • 7.7 负载测试 96
  • 7.8 计划升级途径 96
  • 第8章 为什么不选择PaaS 100
  • 8.1 公共云与私有云 100
  • 8.2 中小型公司:如何选择 101
  • 8.3 大型企业级用户:如何选择 103
  • 8.4 PaaS的限制 103
  • 8.5 直面阻力 107
  • 8.6 以长远的视角看待限制 108
  • 第9章 PaaS的未来 109
  • 9.1 OpenStack的影响 109
  • 9.2 保持开发选项的开放 110
  • 9.3 故障:开发者必须面对的最大问题 111
  • 9.4 通过开源重新获取控制 112
  • 9.5 最终的思考 115
  • 第10章 资源 116
  • 10.1 PaaS供应商 116
  • 10.2 IaaS供应商 119
  • 10.3 托管服务 120
  • 10.4 将遗留应用迁移到PaaS 123
  • 10.5 新兴PaaS应用开发 124

资源下载

资源下载地址1:https://pan.baidu.com/s/1VTFQRIprcpyWyDjAMZCrEg

相关资源

网友留言

网友NO.26865
姜弘壮

根据 Gartner 的定义, PAAS 分为 aPAAS 和 iPAAS 两类。对于 aPAAS,开源世界现在已经有比较成熟的解决方案了。基于 kubernetes 和 deis 完全可以定制出一个满足以下需求的 aPAAS 。 接下来是 iPAAS 的部分了。做为 IOT 领域,首先要解决的就是应用与设备的通讯问题。这个部分在前面 SAAS 部分已经说过了,接下来要思考的是还有哪些服务是 PAAS 应该包含的。 以上五种服务是一个通用应用程序会需要用到的服务,而跟 IOT 关系的体现则是在具体设计这些服务时要重点考虑的问题。 产品或者项目可以按照敏捷的思路推进,程序也可以按照 TDD 实践来开发,然而做为架构师,则需要在一开始就划清系统的范围,知道边界在哪里,系统间的关系是怎么样的。范围清晰了,才能识别全系统的问题集,才能谈概念完整性问题。

网友NO.23843
吕和昶

架构是面向问题,而满足需求的。所以第一步的工作是识别问题。我们要做一个 IOT 领域的 SAAS 服务,那么主要的问题有以下三点: 识别问题之后,就是寻找方案来解决问题,目前业界并没有一个针对 IOT 领域的 SAAS 服务的参考架构,但针对大并发,大数据的问题,我们一般采用分布式集群来解决。 但这样的架构有一个问题,有些租户的设备很多,但数据上报的频率低,而有些租户设备不是很多,数据上报的频率很高。对一个应用来说,计算量是跟数据量相关的,而连接数不能完全体现数据量,所以不能根据设备连接数来决定应用实例数量。 这个架构的问题是所有的应用实例和所有的网关都要保持连接,网关在收到数据时,需要选择转给哪一个应用实例,这样的多对多关系,限制了系统的伸缩性。