【转】业务迁移上云秘籍

一、为什么迁移上云
目前还是有不少的中小企业把自己的业务工作负载放置在本地数据中心，面对着日益增大的业务量，本地数据中心开始慢慢凸显出一些弊端，难以满足企业新型业务的需求，并且购买以及更新设备都需要企业提前支出一大笔资金，很多中小企业难以承受其中的压力，通过迁移上云我们可以避免本地数据中心面临的一些问题。
降低建设及运维成本：托管自己的服务器基础结构需要对硬件，软件，电力和人员进行大量的投资，迁移到云解决方案显著降低资本支出。
减少硬件更新成本：不管是本地托管还是托管提供商处托管，更换硬件都将是繁杂的工作，还需要企业立刻投入所有硬件的费用。
解决软件支持终止问题：应用程序可能依赖支持即将终止的其他软件或者操作系统，迁移到 AWS可以为这些依赖关系提供扩展的支持选项，最大程度减少重构要求。
简化维护工作：很多系统的维护成本甚至超过它们的开发成本，采用云模式服务后基础平台的维护在云服务提供商。
有效控制投资风险：系统在开发过程的任何阶段都有失败的可能，但在开发的初期就要进行硬件投资，一旦失败前期的投资无法收回，采用云服务试错成本低。
敏捷与效率：自由的进行实验，更快速的开发。
灵活性：云的弹性可扩展，支持在线扩容。根据负载大小，弹性可伸缩。
全球化：在云中非常方便的把业务迁移到另一个地域。
多样性：第一时间体验到最先进的技术，如人工智能，机器学习，大数据，物联网等。
安全性：云平台采用冗余、多副本机制，云平台专用企业级防火墙，可自定义安全等级部署，云平台中有各种安全服务，保障我们的业务顺利进行，以及云服务满足各地域的法律法规。

二、迁移规划
当企业使用 AWS，可以实现按需高效、安全地运行资源，只需短短几小时，就能使企业以远胜从前的效率，敏捷地实现创新，再无需等待数月时间。那企业上云，想更快更好地将原有服务做迁移，制定迁移计划需要注意哪些问题？本篇文章将与你系统探讨 AWS 迁移模式。

迁移流程
在众多的迁移上云案例中，大家慢慢总结出了一个相对标准的迁移流程，按照这些流程进行业务迁移，可以提升我们的迁移效率，以及少走一些弯路。
1.资源评估：需要对本地业务资源有一个整体的了解，列出一个业务清单，记录环境中的物理和虚拟服务器。
2.发现和分析：对整理出来的资源进行分析，确定是否适合上云，以及云中使用有相应的服务支持。
3.计划和设计：如果满足上云要求，我们要制定迁移策略。
4.迁移，整合，验证：进行迁移，验证，以及业务切换。
5.运维和优化：利用云中的服务对我们的业务进行管理和优化。

迁移评估
在开始规划之前设定云迁移的优先级和目标，从而确保迁移更加成功。此外，自动云迁移工具还可提供有关环境和依赖关系的见解，帮助制定云迁移项目计划。在企业计划迁移阶段，需要系统评估多方因素，其中包含业务因素、合规因素、安全因素、平台因素及人员因素等，这些是迁移的基础考量。
业务因素：需要考量所有主要利益相关方，是否都支持业务案例和对迁移的承诺，并且是否有资金可以投入迁移工作；
合规因素：需要看企业是否有符合合规标准的应用程序；
安全因素：需要考虑到企业在数据保密性方面的主要挑战，并且采取了哪些控制措施；
平台因素：需要确定一系列试点应用程序，并且得到工作负载所有者的承诺；
人员因素：需要验证企业的技能和能力，是否定义了运营的角色和责任。
借助 AWS 的云迁移评估工具 Application Discovery Service，它可以自动识别在本地数据中心运行的应用程序、其相关依赖关系和性能配置文件，让你能够制定自己的云迁移计划。
运用此信息来映射服务器，从而呈现你的本地应用程序。这将有助于确定服务器之间的依赖关系或通信，让你能够在云迁移计划中包含所有必备的应用程序组件，从而帮助降低风险，确保顺利迁移。然后，按逻辑方式对服务器分组以呈现应用程序，并根据每个应用程序的要求和迁移目标为其选择最佳的云迁移策略。

