第 2 章　迁移到云

T. S. MOHAN

2.1　引言云计算的承诺使得中小型企业对 IT 有着无可估量的期望 , 大公司对其争论不休。云计算

是 IT 的一种突破性模式，其创新在于部分技术和部分商业模式，简言之，就是 IT 的“突破

性技术商业化模式”。这一导引章节主要关注一些决策者、架构师和系统管理人员在应对他

们的 IT 需求、试图理解和利用云计算时所面对的关键问题和相关的困境。在本章中提及和

讨论的问题包括何时以及如何将一个应用迁移到云中；IT 应用的哪一部分或者组件迁移到云

中，哪一部分不迁移到云中 ；哪一类客户把他们的 IT 迁移到云中将会真正受益等一系列问

题。本书描述了上述问题的关键深层因素，并分享了迁移到云的七步实施模式。

云计算现在已经是一个热门话题，业界和学术界的 IT 专业人士都在讨论和辩论。在一

些博客（blog）、Web 站点以及某些研究成果 [1~4] 中对云计算均有激励的讨论。在面对无数的

问题、挑战、利益、限制以及对云计算能做什么缺乏全面了解的情况下，也促进了一些企业

合力创业，帮助他们充分利用并迁移到云中。另一方面，一些大型的云计算 IT 供应商（如

Google、Amazon 和 Microsoft）已开始提供云计算服务。尽管没有明确提及，这似乎像一个

示范和试点。他们收取用户费用，在某些情况下还表现出了非常有吸引力的定价模式。它表

明，云计算本身是真实的，“突破性技术商业化模式”比传统的 IT 企业投资确实具有更大的

投资回报率（Return on Investment，ROI）。另一方面，这些初始的云计算产品是超前的。云

计算服务供应商抓住了分布式系统以及商业模式的实质问题，他们的一些开放型工程和研究

问题 [2] 以多种方式表明云计算服务尚未完全成熟。

最近许多人已经作了一些工作来定义“云计算”一词，但他们并未提供一个全面的解

释 [2,5,6]。技术进步的步伐以及云服务所提供的新型商业模式个案实例更具挑战性。本书对云

计算提出如下定义 ：“它是一种突破性技术商业化模式，使用分布式大型数据中心（它们可

以是公共的、私有的或者混合的）为客户提供可扩展的虚拟化基础设施或一系列符合服务水

平协议（SLA）标准的抽象服务，仅对已使用的抽象 IT 资源收费。”现在大多数企业均由专

用数据中心支配。如今，在大多数大型或者小型企业内，IT 是其业务骨干。这些大型企业的

数据中心分布在各个地区。这些数据中心包括系统和软件，它们是由不同 IT 厂商销售的多

代产品。为了满足不断变化的负载，大部分数据中心都配备了超出峰值负载的设备。如果企

业处于季节性或周期性业务，那么负载会显著变化。因此，通常观察到的 IT 资源配置能力

是平均需求的几倍。这是闲置生产能力的重要指标。许多数据中心管理团队在实践中不断创

新，并部署有可能筛选掉最近通过适当的编程、系统配置、SLA 和系统管理的可用循环计算

32　 　第一部分　基本原理

资源技术。云计算对他们有吸引力，因为云计算可以从他们的 IT 设置到云中传递额外需求，

这只需支付使用的费用，对负载的操作和管理则是畅通无阻的。

2.1.1　云的承诺

对于一些大型数据中心提供云计算服务的大多数用户而言，他们对最底层系统和其运

作的复杂性感到极度困扰。更不用说异构性系统或者在其上运行的软件了。他们对抽象云

计算服务最为深刻的印象是其简单性、统一性和易用性。在中小型企业中，所有额外周期

性 IT 需求的云计算的使用已经取得了重大和显著的经济节约。许多这样的成功故事已记录

在案并在 Internet 上讨论。在云计算服务时考虑经济学和相关取舍，俗称“云计算经济学”

