剖析Amazon、Autodesk等迁移上云的成功案例，看 A

小提示：您能找到这篇{剖析Amazon、Autodesk等迁移上云的成功案例，看 A}绝对不是偶然，我们能帮您找到潜在客户，解决您的困扰。如果您对本页介绍的剖析Amazon、Autodesk等迁移上云的成功案例，看 A内容感兴趣，有相关需求意向欢迎拨打我们的服务热线，或留言咨询，我们将第一时间联系您！

< ">数据库迁移上云？你是否还在为千头万绪不知从何处开始而烦恼呢？别担心，小编今天告诉你一个数据库迁移的独家秘籍！

< font-size: 16px;">在数据库领域，过去的几十年里，客户不得不与具有高锁定性和惩罚性许可条款的商业数据库厂商打交道，付出高昂的成本。同时，我们看到许多客户试图尽可能地迁移到开源数据库，然而往往需要面对实现企业级性能和扩展的挑战。客户希望挣脱束缚，实现成本的节约，从而专注于发展和创新。

< font-size: 16px;">在转向开放源代码数据库的客户要求我们以客户友好的策略、开放源代码数据库的自由性和可移植性来实现商业级数据库的性能。这就是为什么我们构建了Amazon Aurora，一个与MySQL和PostgreSQL兼容的关系数据库，它是为云构建的，将高端商业数据库的性能和可用性与开源数据库的简单性和成本效益结合在一起。Amazon Aurora的性能是标准MySQL的5倍，是标准PostgreSQL的3倍，具有商业级数据库的安全性、可用性和可靠性，成本是标准PostgreSQL的1/10。

< font-size: 16px;">现在的你是不是对Amazon Aurora充满好奇呢？那就快来跟着小编一起看看在AWS上进行业务数据迁移的客户案例吧~

< font-size: 16px;">No.1

< font-size: 16px;">< font-size: 18px; color: rgb(75, 172, 198);">企业核心业务

< font-size: 16px;">< font-size: 18px; color: rgb(75, 172, 198);">数据库迁移之路

< font-size: 16px;">案例一：Autodesk的核心业务数据库迁移之路

作为全球软件解决方案的领导者，Autodesk始终关注中国制造业的痛点与发展需求，借助人工智能、数据库以及相关技术，帮助制造厂商挖掘设计的更多可能性，提升生产的可预判性，旨在让制造商无需高额的资金和人力成本即可实现轻松生产。

< font-size: 16px;">Autodesk公司多年之前就已经启动了自己的云计算现代化之旅，着手将工作负载从本地数据中心迁移至Amazon Elastic Compute Cloud(EC2)及其他AWS服务当中。Autodesk之所以积极推进现代化改造，自然是为了获取必要的灵活性与可扩展性，支持业务的预期增长。2019年，该公司将其关键任务单点登录（AutodeskSSO）应用从Amazon EC2上的自托管SQL Server中迁移至全托管Amazon Aurora MySQL。此项服务需要应对全球各地超过1.42亿用户的身份验证请求，每分钟API请求响应数量超过14万5千次。此外，该应用还整合了300多种用于实现身份验证与授权操作的产品及服务。

< font-size: 16px;">此次迁移有助于简化Autodesk SSO服务的管理与弹性、优化运营成本并降低基础设施的维护开销。根据初步成本分析结果，该公司在使用Amazon Aurora MySQL之后每月总体数据库成本可下降约40%至50%。

< font-size: 16px;">通过本文，我们将探讨Autodesk公司如何在尽可能缩短停机时间的前提下，对关键任务数据库进行迁移。以下各章节将分别介绍迁移前架构、迁移策略、迁移步骤以及性能比较等相关议题。

< font-size: 16px;">迁移前架构

< font-size: 16px;">下图所示，为Autodesk以往使用的SQL Server架构。该数据库以自托管形式在Amazon EC2实例之上运行，且跨越多个可用区与另一区域内的单一节点建立起Always On机制，借此实现灾难恢复能力。

< font-size: 16px;">随着时间推移，Autodesk团队发现现有配置中存在以下挑战：