迁移策略
在确定评估因素后，我们展开讨论计划阶段最重要的迁移模式问题，这对企业而言至关重要。对此，AWS 系统总结了 6R 迁移理论提供参考，包括：保留 (Retain)、停用 (Retire)、更换主机 (Rehost)、替换 (Replace)、更换平台 (Replatform)、重构 (Refactor)，不同的业务应用我们可以采用不同的迁移策略，企业根据应用的评估，选择不同的迁移策略。
Retain：有些应用不能立刻迁移，或者不允许迁移到云中，我们继续留在本地数据中心
Retire：在评估过程中，发现一些不再需要的业务，我们可以从数据中心删除。
Rehost：这种无代码选项通常称为“直接迁移”，可让你快速将现有应用程序迁移到 AWS。每个应用程序按“原样”进行迁移，既发挥了云的优势，又无需承担更改代码所带来的风险或成本。
Replace： 替换现有的应用。比如使用云中的 SaaS 服务替换我们的应用。
Replatform：更改平台作为云迁移的一部分，比如将 Windows 更换成 Amazon Linux。
Refactor：对应用重构，然后迁移上云，比如更改后端数据库，中间件等，相对来说比较复杂。
在迁移过程中我们不只用到一种迁移模式，即使在一个应用程序栈中，企业也可能会遇到 2~3 个 “R”，我们要充分分析应用程序，进行组合搭配，以达到最低的成本和最高的价值。

三、迁移服务及工具
在了解了迁移上云的过程，以及迁移过程中用到的一些策略之后，那么我们开始对本地中心的应用进行迁移上云，我们知道云数据中心中最重要的三项基础设施资源主要是计算、存储、网络，那我们也主要以这三部分为大家介绍一下各自的迁移方法，以及相关的注意事项。

网络迁移
本地数据中心的网络一般是私有网络，大部分是扁平化的网络，一些业务规模比较大的企业，他们都有自己的网络工程师来规划相对复杂的网络，网络迁移的复杂程度主要取决于本地数据中心的网络复杂程度，至于如何把本地网络迁移到 AWS 中，我们也需要根据不同的情况去考量。
在 AWS 云中，我们是通过 VPC 来实现私有网络建设的，VPC 的各项功能基本可以满足企业网络的各项需求，那我们该如何去设计我们的网络呢？
完全复制：应用程序里面嵌入了服务器的私有 IP，整体迁移不去修改代码，并且没有计划使用混合云模式，针对这一部分，我们可以在 VPC 中建立一个和本地数据中心一模一样的网络，拥有相同的 IP 地址块，但是需要注意，VPC 中的一些安全设定本地中心可能没有，比如 NACL、Security group 等。
混合云模式：有些企业部分应用迁移上云，并且未来规划混合云的模式。针对这种情况，我们在 VPC 中设计的网络，其 IP 地址块与本地数据中心的 IP 地址块不能重合，既然是重新规划 IP 地址范围，那我们尽量每个子网的分配的 IP 数量多一些。
本地数据中心的网络冗余，高可用方案，需要精通高级网络的工程师来进行配置和维护，网络上云之后，所有的这些都由 AWS 来进行维护，企业的维护人员具备简单的网络知识即可维护，降低了网络管理的门槛，也为企业节省开支。

工作负载迁移
我们把支撑业务运行的一些资源称之为工作负载，我们可以把虚拟机、数据库、应用等粗略的规划在工作负载层面，下面我们主要针对这几部分来说一下迁移过程中的情况，这也是我们整个迁移最重要的环节。