（cloudonomics）。在 IT 管理人员和技术架构师之间，它成为满足企业的季节性 IT 负载让人

深感兴趣的话题。

云计算经济学

技术

“用时付费”– 较低的成本壁垒 ●按需资源 – 自动缩放 ●Capex vs OPEX – 没有资本性支出 (CAPEX) ，只有运营成本（OPEX） ●SLA 驱动的业务 – 较低的总体拥有成本（TCO） ●有吸引力的非转售（NFR）支持：可用性、可靠性 ●

“无限的”弹性可用性 – 计算 / 存储 / 带宽 ●自动使用监控和计量 ●工作 / 任务虚拟化与透明“移动” ●混合操作的集成与互操作性“支持” ●透明封装和抽象的 IT 特性 ●

图 2.1　云计算服务的承诺

如图 2.1 所示，云业务方面（有吸引力的云计算经济学）和技术方面的承诺广泛资助

CxO 形成几个非关键任务（non-mission critical）的 IT 需求，其范围从他们传统的专用数

据中心到适当的云服务。这些 IT 需求总有一些共同特点 ：它们通常是面向 Web 的、代表

了 IT 的季节性需求、采用并行批处理、属于非关键任务，因此对高安全性要求不高。它们

还包括科学应用 [7]。不过，一些中小型商业企业利用云已不局限于谨慎的用户上的情况。许

多创业公司允许它们的 IT 部门完全使用云服务——这是非常成功的，并取得了高投资回报

率。纵观这些成就，一些大型企业已开始成功开展云的试点。许多大型企业运行 SAP 管理它

们的运营。SAP 本身也在试用其产品套件 ：Amazon 云产品上的 SAP Business One 以及 SAP Netweaver。Gartner、Forrester 公司与其他行业研究分析师预测 ：到 2012 年世界顶级企业将

其 IT 需求迁移到云产品的比例会显著大幅上升。事实上，云承诺有着显著的影响。

2.1.2　云服务产品和部署模式

其于云计算的易用性，它现已成为企业内 CFO 和 CTO 重点关注的方案。主要是由于大

第 2章　迁移到云　 　33

型数据中心服务供应商的经营规模，而且它们已经实现了这一点。大型数据中心服务供应商

现在称为云服务供应商。除了开源的 Hadoop 一围绕 Apache 生态系统构建以外，Google 二、

Amazon 三、Microsoft 四和其他一些厂家也是主力成员。

IaaS IT 人员

PaaS程序员

SaaS架构师及用户

抽象计算 / 存储 / 带宽资源 ●Amazon Web Services[10,9]– EC2、S3、SDB、CDN、云观察（CloudWatch） ●

封装基础设施的抽象编程平台 ●Google Apps Engine(Java/Python)、微软的 Azure、Aneka ● [13]

封装基础设施及封装平台的应用 ●Salesforce.com、Gmail、Yahoo Mail、Facebook、Twitter ●

云应用部署与消费模式

公共云 混合云 私有云

图 2.2 云计算服务产品与部署模式

如图 2.2 所示，这些厂商的云服务产品大致可以分为三大流派：基础设施即服务（IaaS）、平台即服务（PaaS）与软件即服务（SaaS）。对众多的虚拟化 IT 需求而言，尽管 IT 经理

和系统管理员更喜欢 Amazon 提供的 IaaS，不过程序员则更喜欢 Google AppEngine (Java/Python 编程 ) 或 Microsoft Azure (.NET 编程 ) 等 PaaS 产品。大型企业里的软件用户不约而

同地发现，他们一直在使用云，这是因为他们使用了特定的软件包提供的服务，在本质上，

这项服务是一个 SaaS 产品。Salesforce.com 是 Internet 上 SaaS 产品的一个典范。

从技术的角度看，现在 IaaS 类型的云产品最为成功，使用也最广泛。不过，PaaS 的