< font-size: 16px;">中断——以往发生的诸多中断事件，正是由于这套复杂的自找托管数据库基础设施所导致。整个体系中涉及多个采用Amazon Elastic Block Store(EBS)加RAID 10存储配置的Amazon EC2实例，结果就是Windows Server故障转移集群（WSFC）、存储以及IOPS等众多元素构成极为复杂的分层体系。更重要的是，运营团队越来越难以对事件根源进行分析与追溯。

< font-size: 16px;">备份——管理备份也带来可观的开销，特别是在跨区域设置层面。尽管我们使用了自动化脚本，但整个备份流程仍然需要人为介入与严格监控。

< font-size: 16px;">补丁修复——由于Autodesk公司拥有多个环境（包括测试环境、暂存环境与生产环境），因此补丁修复消费了管理员们大量宝贵的时间。

< font-size: 16px;">可扩展性——主节点负责填写只读路由请求，同时标记需要接入的辅助节点。尽管此功能能够保证连接始终被路由至运行状态良好的辅助节点，但从可扩展性的角度来看，主节点的存在本身即是最大的瓶颈。

< font-size: 16px;">副本数量——SQL Server最多允许设置8个辅助副本，而Amazon Aurora MySQL最多可支持15个副本。

< font-size: 16px;">成本——原本的总体拥有成本，达到迁移至Amazon Aurora之后新体系的两倍。

< font-size: 16px;">弹性——对基础设施进行规模伸缩需要耗费大量时间。

< font-size: 16px;">迁移策略

< font-size: 16px;">我们从概念验证起步，借此确定需要完成的应用程序变更、数据库变更、脚本自动化以及各类预创建服务。更重要的是，我们还借此确定迁移至Amazon Aurora这一举措能够有效解决前面提到的种种挑战。

< font-size: 16px;">在实施必要的变更之后，我们制定了计划，以分阶段方式迁移至不同环境。以此为基础，我们对策略进行微调，逐步明确了在不同环境上运行迁移时所带来的相应停机时间。我们的目标是在最少的停机时长之内完成迁移。为了在不同环境间灵活高效地实现迁移，我们利用Terraform自动执行数据库创建与AWS DMS配置等步骤。当然，大家也可以使用AWS CloudFormation实现相同的自动化效果。

< font-size: 16px;">在以下章节中，我们将具体探讨迁移过程中的各注意事项。

Schema迁移

< font-size: 16px;">AWS Schema转换工具是一款出色的schema迁移工具，能够将迁移工作量控制在最低水平。但在本示例中，由于存在大量定制化需求，我们只能放弃效率、选择更适合的schema转换方法。

< font-size: 16px;">作为schema转换流程中的一部分，我们首先为数据库选择了最佳字符集。如此一来，我们的数据库体积将缩减到原始大小的三分之一左右。对数据库的成功“瘦身”，将在迁移过程中带来巨大助益。

< font-size: 16px;">在确定目标数据库的最终架构之前，我们需要全面评估以下因素：

< font-size: 16px;">字符集与排序规则

< font-size: 16px;">数据类型选择

< font-size: 16px;">日期/时间模式

< font-size: 16px;">多字节字符存储

< font-size: 16px;">特殊字符存储

< font-size: 16px;">索引类型

< font-size: 16px;">这些注意事项不仅有助于数据迁移，同时也将避免因引入特殊数据集而导致的各类迁移后问题。

容量规划

< font-size: 16px;">我们对容量规划进行了广泛测试，包括迭代运行工作负载以确定合适的实例大小与对应容量。此外，我们还比较了来自各类监控工具（例如Amazon CloudWatch、New Relic以及MonYog）的关键指标、分析慢查询日志，并对现有生产工作负载/流量及未来数据增长做出预测。

应用程序迁移

< font-size: 16px;">应用程序迁移将以无缝化形式进行，因为我们使用NHibernate（ORM）进行数据访问。ORM生成约80%的查询比例，因此我们可以在应用程序内以最少的ORM配置变更生成MySQL查询。这里也建议大家首先观察应用程序通过ORM生成了多少查询，并据此估算转换其余查询所需要的具体工作量。

