1 书籍简介
中文书名 | 让云落地：云计算服务模式（SaaS、PaaS和IaaS）设计决策 |
英文书名 | Architecting the Cloud: Design Decisions for Cloud Computing Service Models(SaaS, PaaS, and IaaS) |
作者简介 | Michael J. Kavis是云计算的早期倡导者之一，曾经带领团队在亚马逊的公有云上搭建出世界上首个高速交易网络。也是2010年AWS全球初创企业挑战赛的获胜企业M-Dot网络的前任CTO。 |
内容简介 | 在云计算时代，架构师及架构可能会遇到的挑战，以及如何应对这些挑战，并提供适当的解决方案来解决业务问题。告诉大家怎样像架构师一样思考。 |
面向读者 | 实施云计算的首席技术官、企业架构师、产品经理和技术决策者。 |
特点 | 作者有意避开了与产品或供应商相关的细节，通过虚构一个在线拍卖公司AEA，向读者提供了大量可供参考的设计决策，并对所有云架构中都必须应对的重点领域进行了强调说明。 |
2 全书结构
章节 | 内容 |
第1章 为什么是云计算，为什么是现在 | 云计算出现的历史，以及为什么云计算是大势所趋；分别以Instagram和Netflix为例，介绍了初创企业和成熟公司使用云计算的案例。 |
第2章 云服务模式 | 介绍三种云服务模式（SaaS、PaaS和IaaS）的技术堆栈、组件，以及客户和云服务提供商在不同架构下的职责划分；并对云服务的部署模式（公有云、私有云、混合云、社区云）进行了介绍。 |
第3章 云计算的错误实践 | 结合具体案例说明企业在将业务迁移至云端的风险，以及一些错误实践，如期望过高，对云安全重视不足，云技术不足，忽略服务中断的影响等。 |
第4章 先从架构开始 | 使用5W1H方法描述了进行云架构设计时需要考虑的因素，如云架构解决的业务问题（Why），云计算服务的用户（Who），具体的业务和技术需求（What），消费者体验可视化（Where），项目约束（When），以及组织如何应对云化的转变（How）。 |
第5章 选择合适的云服务模式 | 对企业何时选择SaaS、PaaS或IaaS进行了详细描述。 |
第6章 云的关键：RESTful服务 | 介绍RESTful的概念及为什么REST是云服务的核心组成部分。 |
第7-13章 | 具体介绍云中审计、数据存储方式、安全设计、日志策略、SLA管理、云服务监控，以及在出现云服务中断时的灾难恢复计划。 |
第14章 使用DevOps文化来更快、更可靠地交付软件 | 介绍了DevOps的概念，纠正了大家对DevOps的误解，以及企业为使用DevOps应该考虑的因素。 |
第15章 评估云模式对组织的影响 | 提醒企业认识到将业务迁移到云端不仅仅是技术的转变，组织和部门策略的转变也需要引起足够的重视，并为此采取一些应对策略。 |
第16章 最后的思考 | 有关云文化、云商业模式的思考。 |
3 云计算的特征
- 广泛的网络接入
- 弹性伸缩
- 资源池化
- 可计量的服务
- 按需自服务
4 云计算服务模式
对基于云的解决方案而言，事先确定合适的服务模式至关重要。只有完全理解每种服务模式下云服务提供商（CSP，Cloud Service Provider）和云服务消费者（CSC，Cloud Service Consumer）各自应该承担什么样的责任，才能在服务模式中做出正确的选择。按照资源抽象程度的同，云服务模块包括以下三种：
- 基础设施即服务（IaaS: Infrastructure as a Service）
- 平台设施即服务（PaaS: Platform as a Service）
- 软件设施即服务（SaaS: Software as a Service）
服务模式 | 云堆栈 | 堆栈组件 | 责任人 | ||||
用户 | 登录、注册、管理 | 客户 | 客户 | 客户 | |||
SaaS | 应用 | 认证、授权、用户界面、事务处理、报告、控制面板 | 客户 | 客户 |
| ||
SaaS | PaaS | 应用堆栈 | 操作系统、编程语言、应用服务器、中间件、数据库、监听 | 客户 |
|
| |
SaaS | PaaS | IaaS | 基础设施 | 数据中心、磁盘存储、服务器、防火墙、网络、负载均衡 |
|
|
|
4.1 基础设施即服务（IaaS）
定义
消费者能够获得处理能力、存储、网络和其他基础计算资源，从而可以在其上部署和运行包括操作系统和应用在内的任意软件。消费者不对云基础设施进行管理或控制，但可以控制操作系统、存储、所部署的应用，或者对网络组件（如防火墙）的选择有部分控制权。
特点
在IaaS中，涉及管理和维护物理数据中心和物理基础设施（服务器、磁盘存储、网络等）的许多工作，都被抽象成一系列可用服务，可以通过基于代码或/和网页的管理控制台进行访问和自动化部署。过去那种必须先从供应商处订购硬件，然后等待发货，签收、拆封、组装并再进行配置，看着这些大家伙占满数据中心的日子一去不复返了。
成熟IaaS供应商
- 亚马逊AWS
- Rackspace
- GoGrid
- OpenStack（开源项目）
4.2 平台即服务（PaaS）
定义
消费者能够使用提供商所支持的编程语言、库、服务和工具，将自己创建的应用部署到云基础设施上。消费者不会对底层云基础设施进行管理或控制，这包括网络、服务器、操作系统或存储等，但是可以控制所部署的应用，并有可能控制配置应用的托管环境。
特点
PaaS服务完全通过互联网提供，服务提供商管理应用平台，向开发者提供一套工具来加快开发流程，而开发者在使用PaaS服务时，由于受到这些工具和软件包的约束，在某种程度上要放弃一些灵活性。
成熟PaaS供应商
- Force.com
- Google Apps Engine
- 微软Azure
4.3 软件即服务（SaaS）
定义
消费者能够使用提供商运行在云基础设施上的应用，并可通过类似Web浏览器等瘦客户端界面，在各种客户端设备上访问这些应用。除了一些有限的特定于用户的应用配置之外，消费者不需要直接对底层云基础设施进行管理或控制，包括网络、服务器、操作系统、存储、甚至单个应用的功能。
特点
SaaS以一种服务形式向消费者交付完整的应用，消费者要做的只是对一些具体的应用进行参数配置和对用户进行管理。服务提供商则负责处理所有的基础设施问题。
案例
客户关系管理（CRM）、企业资源计划（ERP）、工资单、会计等业务软件。
5 云计算部署模式
按照云基础设施的存放位置及分配方式的不同，云计算部署模式包括：
- 公有云
- 私有云
- 混合云
- 社区云
5.1 公有云
定义
云基础设施提供给大众公开使用。拥有管理或运营这些设施的可能是商业、学术或政府机构，抑或其组合。另外，这些基础设施都存放在云服务提供商处。
优势
- 公用事业价格：最终用户只为所消费的资源付费。最终用户无需采购硬件，避免计算资源再使用周期中可能存在的浪费。
- 弹性：资源池使最终用户可以对其软件解决方案进行设置，来动态提升或降低其在处理峰值负荷时所需的计算资源数量，从而可以对罕见的流量高峰做出实时反应。
- 核心竞争力：最终用户大大减少了在管理基础设施上的时间，可以更专注于自身的核心竞争力。
缺点
- 控制：最终用户必须依靠提供商履行他们在性能和正常运行时间方面的服务等级协议（SLA），如果出现服务中断，而最终用户又没有冗余备份机制，就只能耐心等待服务恢复。
- 监管：类似PCI DSS和HIPAA的监管条例及数据隐私问题都会成为公有云部署的障碍。
- 有限的配置：提供商有一套标准的基础设施配置方案，可能在某些情况下并不符合消费者的需要。
5.2 私有云
定义
云基础设施提供给多个消费者构成的组织专用，拥有、管理或运营这些设施的可能是该组织、第三方，抑或其组合。这些基础设施的存放点可以在本地，也可以不在本地。
优点
解决了公有云的上述缺点，最终用户在单一租户环境下进行部署，不会与其它用户混用。消费者在各方面都有着完全的自主性。
缺点
牺牲了快速伸缩性、资源池化、以及按需付费的云计算核心优势。可访问资源总量取决于内部所购买的基础设施的多少。且必须有人对这些基础设施进行管理。
5.3 混合云
单独存在但却通过标准的或专利性的技术绑定在一起，以使数据和应用具有可移植性的两种或多种不同的云基础设施（私有云、公有云或社区与）的组合。
5.4 社区云
公有云的组成部分，具有区域性和行业性集中的特点，专门针对特定的垂直行业，比如政府、医疗保健或金融等行业，提供一系列服务，包括基础架构即服务(PaaS)、软件即服务(SaaS)或平台即服务(PaaS)。
6 云计算的错误实践
6.1 盲目迁移
云计算架构要求系统是松耦合的，即系统能够弹性伸缩，软件能够按需扩展或缩减，而且不必受运行的物理环境的限制。另外，云计算要求系统还必须是无状态的，一个无状态的服务是指服务不知道前一个请求或响应的任何信息，只处理给定请求的这一持续期间的信息。如果遗留系统是紧耦合并且是有状态的，那么她很有可能不适合立即迁移到云端。
6.2 不切实际的成本期望
有关云计算的最大误解之一是采用云会极大降低经营成本。虽然云计算可以实现按需付费，而不需要按照峰值业务量购买硬件，但从另一个角度来看，传统企业虽然第一次购买基础设施的预算较高，但一旦部署完成，这些就成了沉没成本（sunk cost）。而云计算架构一旦设计的不合理，或者所消费的服务未能在不需要时适当关停，那么使用云就可能会变成一个代价高昂的坏主意。另一方面，如果软件架构不足以支撑业务的扩展需求，一旦出现运行中断或性能问题，就可能导致最终用户的流失和收入下降。
6.3 云安全的错误认知
关于云安全有两种对立的错误认知，一种是坚决认为云是不安全的，拒绝将任何数据存储在公有云中；另一种则认为云非常安全，缺少对各种安全漏洞的防范。
6.4 根据喜好选择服务商
如.NET项目倾向于购买微软的Azure服务（PaaS），但实际业务需求更适合采用IaaS服务模式。
6.5 低估组织变更的重要性
通常人们在获知需要改变时，第一反应都是拒绝。
6.6 技术不足
架构师、系统管理员、安全专家缺少足够的云计算技能和知识。
7 云中的数据存储
许多IT部门对关系型数据库非常熟悉，因此下意识地选择关系型数据库来存储数据，但关系型数据库必须保证事务得到成功处理，因此仅适合处理联机事务处理行为。关系型数据库的构建强调参照完整性，同时还要求使用索引来加快对记录的检索，但当记录数足够大时，这会成为系统性能的瓶颈。NoSQL数据库就是为了解决这些问题而出现的，常见的NoSQL数据库主要有：
NoSQL数据库 | 特点 | 代表产品 |
键值存储 | 采用哈希表实现，每个带有指针的唯一的键都会指向一个特定的数据项 | Redis、Voldemort、DynamoDB |
列存储 | 为了存储和处理跨多台机器之上的大规模分布式数据库，可以在运行中添加列，并且允许行值出现空缺 | Hadoop、Cassandra |
文档存储 | 以文档形式存放非结构化数据 | CouchDB、MangoDB |
图像数据库 | 存储和管理彼此关联的关系，通常用于展现关系的可视化表述图社交媒体分析领域 | Neo4j、InfoGrid |
8 云的安全策略
企业在管理云应用安全时需要考虑的因素：
- 集中化：将一组安全控制流程、策略和服务进行合并，减少需要管理和实施安全功能的地方。
- 标准化：在实施安全解决方案和选择诸如加密、授权、API的方法时，尽量遵守业界最佳实践。
- 自动化：通过对虚拟机和代码的部署实现脚本化，以在需求增加或减少时自动进行资源的缩放。
9 云的监控
云计算需要监控的指标：
- 性能
- 吞吐率
- 质量
- 关键性能指标（KPI）
- 安全
- 合规
10 云的容灾备份策略
- 经典策略：备份数据被存储于由云服务提供商提供的磁盘服务中，一旦运行数据库损坏，可以将最近一次完好的备份启用。
- 单活冷备：从属数据中心做好了在主数据中心出于灾难状态时对其进行接手的准备。冷意味着冗余服务器并没有启动和运行，而是在灾难发生时，运行自动化脚本创建数据库服务器并恢复最近一次的备份。
- 单活温备：数据库服务器出于运行态，而其他服务（如Web、API等）则处于关闭状态；
- 双活热备：从属数据库服务器及Web、API服务均启动并运行，一旦灾难发生，几乎可以以零故障的状态接管主数据中心的业务。
11 DevOps文化
11.1 定义
DevOps并非是一个团队或职能，而是一种文化转变，或者说是一种思考我们如何开发个发布软件的新的方式。DevOps主张打破竖井，鼓励开发、运营、质量控制、产品和管理之间的沟通与协作。
11.2 起源
2009年，第一节DevOps Days会议在比利时召开，几个受到Jhon Allspaw和Paul Hammond的一篇名为《10 Deploys per Day: Dev and Ops Cooperation at Flickr》的文章启发的从业人员，聚集在一起讨论如何在开发者和运营人员之间创造出一种更具协作性的文化。这个话题得到了越来越多的支持，最终DevOps成为了这个新文化的名字。
11.3 DevOps思维
- 理解工作流程
- 始终寻求提高流程的方法
- 不向下游传递缺陷
- 取得对系统的时刻理解
11.4 DevOps关键实践
- 自动化基础设施
通过各种API对基础设施进行抽象，从而使得我们能够像对待代码一样对待基础设施。 - 自动化部署
采用合理的部署过程，使之足够简单，任何人只要有适当的权限都通过简单地点选版本、环境和单击确定按钮来部署软件。 - 设计功能标记（feature flag）
给新特性后功能增加开关控制，在如果Beta测试后才进行规模商用。 - 测量
- 监控
- 快速试验和失败
- 持续集成和持续交付