潜力一直居高不下 ：所有新的面向云的应用开发计划都是以 PaaS 模式为基础的。企业利

用 IaaS 和 PaaS 的显著影响，以服务的形式在云上代表 SaaS 使用。无论是搜索（Google、Yahoo、Bing 等 ） 还 是 email（Gmail、Yahoomail、Hotmail 等 ） 或 社 交 网 络（Facebook、Twitter、Orkut 等），大多数用户并没有意识到他们的多数在线活动是由云以某种形式或者其

他形式来支持的。

云应用部署和消费可分为三层模式 ：来自云厂商的公共云产品、大型企业内部的私有云

计划（private cloud initiative）以及利用公共云与私有云或者管理数据中心服务的混合云计划

（hybrid cloud initiative）。面向服务的 IaaS 提供了抽象（或虚拟化和可扩展）的硬件，如计

算能力、存储或带宽。例如，从 2009 年 Amazon 五的关税定价网页上可以看出，它提供了六

一　http://appengine.google.com二　http://aws.amazon.com三　http://azure.microsoft.com四　http://hadoop.apache.org五　 http://aws.amazon.com/ec2

34　 　第一部分　基本原理

个层次的抽象弹性云计算（Elastic Cloud Compute，EC2）服务器能力 ：“小型实例”、“大型

实例”、“超大型实例”、“超强 CPU 型实例”、“超强 CPU 基本型实例”以及“超强 CPU 超

大型实例”。这些都表现在适当的内存、存储、性能保证和带宽支持上。PaaS 产品侧重于对

编程平台的支持，其运行时隐式地使用各个供应商提供的云服务。到目前为止，这些供应商

高度锁定，许多创新公司已经利用 PaaS 技术开发出新的应用。由于编程平台的内在云支持，

与 IaaS 产品相比，以 PaaS 为基础的应用程序提供更好的性能。云产品的 SaaS 侧重利用云

计算的优势支持大型软件包的使用。这些软件包的大多数用户都不约而同地忽略了底层云的

支持。其实，就算不是全部，绝大部分人也不关心它。事实上，软件包功能的有效程度无不

体现在云计算平台的深入（under the hood）支持上。例如，在 gmail 中，用户很难理会占用的

存储空间，或者是否需要删除 email 或者它的存储位置。这些无不反映了潜在的云，其中存储

（大多数不知道它在哪个系统上）易于扩展，或者就此而言，它存储在何处或者位于何处。

2.1.3　云的挑战

尽管云服务产品展现在 IaaS 情况下是简单 IT 观念模式，或者 PaaS 情况下是简单编程观

念模式、SaaS 情况下是资源使用的简单观念模式，但是底层系统面临的挑战仍然是巨大的、

复杂的。尽管底层系统非常容易出现故障、异构、资源占用，并表现出严重的安全缺陷，但

这些源于需求的主干为计算提供了一致相合和有力的简单观念。如图 2.3 所示，云的承诺与

大多数人更喜欢的典型分布式系统的属性非常相似。无论在 IaaS、PaaS 或者 SaaS 云服务中，

总有一个特别功能——全网可靠性，或者“即时”网络或“零”网络延迟，或者可能支持

“无限”带宽等。不过，在设计、实现和部署时，必须刻意避免这些设备 一（fallacies）构建在

健壮的分布式系统上。在确保切实管理好底层系统的同时，云计算已预测其服务理想化的观

点。事实上，在实施云计算服务时面临着很多挑战，如图 2.3 所示。

安全

性能监控

一致性与稳健的服务抽象

元调度

高能效的负载均衡

规模管理

SLA与 QoS的架构互操作性与可移植性

绿色 IT

分布式系统设备与云的承诺 云技术的挑战

全网可靠性

零网络延迟

无限带宽

安全的网络

无拓扑变化

集中管理

零传输成本

异构网与系统

图 2.3 实现云计算服务的“深入”挑战

