前言
随着互联网的发展，以及大数据时代的来临，信息数据量也呈现出迅速增长的发展趋势，越来越多企业认识到，数据不仅可以在本地存储，还可以在云端存储。而云原生数据库就是一种稳定可靠、可弹性伸缩，解决数据运维工作的数据库服务。
项目使用前期调研
亚马逊云科技提供了100余种产品免费套餐。其中，计算资源 Amazon EC2 首年12个月免费，750小时/月；存储资源 Amazon S3 首年12个月免费，5GB 标准存储容量；数据库资源 Amazon RDS 首年12个月免费，750小时；Amazon Dynamo DB 25GB 存储容量 永久免费。https://aws.amazon.com/cn/free/
我公司苏州凯捷智能科技有限公司从本地存储更换为亚马逊云科技数据库存储数据。
本人公司2021年开业创业性公司主要服务对象3C、新能源、政府等。数据存储量比较大。因为创业性公司不会专门搭建一个服务器用于存储，对于时间、成本等条件。肯定不能满足这样使用。于是我们开始调研云数据库性能对比，价格等。最终选择了 Amazon。
公司的预算以及规模要求
在几万预算中性能对比下来 Amazon 数据存储、数据操作简单方便技术目前是全球领先的据我了解在全球范围内，Amazon 在云服务领域处于领导者地位。数以百万计的客户——包括发展最快的初创企业、最大的企业和领先的政府机构——相信 Amazon 能够为他们的基础设施提供动力，变得更加灵活，并降低成本。
丰富的云服务和功能
Amazon 在各个方面的业务需求上，都有对应的产品或者整体的解决方案存在。Amazon 的这些服务还具有最为多样复杂的功能。例如，Amazon 提供了种类繁多的数据库，这些数据库是为不同类型的应用程序专门构建的，因此您可以选择适合作业的工具来获得最佳的成本和性能。
覆盖全球的云基础设施
Amazon 拥有强大的、充满活力的生态系统，拥有数百万活跃客户和数万合作伙伴。Amazon 客户几乎涵盖所有行业和规模的组织，包括初创企业、企业和公共部门组织。
强大的云计算生态
WS 开发工具完善、文档和教程齐全、社区氛围友好，在 Amazon 上开发应用非常方便。
最终苏州凯捷智能科技有限公司选择了Amazon 数据存储服务。
首先讲讲什么是云原生数据库？
云原生数据库是一种通过云平台进行构建、部署和分发的服务。作为一种云平台，云原生数据库以 Paas 的形式进行分发，也经常被称作 DBaas ；用户可以将该平台用于多种目的，例如存储，管理和提取数据。
简单来说，云原生数据库，是一种通过云平台进行构建、部署和分发的服务。这种云原生属性是它相比于其他类型数据库最大的特点。作为一种云平台，云原生数据库以 Paas (平台即服务, Platform-as-a-Service )的形式进行分发，也经常被称作 DBaas (数据库即服务, DataBase-as-a-Service)。用户可以将该平台用于多种目的，例如存储，管理和提取数据。
云原生数据库通常通过在云基础设施之上安装数据库软件来实现，这种方式使得云原生数据库具备了传统数据库所不具备的直接访问性和运行时可伸缩性。随着云原生数据和海量计算的重要性不断提高，人们空前重视通过部署这种服务为企业提供增强的可靠性和可伸缩性。
mysql 数据库，云数据库的优势有哪些？
1、服务可用性
云数据库具有高可用性，完善的数据自动备份机制，数据可保留时间长，分钟级别可完成故障转移。而在自购服务器搭建的传统数据库服务中，需自行搭建主从复制，自建 RAID，单独实现或者购买负载均衡设备等。
2、数据可靠性
云数据库是保证99.95%高可靠的，提供主从数据存储，支持按时间点恢复、秒级监控等，保障线上数据安全。而在自购服务器搭建的传统数据库服务中，需要自行保障。
3、系统安全性
云数据库具有高安全性，DDoS 防护，能帮助用户抵御攻击流量，减少数据安全风险，保证业务的正常运行。而传统数据库则需自行部署，价格高昂，同时也需自行修复数据库安全漏洞。
4、软硬件投入
云厂商提供的云数据库不需要客户购置 软硬件投，并且支持按需付费。而传统数据库成本相对较高，对于 SQL Server 还需支付许可证费用。
云数据库结合云服务器使用，具有数据传输稳定高可用，内网带宽传输速度快，可扩展性高的优势。相对于自建数据库，云数据库具有更经济、更专业、更高效、更安全、简单易用等特点，用户能更专注于核心业务。
睿江云目前拥有单节点，双节点，三节点三个版本的云数据库，用户可根据业务需求选择购买。高性能、高安全、高可靠的数据库服务，可以有效地减轻用户的运维压力，为用户带来安全可靠的全新体验。
5、转身 Amazon 原因
第一个就是分布式、高可扩展性的 OLTP 数据库的云原生化。我认为包括 Amazon Aurora、包括现在的主流的这些号称 Cloud Native 的一些数据库，还远没有到达一个最终形态，它相当于只是一个把一个单机数据库的技术云化了而已。分布式数据库如何与云原生真正结合，这现在还是一个悬而未决的问题。这个问题的本质就是分布式数据库如何从 On Cloud，走向 In Cloud。
手把手教你将服务器迁移到 Amazon 全过程
迁移策略方案
以上这些数据库由 Amazon 完全托管，用户不用去管理底层硬件系统升级维护等相关工作，这也是推荐使用全托管数据库而非自建数据库的原因。为了方便客户数据库迁移上云，Amazon 还为客户提供了非常方便的迁移工具 DMS，帮助用户轻松经济高效的完成迁移任务。
那么面对这么多种类的数据库，尤其是一些新型数据库，我们从来没有使用过，我们该如何选择？我们需要从业务场景为出发点来分析使用哪种数据库，下面我对 Amazon 数据库的使用场景做个简单的介绍，也让大家对 Amazon 各种数据库的应用场景有一个大致了解。
1、盘点云服务
首先盘点下我们用到的阿里云服务有哪些？云服务器 ECS，负载均衡 SLB，对象存储 OSS，大数据服务 MaxCompute，其中数据库、缓存、队列之类均使用 ECS + 开源产品搭建，而非阿里云服务。基本 Amazon 均有对标产品，EC2， ELB，S3 等可以满足需求，当然成本上 Amazon 产品还是略贵一些。
2.盘点服务机器
在线服务主要依赖ECS ，系统搭建 CentOS，部署应用服务器，数据中心主要包括 Mysql 、MongoDB、Redis、ES、OSS等 ，中间件服务，消息队列，路由网关等。离线服务数据仓库主要基于 MaxCompute，以及相关报表服务。
3.迁移策略
3.1.离线服务迁移策略
在新数据中心建立数仓，导入历史数据，新机房搭建 ETL 服务，迁移后增量数据从新机房在线服务中抽取。迁移可独立进行不受限于在线服务，注意在线服务迁移节点前后的数据补录和剔除。由于阿里云 MaxCompute 服务与 hive 语法有差异，此处还有些 sql 修改的工作。
3.2.在线服务迁移策略
原机房服务架构情况如下图：
图中 router 作为网关和负载均衡，简化队列等其他服务。迁移方案总体分为不停服迁移和停服迁移两种，下面就具体分析下如何选型。
3.3.不停服迁移方案
首先在新机房按同等架构部署一套服务，数据库维持主从架构（原机房做主，新机房做从），redis （只用于缓存）两边各自部署维护。
从 网关层（router）切流量到新机房应用服务，但服务读写数据库仍从原机房（阿里云机房），如果不考虑延时或一致性要求不高的场景可以从新机房数据库读，写到原机房数据库。
应用流量迁移后，切换数据库读写到新机房，迁移前需要检查新机房是否有数据落后，通过变更连接配置进行切换，对使用数据库长连接的连接池模式，需要在程序做支持，捕获配置变更后启动新配置的连接池。
此方案采用从应用服务层到数据层自顶向下迁移，迁移过程中会出现双机房双活和跨机房调用的情况，确保尽可能少的出现跨机房调用。
方案优点：
服务基本可用，对用户无感知，或感知较小。
方案缺点：
实施过程复杂，跨机房数据延时会影响服务正常，切换瞬间可能会有数据不一致。
为了减少跨机房延时，一般采用拉专线方式，同机房数据传输一般延时在 10ms 以内， 同城专线一般延时在 10 ms 左右，跨城专线一般在 10 - 200 ms，公网传输一般在几百毫秒。
由于两个机房之间无法直接拉专线，跨机房调用可能会导致服务延时失败，出现更多不可控因素，且业务存在夜间低峰期且无新用户，停服影响可接受，因此最终实施将会按停服方案来操作。
3.4.停服迁移方案
和不停服一样，首先搭建一套镜像服务，在某个时间点会将所有写入暂停（无新数据写入），待数据全部同步新机房后，在新机房启动服务，并将流量完全导向新机房。
方案优点：
实施过程简单，实施过程中不会出现脏数据。
方案缺点：
会有一段时间对用户完全不可用，必须根据业务场景来评估是否可接受。
实现流程
1.完善实施细节
实施迁移前，必要的准备工作必不可少，购买新机房服务，配置网络及服务的搭建，应用服务的部署，数据库的准备及数据同步（及一致性检查），涉及到 ip 变更合作机构加白名单，以及必要的通知工作，最后需要对新机房服务做回归测试和校验。为了防止遗漏，最好使用 checklist 清单，完成一项对其打钩。
2.执行迁移过程
选择合适的迁移时间，服务低峰时间，避开必要的定时任务执行时间，梳理清可提前的或可推后的定时任务，迁移时间与必须按时执行的定时任务错峰。迁移过程对用户访问进行限制，除测试白名单可正常访问服务，其他用户会提示 “系统升级，请稍后回来” 。迁移计划可以分几步，确定好时间，执行人，执行内容，必要的执行操作，做好 checklist 清单，格式如下：
停止原机房对外服务
1)上线代码控制访问请求
2)停止定时脚本和常驻 （注意顺序）
3)观察数据无写入 xx 时间，保险起见对主库改为 readonly
4)观察队列无新增，消费已完成 （可省略迁移队列数据）
外网域名 DNS 解析切换
1)外网域名 DNS 解析切换
2)DNS 解析生效需要周期，此时打入旧机房流量可以做转发到新机房
新机房服务恢复
1）在准备阶段已完成服务部署，数据库维持从库同步数据，此时断开与主库连接
2）可以校验数据是否完全一致，准备阶段完成历史记录校验，迁移阶段只校验增量部分
3）涉及 OSS 数据，需要同步到 S3，没有直接同步工具，可以先下载再上传，最后写了个比对工具校验两边一致性
4）定时任务和常驻进程在新机房启动。
回归测试
恢复对外服务
1)观察日志监控
2)服务和业务监控
3)其他系统服务恢复
3.迁移过程的突发事件
虽然做了“万全”的计划，但迁移过程还是会发生一些计划外的事件，这时候就要随机应变了，但一个基本原则就是是否可以先忽略？如果不影响正常业务可以事后解决。
在停止对外访问后，按预期将没有新数据写入，但发现 MongoDB 数据库仍有数据写入，通过追查连接 ip 发现有其他部门服务连接，此时半夜无法联系到对方处理，最后确认该数据表我们并不使用，那么可以忽略不处理，但因为此项确认比预期要长，整体迁移时间也向后发生了偏移。
MongoDB 采用了停服后全量数据导出，在新服务器上导入的方案，并未使用从库。因为数据量较少，导出恢复速度快，不会有不一致问题。
在使用 Amazon 的 负载均衡服务（ELB）时，发现了与阿里云的 SLB 不一样的情况，在长连接服务过程中会断开连接，而当时在场的 Amazon 技术支持也未能有效解决，当时根据情况决策不使用负载均衡，直接连接 ip 的方式，先解决了服务断开的问题。
Amazon 负载均衡有健康检查机制，如果长时间无目标响应就会断开连接。
4.回滚计划
在做迁移计划时，也会出相应的回滚方案，如果不符合预期就会执行回退到阿里云，那么在停服阶段的回滚，相对比较简单且无损。而一旦对外开放流量后再回退，基本上需要执行迁移方案的逆向操作。
收尾
服务前移完成后，还有一些收尾的工作，以及服务的观察和监控。系统指标对比：如 cpu、内存、io 等系统层面的使用情况和负载
应用指标对比：如接口响应时间，QPS 等情况
业务指标对比：如关键业务的转化率等情况迁移前可在原机房看一些关键数据，如最后一条用户数据、订单数据等，然后在新机房有针对性的查看放量后新增数据情况。经过历时几个小时的通宵迁移，服务已平稳从阿里云机房迁移至了 Amazon 机房，观察几个小时后整体符合预期，算是基本圆满达成目标。
Amazon 数据库优势
在众多的云厂商中，我们为什么选择 Amazon 数据库服务，Amazon 还有哪些独特的优势呢？我主要总结以下几点：
成本优势
使用自建数据，企业首先需要支付一笔资金购买服务器，一些商业数据库的授权，需要再次支付一笔费用。如果迁移到 Amazon 的自研数据库，客户不必再支付高昂的商业数据库授权，也不必再去花费大量资金去购买服务器，在云中，客户只需要按量付费，因此很多企业由于把数据库迁移到 Amazon 而节省巨大费用支出。
从最近的 Amazon 公告中，看到 Amazon 帮助三星把数据从商业数据库 Oracle 迁移到了 Aurora，为三星每月的数据库成本降低了 44%，并让三星的数据库运行更加稳定。
完全托管
以上所说的几种数据库都是 Amazon 完全托管的数据库，完全托管意味着零运维。首先客户不需要去维护硬件的生命周期、系统的补丁更新、高可用的部署、备份等。如果需要对数据库扩展，也只需点几下鼠标而已，非让方便，让 DBA 从复杂的数据库运维中解脱出来，专注于数据库性能调优。
全球优势
过去我们需要借助非常复杂的技术手段，花费大量的成本、甚至牺牲一定的可用性，才能实现快速、稳定、安全的跨区域的数据复制，现在只要在 Amazon 云中轻轻点几下鼠标即可完成。
Amazon 云现已在全球 24 个地理区域内运营着 77 个可用区，180个边缘站点等，为 Amazon 相应全球数据库提供了基础保障。依托于 Amazon 强大的基础设施，目前已经有三款数据库支持全球同步，延迟通常不超过 1 秒，可以满足目前大部分应用的需求。
对于关系型数据库的全球同步需求，Amazon Aurora Global Database 能够允许用户轻松实现跨区域的数据库部署，让用户轻松在区域之间复制数据和解决更新冲突，从而更加专注于应用程序的业务逻辑。Amazon 还提供了 Amazon DynamoDB Global Tables。它基于 DynamoDB 的全球覆盖范围构建，具有多区域、多主表的特性，可让全局分布式应用程序实现快速的本地读写性能，为用户提供一个完全托管的、多区域、多主的 Key-Value 类型数据库。
针对缓存数据库，在众多组织都在利用 Redis 为全球用户提供低延迟访问的背景下，Amazon 为更好满足客户的需求，Amazon 推出了 Amazon ElastiCache Global Datastore for Redis 全球缓存数据库，为用户提供数据跨区域复制，可以在一个区域写入数据，同时在其他区域读取数据，使缓存的数据更接近用户，减少网络延迟，并提高应用程序的响应能力。
心得与建议
当然，数据库迁移是一个庞大而复杂的工程，尤其将数据库迁移上公有云，除了数据库知识更需要了解公有云上网络，存储，虚拟化等一系列知识。但是，我们不应该仅仅将数据库上云看做一个复杂的任务，更应该把它当做一个优化我们数据库的契机，那么上云过程中有哪些注意事项和建议呢？
对于一些允许停机的应用，这部分数据我们推荐使用离线迁移，整个操作比较简单，速度快，不容易出问题。
如果业务需要在线迁移，那么推荐使用 DMS 进行迁移，需要注意的是，在数据库切换之前先停掉源数据库写入，带数据完全同步到目标数据库之后进行数据库切换。如果迁移的数据量比较大，建议选择配置比较大的复制实例，这样可以加速我们的复制速度。如果您想要转换数据库引擎，在使用 SCT 进行 Schema 转换的时候可能会遇到一些目标数据库不支持的地方，请先联系 DBA 人员，对这些地方进行更改，满足之后再进行转换。
资料分享
- 数据库免费试用链接及上手教程：https://aws.amazon.com/cn/getting-started/databases/get-started/
- 云原生数据库在线大会：https://www.awsevents.cn/CloudNative/listDetails.html
粉丝福利
亚马逊云科技专为开发者们打造了多种学习平台：
- 入门资源中心：从0到1 轻松上手云服务，内容涵盖：成本管理，上手训练，开发资源。https://aws.amazon.com/cn/getting-started/
- 架构中心：亚马逊云科技架构中心提供了云平台参考架构图表、经过审查的架构解决方案、Well-Architected 最佳实践、模式、图标等。https://aws.amazon.com/cn/architecture/
- 构建者库：了解亚马逊云科技如何构建和运营软件。https://aws.amazon.com/cn/builders-library/
- 用于在亚马逊云科技平台上开发和管理应用程序的工具包：https://aws.amazon.com/cn/tools/
【专属福利】
福利一：100余种产品免费套餐。其中，计算资源 Amazon EC2 首年12个月免费，750小时/月；存储资源 Amazon S3 首年12个月免费，5GB 标准存储容量。https://aws.amazon.com/cn/free/
福利二：最新优惠大礼包，200$数据与分析抵扣券，200$机器学习抵扣券，200$微服务与应用开发抵扣券。https://www.amazonaws.cn/campaign/
原文来自亚马逊云科技开发者文章：
https://dev.amazoncloud.cn/column/articleDetail?id=63209584ed07ac10b0752c74