< font-size: 16px;">我们网站舆情监控系统在SSO应用程序中开发了一项功能，用于支持按需数据库连接切换并进一步实现对读取/写入流量的控制。以此为基础，我们能够在整个迁移计划中实现连续部署与跨环境执行。最后，这项举措还有助于最大程度减少数据库切换操作所带来的停机时间。

< font-size: 16px;">之前，我们使用的是完整NET框架，遗憾的是带有NHibernate的NET完整框架中的MySQL驱动程序并不支持Amazon Aurora MySQL故障转移功能。换句话说，我们的应用程序将无法自行实现故障恢复。为此，我们提出了一项自定义解决方案，针对NET中MySQL驱动程序缺失的问题为Amazon Aurora MySQL故障转移提供新的支持方法，确保应用程序能够在迁移过程中继续正常支持业务流量。

数据迁移

< font-size: 16px;">数据迁移与验证是整个迁移流程中的重要一步。我们使用AWS Database Migration Service（DMS）以实现安全且经济的迁移效果。关于更多详细信息，请参阅AWS DMS上手指南。

迁移步骤

< font-size: 16px;">下图所示，为迁移中的各项状态与具体步骤。图中为前滚迁移模式，各个步骤将帮助大家快速理解与迁移进度相关的情况。在下面几个章节中，我们将就每种状态及其内容做出说明。

< font-size: 16px;">只要可能，我们都会提前创建服务与基础设施。例如，在开始迁移之前，我们的Amazon Aurora MySQL数据库、SQL服务回滚数据库以及AWS DMS实例都已经准备就绪。

< font-size: 16px;">初始状态

< font-size: 16px;">即SQL Server服务的初始状态。

< font-size: 16px;">第一步

< font-size: 16px;">在这一步中，我们将正式开始从SQL Server到Amazon Aurora MySQL的全加载迁移。所谓全加载迁移，实际上是一套时间点快照副本，DMS负责将数据从源数据库复制到目标数据库。

< font-size: 16px;">从数据库的约束角度来看，要想获得最佳全加载性能，理想的作法是在导入全加载前仅部署各主键。在全加载之后，我们再逐步添加其他约束元素，例如外键。由于AWS DMS会从多个表处并行加载数据，因此复杂的外键关系可能会减慢加载过程。在Amazon Aurora河池网站建设 MySQL上，最好只包含写入节点。而在SQL Server回滚设置中，理想的作法是在主节点中创建回滚数据库。另外，在单一节点上创建索引会进一步提升速度，特别是在表体积很大的情况下。

< font-size: 16px;">第二步

< font-size: 16px;">在完成从SQL Server到Amazon Aurora MySQL的全加载创建后，下一步是从Amazon Aurora MySQL到SQL Server回滚数据库创建全加载副本。任务完成后，我们即在源数据库、Amazon Aurora MySQL以及SQL Server回滚数据库之间完成了全加载数据同步。

< font-size: 16px;">第三步

< font-size: 16px;">在这一步中，我们将向Amazon Aurora MySQL与SQL Server回滚数据库添加索引与外键，向Amazon Aurora MySQL添加读取节点，并将回滚数据库添加至Always On数据库。通过这些操作，我们的全加载性能将有所提升，同时保证数据库在切换完成之前始终处于高可用性状态。

< font-size: 16px;">大家当然可以在全加载期间启用验证，但如果您接下来打算使用变更数据捕捉（CDC），这里提醒大家在CDC阶段再启用验证效果更好。AWS DMS负责对整体数据进行验证，其中包括全部全加载组成部分的迁移数据。AWS DMS提供一项特殊功能，允许用户在其中设置定制化验证功能。我们会大量使用此项功能以验证各特殊字网络推广软文范文符与Blob数据类型。

< font-size: 16px;">作为质量检查（QA）流程中的一部分，我们对部分重要工作流者做了验证。我们在全加载后进行了一轮示例数据验证，希望确保关键工作流能够按预期正常运作。此项示例数据验证以DMS验证为基础。经过全面测试之后，我们开始进入CDC阶段，将全加载之后累积的增量变更从源数据库传输至Aurora MySQL，再将Aurora MySQL传输至SQL Server回滚数据库。