其中面临的首要挑战便是安全性。云安全联盟（Cloud Security Alliance，CSA）旨在解

决这些问题 [8]。

一　 http://blogs.sun.com/jag/resource/Fallacies.html

第 2章　迁移到云　 　35

2.2　迁移到云的主要途径由于云计算是一种“突破性技术商业化模式”，根据 Gartner 2010 年的研究，云计算位

居十大战略技术之首 一，一些企业正在努力为迁移到云做准备。“云计算经济学”用于处理利

用云期间的经济学问题，它是基于云（cloud-based）的企业使用云成功的首要因素。以什么

样的 IT 成本——短期或长期，是否打算迁移到云？在企业取消了所有资本开支，仅有运营开

支可以利用的情况下，利用云能否满足企业所有的 IT 战略指标？与自己运行的私有数据中

心相比，总体拥有成本（TCO）确实大大减少。决策者、IT 经理及软件架构师在为新的企业

做 IT 规划时，面临着一些困境。

2.2.1　为何迁移

企业应用之所以要迁移到云，主要是一些经济和商业原因，另外还有一些技术因素。经

过众多努力，在企业中提出了采用云计算技术的倡议。这使得运行在专用数据中心上的企业

应用可以与在云上开发的新型企业应用进行集成。使用云计算服务或者与云计算服务集成是

迁移的一个使用案例。

以迁移到云中的应用为核心，可以采取以下几种方法 ：任何一个干净和独立的应用程序

都可以运行；在某种程度上代码需要修改和调整；或者设计（代码）需要先迁移到云计算服

务环境；最后设计迁移会使核心架构也迁移到云计算服务环境内，这需要开发一种新型架构，

同时所附带的设计和执行代码亦是如此。或者应用程序迁移时，需要迁移的应用程序正在使

用，因此，需要对其调整和修改。简而言之，迁移可能发生在应用程序、代码、设计、架构

和使用这五个层次之一。

有了适当的简化，企业应用程序迁移最好遵循如下准则：

P → PC′+ Pl

′→ P′OFC + Pl

′

其中，P 是在迁移之前运行在专用数据中心内的应用程序 ；PC′是迁移到（混合）云之后的

应用程序部分 ；Pl′是运行在本地专用数据中心内的应用程序部分 ；P′

OFC 是云优化应用程序

的一部分。如果一个企业应用程序不能完全迁移过去，它可能会导致部分应用程序继续运行

在本地专用数据中心上，剩余的应用程序则会迁移到云——实质上这是使用混合云的一种案

例。不过，当整个应用程序都迁移到云时，Pl′便为空。事实上，企业应用程序 P 可以在应

用程序、代码、设计、架构和使用这五个层次上迁移。由此可以认为，PC′可以在没有任何

Pl′组件的情况下，在这五个层次中的任意一个层次上迁移。将其与云计算服务产品（IaaS

模式、PaaS 模式或 SaaS 模式）组合使用——本书有各种情形下迁移的使用案例，这都需要

架构设计师通过深入思考来迁移。为了便于简洁地捕获这一情况，对于枚举，本书有如下迁

移方案用例 ：对于迁移到 IaaS 的产品，有 30 种使用案例 ；对于迁移到 PaaS 的产品，有 20种使用案例 ；对于迁移到 SaaS 的产品，这完全是在迁移的情形下使用，并未附带企业应用

一　 http://www.gartner.com/it/page.jsp?id=1210613

36　 　第一部分　基本原理

程序的迁移——就像从现有的本地 ERP 系统迁移到云提供的 SAP 系统一样。当然，这些迁

移的使用案例的详细方法存在于许多普遍适用的场景，企业已综合了他们迁移策略的最佳

实践。事实上，这些自定义和专有的最佳实践迁移产业已得到蓬勃的发展。在这些最佳实

践中，许多人专门从事企业应用程序的迁移——就像迁移应用程序服务器或者企业数据库