虚拟机迁移
将虚拟机转移到云端有助于避免会造成巨大财务压力的更新周期。准备就绪后，我们可以通过两种简单方式使用直接原样迁移策略进行迁移，我们使用 Rehost 作为我们的迁移策略。
第一种：我们可以使用 AWS Server Migration Service (AWS SMS) 将虚拟机从本地或其他云平台直接迁移到 AWS。AWS SMS 是一项免费的服务，它可以帮我们把本地虚拟机增量的复制为可在 Amazon EC2 上部署的云托管的 Amazon 系统映像 (AMI)，整个复制过程，我们只需要支付迁移期间所使用的 S3 存储桶、EBS 卷和数据传输费用，以及所运行的 EC2 实例费用。
第二种：我们也可以使用 VMWare Cloud on AWS 解决方案将您的 VMware 虚拟机直接迁移到 AWS。 这意味着您现有的基于 VMware 的工作负载可从云端的性能、规模和安全性中获益，而无需在迁移时重写。
注意事项
因为是整体的搬迁服务器，要考虑到带宽是否满足，是否需要增加临时带宽。
复制过程中有可能会用到临时的一些磁盘，存储方面是否足够。
防火墙的替换，云中没有物理防火墙，可以考虑使用 AWS 的安全组来替换。
价值体现
可以享受更低廉的价格以及更先进的配置。
多区域节点选择。
提高员工效率，由传统 IT 运维转移到业务上面。

数据库服务迁移
本地数据中心的数据库服务，一般都是在物理机或者虚拟机上面，由运维人员部署，针对数据库的迁移，我们主要有以下注意事项以及解决方案：
迁移策略：针对数据库，我们可以选择的迁移策略有 Rehost 和 和 Replatform。
针对 Rehost，我们可以直接使用 AWS SMS 来进行迁移。
针对 Replatform，就是我们把本地自建的数据库服务转换为 AWS 的数据库服务，AWS 的数据库很丰富，基本涵盖了市面上的所有数据库，包括关系型数据库和非关系型数据库。
注意事项
兼容性要求，如：文件格式，字符集的兼容性要求，引擎的兼容要求。
数据迁移的限制，如，服务商数据库名/表名保留字；是否影响业务及其程度；是否需要停服务以及停服务的时间。
迁移工具的便利性，服务商指导。好的迁移方案&工具应该是尽可能少人工操作，step by step，自动化。
数据完整性校验，在数据迁移完毕进行切换前，一定要进行数据完整性验证，以保证数据被正确、完整的迁移。如：部分服务商不能提供完整性校验，或者在校验存在不一致时无法给出具体信息，实际也无法定位。
价值体现
云数据库的高性能，高可靠性，扩展性，灵活性
大规模创新
兼具备份、扩容、迁移等功能
DBA 不用再去维护数据库的安装，运行，高可用，备份等，把精力集中在数据库优化业务上面。
对于 Rehost 的迁移，我们可以很方便地使用 AWS SMS 工具来完成，不过其中可能会有数据延迟，因为数据并不是实时同步的，所以我一般推荐大家使用云中的数据库，他具有我们传统自建数据库没有的一些优势。
AWS Database Migration Service (AWS DMS) 是一项云服务，可轻松迁移关系数据库、数据仓库、NoSQL 数据库及其他类型的数据存储。您可以使用 AWS DMS 将数据迁移到 AWS 云，在本地实例之间（通过 AWS 云设置）进行迁移，或者在云与本地设置的组合之间进行迁移，使用 DMS 服务，可以保证我们的源数据库和目标数据库数据实时同步，持续运行，使用这种模式，可以保证我们的数据库迁移零宕机。
对于一部分用户，他想在上云之后换一种数据库引擎，比如 Oracle 转换成 Aurora MySQL，遇到这种情况，我们可以借助 AWS Schema Conversion Tool 这项服务来帮助我们完成，在使用 SCT 的时候，比较消耗内存，提高内存性能可以提高转换速度，但会占用台式计算机的更多内存资源。