< font-size: 16px;">在此期间，AWS DMS会将迁移指标发送至Amazon CloudWatch。若需了解更多详细信息，请参阅监控AWS DMS任务。

< font-size: 16px;">第四步

< font-size: 16px;">在CDC执行期间，我们一直在密切监控Amazon CloudWatch中的以下几项指标：

< font-size: 16px;">  ValidationPendingOverallCount

< font-size: 16px;">  CDCLatencySource

< font-size: 16px;">  CDCLatencyTarget

< font-size: 16px;">在ValidationPendingOverallCount达到低值，而源数据库与目标数据库之间的CDC延迟最低时，我们即可着手执行数据库切换。数据库切换同样分几个步骤，我们首先需要停止应用程序的写入流量、等待挂起记录得到全部验证，而后切换应用程序中的标记以使其指向Amazon Aurora MySQL。

< font-size: 16px;">上述指标的最佳数值，取决于您的实际用例与变化速度。大家可能需要通过多轮测试以确定具体数值。

< font-size: 16px;">以下示例图为ValidationPendingOverallCount指标。大家可以看到初始挂起行数很高，之后逐渐减少。

< font-size: 16px;">以下示例图为CDC LatencySource指标，它显示的是源数据库最后捕捉到的事件与AWS DMS实例当前系统时间戳之间的间隔（单位为秒）。如果因任务作用域导致未能从源数据库处捕捉到任何变更，则AWS DMS会将此值设置为0。

< font-size: 16px;">以下示例图为CDC LatencyTarget指标，它显示的是Amazon Aurora MySQL上首个等待提交的事件时间戳与AWS DMS实例当前时间戳之间的间隔（单位为秒）。如此出现此值，则意味着存在Amazon Aurora MySQL无法处理的事务。因为如果所有事务都得到正常应用，那么目标数据库延迟应该与源数据库延迟相同。目标数据库延迟不得低于源数据库延迟。

< font-size: 16px;">第五步

< font-size: 16px;">在本步当中，我们的应用程序已经指向Amazon Aurora MySQL并保持良好运行。我们的团队对应用程序进行了端到端测试，旨在确保所有功能都可正常工作。整个回滚设置共运行数天，帮助我们观察其实际运行状态。

< font-size: 16px;">最终状态

< font-size: 16px;">在这一步中，我们删除了回滚设置。下图所示为我们构建完成的迁移后架构。

< font-size: 16px;">回滚步骤

< font-size: 16px;">在这一步中，我们的目标是在最糟糕的情况下制定备份计划。由于数据库在关键任务服务中扮演重要角色，因此我们必须引入完善的回滚机制以从最坏的情况中恢复正常。

< font-size: 16px;">如果在发生故障时仍必须使用当前数据库，我们的计划是首先停止向Amazon Aurora写入流量，等待挂起记录得到验证，而后将应用程序切换至回滚数据库SQL Server Always On）。如此一来，我们就可以在不丢失任何数据的前提下还原至旧有设置。

< font-size: 16px;">当然，要保证回滚设置正常起效，我们必须对其进行充足的测试与验证。我们在测试环境中使用生产规模的数据以执行测试，并确保当应用程序从Amazon Aurora MySQL切换至回滚数据库时，不会导致任何数据丢失问题。

< font-size: 16px;">性能比较

< font-size: 16px;">我们从迁移前与迁移后的读写查询中，捕捉到前10条查询性能进行比较。

< font-size: 16px;">下图所示，为前10条读取查询的查询性能。可以看到，Amazon Aurora的性能表现相当出色。

< font-size: 16px;">下图所示为前10科写入查询的查询性能。Amazon Aurora MySQL在这里的性能表现同样胜过MSSQL，执行时长也远低于MSSQL。

< font-size: 16px;">相关建议

< font-size: 16px;">除了之前章节中提到的方法，我们还为大家整理出以下建议：

< font-size: 16px;">充分规划运行测试，这样您才能总结出适合现有数据库的迁移策略。绝不存在百试百灵的策略，因此请务必拿出自己的配置思路并逐步做出优化。