一样。

云计算经济学。迁移到云总是受经济原因驱动，例如 IT 资本开支（Capex）与运营开支

（Opex）方面的成本削减。既有迁移的短期效益，以抵消季节性和高可变 IT 负载，又有利用

云的长远效益。对于长期持续使用，截至 2009 年，云计算服务的一些障碍和缺点需要加以

解决。

Armbrust 等 [2] 阐述了云计算经济学的核心，即迁移时的经济可行性或者耐用性。如果

在云上使用企业应用程序的平均成本明显低于专用数据中心的成本，并且迁移成本并未增加

投资回报率（ROI）的负担，那么本书强烈建议迁移到云。

除了这些费用外，在迁移的云计算经济学中起重要作用的其他因素是许可问题（也许是

部分企业应用程序的）、SLA 规范以及云服务产品的价格。在广泛的层面上，大多数云服务

供应商有弹性计算、弹性存储或弹性带宽的费率。当然，这些定价费率也是可变的，因此迁

移的云计算经济学应该完全依据变化的价格。

2.2.2 云迁移的决策

事实上，企业应用程序概念和原型的一些论证是对云的尝试，这有助于在迁移到云时

作出一个明智的决定。迁移后，迁移的投资回报率应该对广泛的价格幅度持积极态度。在对

迁移诉求作出决定时，可以清晰地了解引人注目的因素或咨询一个专家小组以了解务实的方

法。在后一种情况下，有点像软件估算，适用于 WideBand Delphi Techniques 作出决定。本

书使用如下技术：这几类关键问题的调查问卷之所以影响 IT，是因为企业应用程序的迁移使

特定观众对他们的技术和业务专长所做出的选择。假设有 M 个这样的类。在整个问卷中，对

问题的每个类均分配了某个相关的权重 B。假设在问题 M 类中，有一类最大的问题 N。然

后，本书可以用权重为基础的决策模型作为 M×N 的权重矩阵，表示为

Cl≤∑ Bi（∑ Aij Xij）≤ Ch

M

i=1

N

j=1

其中，Cl 为最低权重迭代次数；Ch 为最高权重迭代次数；Aij 是为问题分配特定常量；Xij 是

介于 0 与 1 之间的分数，它表示与问题相关及匹配的程度。除了问题类，并非所有的类都有

N 个问题，其对应值可以为空值。本书定义了最低和最高迭代次数，以排除琐碎的迁移案例。

不过，有一个简单的变通方法作为平衡计分卡导向的决策。例如，在 Dargha[10] 的文章中是

通过云的方法实现的。

第 2章　迁移到云　 　37

2.3　迁移到云的七步模型通常情况下，迁移到云是分期或者分阶段实施的。迁移到云的一个结构化和面向过程的

方法自身有一些捕获众多迁移项目的最佳实践的优势。由于迁移是一个非常艰难和模棱两可

的问题，学者对此并没有太大的兴趣，行业的从业者也是如此。并非整个行业都在努力巩固

所赚取的最高收益与客户的长期痛苦。经过充分的研究和实践，本书分享的迁移到云的七个

步骤模型可以作为在企业范围内理解云计算和利用云计算提供服务产品的一部分。图 2.4 以

一种简洁的方式展示了迁移到云的七步模型，图 2.5 则展示了迁移到云的七步迭代过程。

云迁移评估包含对认识问题的评估，其中包括对应用程序级或代码、设计、体系结构或

使用级的具体情况所涉及的问题进行评估。此外，迁移评估所使用的工具、测试用例以及配

置、功能与云迁移评估的非转售（NFR）组成评估企业应用。这推动了富有意义的全面迁移

策略的制定。迁移七步模型的迭代过程的第一步是基本评估。一起利用定价参数的各种方法

迁移的概念或者原型证明可以做出适当的评估。

这些评估是迁移成本在生产版本的情况下，能够实现的投资回报率。下一个过程的第一