应用迁移
在实现应用迁移上云的过程中，一般会面临已有业务系统改造和新建业务系统两种场景。新建业务系统只需要按照应用上云的标准要求进行架构设计、研发、编码和测试即可，实现相对简单。已有业务系统迁移上云则需要对现有业务系统改造。
迁移策略：
对于 Rehost，使用 AWS SMS 服务可以方便地迁移整个应用程序技术栈上云，这种迁移相对来说比较简单，迁移完成之后，修改一下后端数据库信息，切换 DNS 服务即可上线。
对于 Refactor，这种情况会花费比较多的工作量，他需要用户重构应用程序代码，使其可以充分的去兼容云原生的一些服务，比如 Lambda，API GateWay，Elastic Beanstalk 等一些服务，以提高我们应用程序的性能和安全。
注意事项
是否有相关的应用程序路线图
有哪些相关的成本与此应用程序有关系
有哪些改进选项可增强服务可用性
如果不改变这个应用程序，是否有相关风险
此应用是否与组织的技术目标互相一致
价值体现
可以使用云原生的一些服务
可以借助云中 DepOps 工具加速应用程序的测试与发布
运维开发人员不用再去管理应用环境的配置，专注于应用代码的开发，提升效率
对于应用程序上云，我们一般是先在云中完全建立一套完整应用程序环境，等待程序测试无误之后，通过修改 DNS 来完成应用上云，应用稳定后，应用程序就可以逐步的有计划从本地中心移除。

容器迁移
随着近些年容器的流行，越来越多的公司会有一些服务运行在容器平台中。如果容器运行在单机上面，我们一般直接使用 docker 命令运行，或者使用 docker-compose，对于运行在多机器上面的容器服务，我们大部分使用的都是现在很流行的容器编排服务 kubernetes。
因为容器的特性，它可以把整个程序运行环境打包到镜像中，我们不需要再单独为其配置运行环境，根据这方面特性，对运行在容器中的应用程序迁移上云变得简单了很多，用户不需要对代码进行任何更改即可完成迁移上云。
那么在 AWS 上面有哪些容器平台供我们选择使用呢？相对于本地自建的容器平台又有什么优势？
在 AWS 云平台中，有两个容器编排工具供我们选择，一个是 Amazon Elastic Container Service (ECS) 或 Amazon Elastic Kubernetes Service (EKS)。
如果应用程序是运行在单机上面的，在云中最佳的选择是 ECS，ECS 是一项高度可扩展的快速容器管理服务，它可轻松运行、停止和管理集群上的 Docker 容器，ECS 与 Identity and Access Management (IAM)、Amazon Virtual Private Cloud (VPC) 和 Amazon Route 53 等 AWS 服务深度集成，并在安全性、可靠性和可用性方面进行了广泛的测试，以支持内部和客户的任务关键型服务。
如果应用程序运行在 kubernetes 上的，在云中的最佳选择是 EKS，EKS 则是运行 Kubernetes 的最安全、可靠且可扩展的方式。EKS 提供的控制平面不仅可扩展且高度可用，还能跨多个可用区运行，以消除单点故障。EKS 可运行上游 Kubernetes，并且经认证与 Kubernetes 一致，因此您可以获得社区中开源工具的所有优势。
在 AWS 上运行容器时，您有两个平台可以进行选择。首先，您可以选择是否要管理服务器。如果您想要进行容器的无服务器计算，请选择 AWS Fargate，如果您需要控制计算环境的安装、配置和管理，则选 Amazon EC2。
Fargate 是客户跨 ECS 和 EKS 在 AWS 上运行容器的首选方式。客户喜欢 Fargate 是因为它提供容器的无服务器计算，此服务可使他们专注于构建其应用程序。使用 Fargate，您无需预置和管理服务器，而且可以为每个应用程序指定资源并为其付费，并通过设计隔离应用程序来提高安全性。
AWS 容器平台优势
低成本：可以选择部分 spot 实例作为底层资源节省费用。
企业就绪
弹性扩展：云中 EKS 相比自建的 kubernetes 多 Cluster Autoscaler 特性，可以根据负载扩展集群中的服务器数量，ECS 中由 capacity providers 来提供底层计算资源弹性伸缩。
更可靠：ECS 和 EKS 的控制面板由 AWS 完全托管，服务的可用性由 AWS 专业技术团队维护。
网络：使用 Amazon VPC CNI，使 container 或者 pod 具有 VPC IP，省去网络封包，提升网络性能。
负载均衡：通过使用 AWS ALB，可以让流量直达 container 或者 pod 的 IP，集群可以省去 原有 service 流量分发，提升转发性能。
权限：可以直接为 container 或者 pod 赋予 IAM role 级别的权限，安全访问 AWS 其他服务。
那么面对这么多服务，我们该如何选择呢？
首先对于非分布式的应用，也就是单个的容器服务，我推荐选择 ECS + EC2 平台，ECS 为我们简化了容器设定，降低管理容器的门槛，用户只需要按照容器运行的要求设置好 Task definitions 即可，如果您不想管理 EC2，那推荐选择 EC2 + Fargate。
对于运行在 kubernetes 平台的应用程序，首选推荐 EKS + EC2 平台，也可以启动一部分 spot 实例混搭以节省费用，可以把在本地 kubernetes 上使用的 yaml 文件直接在 EKS 上运行，不需要特别的修改，整个迁移相对来说更加简单，相对于 ECS，管理 EKS 集群需要运维人员更高的一些容器编排技能。对于一些访问量波动比较大的应用程序，我们可以运行在 Fargate 平台上面，弹性扩展底层硬件。

