共计 3108 个字符，预计需要花费 8 分钟才能阅读完成。
因为云计算行业的飞速发展，当初很多企业都致力于将要害企业应用程序迁徙到公共云。在某些状况下，企业团队在云迁徙中遇到了艰难，并且成绩无限。但能够通过所学到的经验教训在随后的尝试中改良后果。
如果企业正在寻求对工作要害型应用程序进行现代化革新，并且打算将云迁徙作为此过程的一部分，那么借鉴别人的教训则能够事倍功半。
因而，本文将通过这些常识来构建企业管理者须要思考和解决的次要畛域的 10 个步骤，以最大限度地进步胜利迁徙云的机会。
1、建设迁徙架构师角色
在开始云迁徙之前，须要建设迁徙架构师角色来领导这项工作。迁徙架构师是零碎架构师级别的职位，负责布局和实现迁徙的所有工作流程。他们的外围职责应包含定义使迁徙胜利所需的必要重构、设计数据迁徙策略、定义云解决方案要求以及确定迁徙优先级和生产切换机制。
在大型迁徙我的项目的过程中，必须做出许多决策和技术打算，而领有一个负责迁徙各个方面迁徙架构师对于我的项目的胜利至关重要。
2、抉择星散成级别
当企业将应用程序从本地数据中心迁徙到云时，能够通过两种形式迁徙应用程序 – 浅层星散成或深层星散成。
对于浅层星散成（有时称为“晋升和转移”），企业将本地应用程序挪动到云中，并且为了运行利用。任何应用程序更改都足以让它在新环境中运行，不应用云独有的服务。此模型也称为晋升和转移，因为应用程序“按原样”晋升并挪动或转移到云中。
对于深度星散成，企业能够在迁徙过程中批改应用程序以利用要害的云性能。企业能够应用先进的主动扩大和动静负载平衡，或者它可能与将 AWS Lambda 等无服务器计算性能用于局部应用程序一样简单。它还可能波及应用特定于云的数据存储，例如 Amazon S3 或 DynamoDB。
3、抉择繁多云或应用多云
在开始云迁徙之前，请对此问题进行思考：是想抉择一个云提供商并迁徙您的应用程序，以便它针对该繁多环境优化运行，还是心愿应用程序在多个云提供商上运行？
优化应用程序以与特定的云提供商一起工作绝对简略。开发团队只需学习一组云 API，应用程序就能够利用云供应商提供的所有。
这种办法的毛病是供应商锁定。一旦企业更新了应用程序以仅与一个提供商单干，将应用程序挪动到另一个提供商可能须要与原始云迁徙一样繁冗的流程。此外，领有繁多云提供商可能会对企业与云提供商协商重要条款（例如定价和 SLA）的能力产生负面影响。
而且，它也变得更加简单。应用多个云提供商有几种不同的模型：
1）一云一利用。 另一个云中的另一个应用程序。兴许最简略的多云办法在一个云提供商中运行一组应用程序，在另一个云提供商中运行另一组应用程序。这种办法使企业能够进步与多个提供商的业务杠杆作用，以及未来在何处搁置应用程序的灵活性。它还容许企业针对运行它的提供程序优化每个应用程序。
2）跨多个云提供商拆分应用程序。 一些公司抉择在一个云提供商中运行应用程序的一部分，而在另一个云提供商中运行它的其余局部。这种办法让企业能够利用每个提供商提供的要害劣势（例如，一个提供商可能具备更好的 AI 性能，而另一个提供商可能以其数据库速度而闻名）。这里的危险是企业的应用程序与两个提供商的性能相干，任何一个提供商的任何问题都可能影响应用程序的客户体验。
3）将应用程序构建为与云无关。 应用这种办法，企业能够在多个提供商上同时运行应用程序，或者将应用程序负载扩散到它们之间。该模型为企业在供应商会谈中提供了最大的灵活性，因为企业能够轻松地将负载从一个云提供商转移到另一个云提供商。毛病是会造成很难应用每个云提供商的要害性能，从而升高了将应用程序托管在云中的益处。
4、建设云 KPI
要害绩效指标 (KPI) 是企业收集的无关应用程序或服务的指标，用于掂量其执行状况是否合乎预期。云迁徙的最佳 KPI 显示了企业正在进行的迁徙是如何进行的，说明了可能埋伏在应用程序中的可见或不可见的问题。兴许最重要的是，云迁徙 KPI 能够帮忙企业确定迁徙何时实现并胜利。
云迁徙 KPI 有几个要害类别：
对于每个类别，确定哪些指标对本身业务最重要，哪些指标将受迁徙到云的影响最大。
5、建设绩效基准
基线是测量应用程序或服务的以后（迁徙前）性能的过程，以确定其将来（迁徙后）性能是否能够承受。基线可帮忙团队确定迁徙何时实现，并验证预期的迁徙后性能改良。还能够在云迁徙期间参考基线来诊断呈现的任何问题。
管理者须要决定掂量的每个 KPI 设置基线指标。确定将收集数据多长时间以确定基线。抉择较短的基线期（例如一天）能够让团队更快地口头，但可能无奈收集到具备代表性的绩效样本。抉择更长的基线工夫（例如一个月）显然须要更多工夫，但能够提供更具代表性的数据。
团队管理者还须要确定是否只想收集均匀或代表性的基线数据，或者是否心愿包含在“顶峰”或“要害”期间收集的数据。无论哪种数据收集模型适宜所在行业，请务必明确定义要收集的数据类型和时间段。
6、优先思考迁徙组件
企业管理者还必须决定是一次迁徙整个应用程序，还是将其一一组件或一一服务迁徙到云组件。
首先，确定服务之间的连贯以及哪些服务依赖于哪些其余服务。应用依赖关系图来决定应该迁徙哪些组件以及以什么程序迁徙。从具备起码依赖关系的服务开始通常是有意义的。
在这种状况下，须要首先迁徙最外部的服务，而后跟进最内部的服务——通常是最靠近客户的服务。另一种办法是从最靠近客户的服务（最内部的服务）开始，这样就能够管制对客户的所有影响。
7、执行任何必要的重构
企业可能心愿在迁徙应用程序和服务之前对其进行其余工作，以便它们在云中尽可能无效和高效地工作。例如，他们可能想要重构应用程序：
因而，它能够无效地与可变数量的运行实例一起工作，以容许动静扩大，从而可能节俭云服务老本。
这样，企业的资源利用率就能够更好地利用动静云性能，例如依据须要动态分配和勾销分配资源的能力，而不是提前动态分配资源。
在迁徙之前迁徙到更加面向服务的架构，以便企业能够更轻松地将单个服务迁徙到云中。
8、创立数据迁徙打算
迁徙数据是云迁徙中最辣手的局部之一。数据的地位会显著影响应用程序的性能。当数据拜访办法依然次要是在本地时将数据挪动到云会显著影响性能。如果数据依然在本地，但拜访它的服务驻留在云中，状况也是如此。
数据迁徙的选项包含：
在本地数据库和云数据库之间应用双向同步机制。将所有数据使用者移至云后，删除本地数据库。
应用与基于云的数据库单向同步的本地数据库，并容许消费者仅连贯到本地版本。准备就绪后，禁用对本地版本的拜访，以便基于云的版本成为主数据库，并启用基于云的消费者对新数据库的拜访。
9、切换生产
企业何时以及如何将生产零碎从旧的本地解决方案切换到新的云版本？答案取决于应用程序的复杂性和架构，尤其是数据和数据存储的架构。
有两种常见的办法：
1）一次性实现。 等到将整个应用程序或服务移到云上并验证它能够在那里工作，而后将流量从本地堆栈切换到云堆栈。
2）一次做一点。 挪动一些客户，测试所有是否依然无效，而后再挪动一些客户。持续此过程，直到将所有客户转移到基于云的应用程序。
10、查看应用程序资源分配
即便在实现将所有内容迁徙到云之后，还有一些事件须要思考。最重要的是资源优化。云针对动静资源分配进行了优化，当动态分配资源（例如服务器）时，企业并没有利用云的劣势。
当迁徙到云中时，请确保团队制订了将资源分配给应用程序的打算。当须要为云中的应用程序调配额定的资源时，供应商通常能够随时从供应商处取得简直任何数量的资源。
文中的 10 个步骤涵盖了很多内容，但在云迁徙过程中，还应该思考其余事项。例如，创立安全可靠的云环境显然是所有云迁徙的要害局部。侥幸的是，次要的云提供商提供了重要的工具和资源来帮忙企业构建和保护一个平安的零碎。