步是在专用数据中心内隔离所有企业应用程序组件的系统性及环境性依赖关系。反过来，这

也产生了迁移复杂性级别的问题。完成隔离之后，接着应该停留在本地专用数据中心到云的

映射构造。相当一部分的企业应用程序或许需要重建、重新设计并在云上重新实现。这得到

的仅是原有企业应用程序的功能。这种迁移或许会丢失某些功能。在接下来的处理步骤中，

本书利用云计算服务的内在功能以自己的方式增加企业应用程序。增加完企业应用程序之

后，接着用大量的测试套件验证和测试企业应用程序的新形式，其中测试套件还包括运行在

云上的企业应用程序测试组件。这些测试结果可能是积极的或迷惑的。在后一种情况下，本

书需要迭代并优化适当内容。经过几轮优化迭代之后，则认为迁移是成功的。本书的最佳实

践表明，最好是在这七步模型的优化过程中迭代，并确保迁移到云的（功能）强大性和全面

性。图 2.6 显示了迁移到云的七步模型所累积的最佳实践的典型组件。尽管列举的不是很全

面，但具有一定的代表性。

1. 进行云迁移评估

2. 隔离依赖关系

3. 映射消息与环境

4. 重新设计并实现失去的功能

5. 充分利用云的功能与特点

6. 测试迁移

7. 迭代与优化

图 2.4 迁移到云的七步模型（来源：Infosys 研究）

38　 　第一部分　基本原理

开始访问

优化

结束

隔离

迭代七步模型

测试

扩展 重新设计

映射

图 2.5 迭代迁移到云的七步模型（来源：Infosys 研究）

优化

• 优化—返工与迭

代

• 显著满足迁移的

云计算经济学

• 用标准和管理优

化法规遵从

• 提供最佳的迁移

投资回报率

• 利用新的云功能

制定路线图

访问

• 云计算经济学

•迁移成本

• 经常性费

用

• 数据库数

据分段

• 数据库迁

移

•功能迁移

• NFR 支持

隔离

•运行时环境

•许可证

•库依赖关系

• 应用程序依赖关系

•延迟瓶颈

•性能瓶颈

• 架构依赖关

系

映射

• 消息映射：编

组及取消编组

•映射环境

• 映射库及近似

运行时

重新设计

• 使用云运行

时的近似丢

失功能支持

API

• 新的使用案

例

•分析

•设计

扩展

• 开发云的额

外功能

•需求低成本

• 扩展自动伸

缩服务

•存储

•带宽

•安全性

测试

• 扩展测试案例

与测试自动化

• 运行概念证明

• 测试迁移策略

• 测试云扩展引

起的新的测试

用例

• 测试生产负载

图 2.6 迁移到云的迭代模型的七个步骤的一些细节

与迁移到 Amazon AWS 一的典型做法相比，本书的七步模型比较富有通用性，功能全

面。通常情况下，迁移到 Amazon AWS 分为好几个阶段和步骤。在 Amazon 网站的白皮书中

提到了六个步骤 ：第一阶段是云迁移评估阶段，其中的依赖关系是孤立的，制定战略处理这

些依赖关系 ；第二阶段是试用概念验证（proof of concept）构建一个参考迁移架构 ；第三阶

一　 http://aws.amazon.com

第 2章　迁移到云　 　39

段是数据迁移阶段，在这个阶段完成数据库数据的分段和清理，这一阶段还试图利用各种云

存储作为最适合的选项 ；第四阶段包括应用程序迁移追求其中一个“叉车式策略”（forklift strategy），随着它的依赖关系（其他应用程序），关键企业应用程序迁移到云中，或者可能使

用“混合迁移策略”（hybrid migration strategy），企业应用程序的关键部分保留在本地专用

数据中心，而非关键部分则移动到云中；第五阶段包括利用 Amazon AWS 的各种功能，如弹