数据迁移
这里所说的数据主要是静态存放的数据，以及一些归档数据，需要把这些数据传输到 S3 中，数据迁移工具的选择主要是考量数据量的大小，以及本地数据中心的带宽大小，不同的组合用到的迁移工具也不尽相同。
AWS DataSync 是一种数据传输服务，可以简化、自动执行和加快本地存储与 Amazon S3 或 Amazon Elastic File System (Amazon EFS) 或 Amazon FSx for Windows File Server 之间的数据迁移。DataSync 使用本地代理连接到 NFS 文件系统，并快速迁移文件数据（比开源复制工具的速度快 10 倍），而无需编写和管理脚本。DataSync 会执行完整的初始副本，增量传输以及对已传输数据的验证。如果您有可用的网络带宽，那么 DataSync 是迁移基于文件的数据的最简单方法。
AWS Transfer for SFTP (AWS SFTP) 是一项完全托管的 AWS 服务，可让您通过安全文件传输协议 (SFTP) 将文件传入和传出 Amazon Simple Storage Service (Amazon S3) 存储。SFTP 也称为安全外壳 (SSH) 文件传输协议。
AWS Snow 系列可以为那些需要在严峻的非数据中心环境中运行操作、将大量数据迁出本地环境以及遇到缺乏一致网络连接的情况的客户提供帮助。Snow 系列由 AWS Snowcone、AWS Snowball 和 AWS Snowmobile 组成，可以提供各种物理设备和容量点，其中大部分设备还内置有计算功能。这些服务使您能够在本地经济高效地使用 AWS 云的存储和计算能力，从而有效地传输数据并加速迁移。
我们可以很简单的通过数据库和带宽估算出数据上云所消耗的时间，企业可以根据自己所能承受的能力来选择不同的工具，对于一些数据量比较小的，可以使用 DataSync，SFTP，当然也可也使用 aws cli 把数据传输到 S3，然后对于数据量比较巨大的，通过网络传输相当消耗时间的，我们可以使用 Snow 系列来传输数据。

四、优化
利用 AWS 安全管理服务来管理云环境，从而管理和监控云环境中的应用程序。开始在迁移期间使用这些服务，也可以在迁移后继续使用其中的部分服务来保证混合云的一致体验。

云成本管理：AWS 账单和成本管理是一项 Web 服务，借助该服务提供的功能可帮助您监控成本并支付账单。Amazon Web Services (AWS) 根据使用情况向您的账户收取费用，可确保您只需按实际使用量付费。
使用 AWS 产品/服务节省费用：购买 AWS 的 RIs 还有 Savings Plans 服务，借助 Compute Optimizer 的推荐调整虚拟机的大小，以实现利用率最高，价值最大化。
加快实现应用现代化：利用所节省的资源来增添更多云功能，慢慢把云中的工作负载迁移到无服务模式，实现应用的现代化。

五、安全与管理
AWS 非常注重客户业务的安全性，AWS 具有众多的安全服务来保障我们的应用与数据安全，这里只简单介绍一下我们常用的几个服务。