< font-size: 16px;">进行多轮性能测试以实现SQL查询调优；SQL查询在不同的数据库上会表现出不同的行为。

< font-size: 16px;">最大限度提升迁移流程的自动化水平。在实践中，我们使用Terraform实现自动化，从而快速重复多轮测试并总结出统一的迁移执行流程。

< font-size: 16px;">尽可能设置警报机制，同时通过适当监控以分析迁移流程。

< font-size: 16px;">为了预留充足的时间以处理意外错误，理想的作法是至少在计划切换的一天之内实现数据库切换点（详见迁移步骤中的第四步）。

Autodesk案例小结

< font-size: 16px;">异构数据库的迁移工作往往困难重重，但凭借AWS DMS的协助以及妥善规划，Autodesk仍然顺利从SQL Server迁移到了Amazon Aurora MySQL。通过此轮迁移，该公司不断显著提升了运营效率，同时也对基础设施的成本与性能做出优化。

< font-size: 16px;">Autodesk以及其他众多企业已经开始享受Amazon Aurora MySQL带来的种种助益，包括Amazon电商也利用AWS实现了数据库自由。除此之外，中国支线航空商业模式的引领者和践行者——华夏航空也通过AWS完成了核心数据的迁移，跟着小编一起看看吧。

< font-size: 16px;">案例二：Amazon电商利用AWS实现数据库自由

Amazon电商在迁移过程中面临两项关键挑战。一是如何解决大规模的项目管理问题，因为这对于带动多样化、全球分布的团队开展项目和跟踪进度非常必要。二是迁移涉及高度技术复杂性。要想成功完成该项目，很明显，公司的业务线需要集中协调、培训和技术支持。

< font-size: 16px;">为了克服这两项挑战，Amazon电商一开始就创建企业项目管理办公室(PMO)，设定明确的业绩要求，并且对每个服务团队进行周度、月度、季度审查，以跟踪和报告项目进度和状态。

< font-size: 16px;">AWS技术核心团队，由经验丰富的解决方案架构师和数据库工程师组成，这也是项目成功的关键。该团队就哪些AWS服务最适合于从Oracle迁移过来的Amazon电商数据的每一个类别提出了建议。

< font-size: 16px;">Amazon电商还仔细考虑了如何以最佳方式，帮助Oracle数据库管理员走上现行的新职业发展道路。其中一个选项是，帮助他们获得转型成为AWS解决方案架构师所需的必要技能。另一个选项是，在基于Oracle的传统环境和AWS云环境之间搭建桥梁的过程中，给予管理角色，在此角色下，Oracle背景很有帮助。

< font-size: 16px;">案例三：华夏航空选择AWS将核心数据迁移上云

华夏航空股份有限公司成立于2006年，是中国支线航空商业模式的引领者和践行者。截至2018年底，公司在飞航线123条，其中国内航线120条，国际支线航线3条，独飞航线114条，占公司航线比例达93%；通航城市107个，其中国际航点城市2个；公司支线航点占全部国内支线机场比例达41%。

< font-size: 16px;">2018年华夏航空开始具体地实施迁移上云工作。按照规划，华夏航空将全面采用由西云数据运营的AWS中国（宁夏）区域构建云基础架构，到2020年左右把绝大部分应用都迁移上云。

< font-size: 16px;">华夏航空的上云顺序是这样规划的。第一步，让华夏航空的中转系统2.0上云；第二步，迁移营销、内部管理以及相关的业务系统，2018年总共完成十几个这样的系统上云；第三步，核心业务运行和保障系统上云，这一块比较庞大，计划在2019年做迁移。第四步，到2020年，把飞行管理、安保管理、安全管理以及一些周边的业务管理，尽可能都迁移上云。

< font-size: 16px;">根据华夏航空的估算，业务应用上云后，可以节省成本20%~30%，有的应用甚至可以节省50%以上的成本。对一些应用，如果加以改造、优化后上云，可以节省更多成本。例如，把原来的Oracle数据库改成MySQL数据库，省去商业数据库软件昂贵的授权及持续的高额服务费用。