性、自动伸缩、云存储等 ；在第六阶段，优化云迁移。这些阶段是 IT 人员迁移企业应用程

序的典范，它们未触及其内部结构，而只在配置层面——这与典型的 IaaS 云计算产品完全匹

配。然而，这仅是本书七步迁移模型的一个子集。对于 Amazon 云产品而言，这是很具体的

和专有的。

迁移的风险及风险缓解

云迁移项目的最大挑战是如何高效地鉴定迁移风险并缓解它。在云迁移的七步模型中，

测试和验证的过程步骤包括鉴定关键的迁移风险所做出的努力。在优化这一步骤上，本书提

出了各种方法缓解鉴定迁移的风险。

迁移到云的迁移风险可分为两大类：常规迁移风险以及与安全相关的迁移风险。在前面，

本书解决了包括性能监控和调优在内的一些问题。从本质上找出所有可能的生产层面的异

类；云计算服务领域中的业务连续性和灾难恢复；遵守标准和治理问题；IP 和许可问题；服

务质量（QoS）参数以及相应的 SLA 承诺；应用程序中数据的所有权、传输及存储；有助于

缓解潜在供应商锁定（lock-in）可移植性和互操作性问题 ；轻视和不理解迁移的复杂性问题

使得迁移失败，高级管理人员在这些努力中丧失了商业信心。

在安全性方面，云迁移的风险很大，这已在云安全联盟 [8] 公布的指导性文件中进行了

阐述。除了信任问题和隐私问题之外，还包括各种层次的企业应用程序适用于云的安全性问

题。有几个迁移策略和实施必须遵守的法律法规，其中包括获取正确的执行日志以及在详细

的级别保留所有审计跟踪权利——当前可能无法完全有效。当前的云计算服务厂商在治理问

题上有一些缺点。多租户问题以及在云计算环境中 IT 数据泄漏的影响是公认的，然而并没

有充分验证阻止此问题发生的解决方案的健壮性。漏洞管理和突发事件的反应质量的主要方

面有待云服务厂商大力支持。最后，还有一致的身份管理问题。这些问题在 2.1 节中已经讨

论过。随着适当的云计算的实现，图 2.3 中列出的问题和挑战依然是持续研究和工程挑战。

2.4 小结尽管迁移到云有很多挑战，许多迁移项目未能完全理解风险问题，主要赞助商和管理方

轻视它或者提交一段代码或数据到迁移的云中。在利用迁移到云的七步模型时，一个精心设

计的云迁移策略具有显著的机遇和成功因素。其中，最主要的是全面理解迁移的云计算经济

学以及底层技术面临的挑战。

对于每类企业应用程序和企业实践组（corporate practice group）而言，每个开发迁移到

云的最佳实践都是独一无二的。一些关键的最佳实践包括设计迁移和新的应用程序架构，以

及假设在云计算服务环境出现故障安全时为故障设计或编码。事实上，大多数云计算数据中

40　 　第一部分　基本原理

心使用的硬件产品经常出现故障。未反映这一现实的方法导致一些性能损失。另外一个最佳

实践是 ：目标企业应用程序的各个不同部分之间的松耦合的应用程序和实施。一个关键的最

佳实践必须确保各个层面和迁移层的安全性。最后，最重要的最佳实践必须充分利用云计算

服务的功能，同时在专用数据中心中部署的传统企业应用程序没有受到约束。迁移到云是一

个重要的活动。一个成功的迁移涉及各种复杂因素，这是极富挑战性的。在共同规划迁移到

云的行动和过程中，本书提出的迁移到云的七步模型有助于读者成功完成迁移。当然，最佳

实践是通过执行迁移项目积累起来的，迁移的七步模型就是一个映射。

致谢

衷心感谢 S. V. Subrahmanya 以及 E-Com 研究实验室、教育与研究部门（E&R）与

Infosys 公司的成员给予的帮助与支持。

参考文献

第 2章　迁移到云　 　41