业界领先的安全性：AWS Security Hub 向您提供 AWS 资源安全状态的全面视图。Security Hub 跨各 AWS 账户和服务收集安全数据，帮助您分析安全趋势，确定整个 AWS 环境中的安全问题并明确其优先级。
监视分析云健康状况：利用 Amazon CloudWatch 跟踪云应用的运行状况和性能、基础结构和数据。从各来源轻松收集数据，并获得丰富见解。
有效管理虚拟机：借助 Systems Manager 可以轻松批量管理众多虚拟机，如命令批量执行，操作管理、应用程序管理、操作和更改、实例和节点。

六、客户案例
笔者曾经在一家数据分析的公司任职，公司的主要业务是通过对手机 APP 数据进行分析。之前的业务全部在上海的数据中心，公司的应用程序主要是 Java 程序，数据库有 MySQL和 Oracle，大数据处理平台是通过多台物理机自建的 Hadoop 集群。

上云之前，如果临时接了一个项目，IDC 的资源难以及时有效的支持相应服务，公司需要硬件采购，（包括服务器，防火墙，交换机在内的相关基础硬件），设备上架，网络规划，系统安装及配置，以及大量的人工运维。整个周期需要至少半月到一个月左右。

通过一次培训，了解到云计算相关的特性，客户开始对部分业务进行上云评估，通过半月时间对本地数据中心的工作负载进行梳理并列出清单，根据AWS提供的迁移策略和最佳实践逐步将业务迁移上云。需要注意的是很多业务需要分步骤上云，逐步去替代掉本地数据中心的业务，在上云的过程中，客户对部分应用进行了优化和重构，使其更加适应云原生的服务。

经过近一年多的 AWS 云服务的使用，客户充分体验到云服务的优势：

节省硬件部署时间消耗，提高服务上线时间：客户不必再花大量的时间在硬件采购和上架以及系统安装上；设备上线大大缩短了时间，由之前的数周缩短为一小时以内。
简化数据库管理：我们由自己部署的数据库，全部切换为云中的数据库，包括 RDS 还有非关系型数据库，MySQL 我们更是直接采用了 Amazon Aurora Serverless 数据库，不在为估算数据库的配置而苦恼，它会根据业务的负载自动的扩容缩容，极大的减轻了我们的维护压力，DBA 人员不必再为数据库部署，高可用，备份，以及维护花费精力，这些工作只需要在云中点击记下就可以完成，DBA 把工作技术在业务上面的优化，极大的为我们节省了人工成本，并提高了工作效率。
提高应用上线效率：上云之前，我们部署应用相对比较繁琐，因为我们是 Java 程序，每上线一个新程序，都需要去配置一个tomcat，因为端口不可以公用，我们需要修改每个 tomcat 的配置更改端口，久而久之，tomcat 越来越大，非常不便于管理，我们对部分应用重构之后上云，对于一些功能简单的应用，我们部署在了 Lambda 上面，并通过 API Gateway 来触发，不必再去关注底层服务器；另外一部分应用直接部署在了 Elastic Beanstalk 上面，可由开发人员直接部署，不必再去为环境搭建而花费时间，还有一部分应用放在了 ECS 上面，使用容器技术也极大提升了我们的部署效率。
节省总体成本：上云之后，对于成本的节省也非常显著，我们粗略估算，费用节省高达 40%，这主要归功于云计算的灵活性，弹性，以及低成本，不必提前预置一大批硬件花费大量金钱，对于长时间运行的一些服务，我们购买了预留实例来节省成本。简单拿我们的大数据平台来说，之前我们是几十台服务器组成的集群，集群的利用率并不高，但是也不能没有，上云之后，我们直接购买的 EMR 服务，我们了解到 AWS 有一种叫做 spot 的实例，费用节省最高达 90%，我们的大数据工作负载，基本 80% 的服务器全部是买的 spot 实例，分析完之后销毁所有的实例，单单这一特性，为我们节省了非常大的成本。
云中的优势还远远不止于此，比如在安全性方面，各种安全服务保障我们的业务顺利进行，以及我们可以第一时间使用最先进的服务，可以非常方便地使用机器学习等其他服务，它不但减轻了我们的工作，也为企业节省了巨大的费用。
————————————————
版权声明：本文为CSDN博主「wangzan18」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/wangzan18/article/details/107253505