助力某电商系统平台成功迁移至AWS云项目案例-下篇

新钛云服已累计为您分享785篇技术干货

迁移设计方案

AWS云架构图

AWS架构说明

通过AWS遍布全球的基础设施，整个架构基础架构主要说明如下：

· 业务主要使用的资源有Amazon EC2、Amazon RDS、LB、CloudWatch等

· 为了保证可用性，服务器资源全部采用多AZ部署

· 为了提升数据库性能，此次迁移把原RDS数据库迁移到AWS RDS

· 静态资产（如图像和视频）存放在S3

· 业务流向为用户访问各个应用系统的LB前端地址，经过负载均衡转发至应用前端服务器，前端服务器对数据库和后端API的请求由内网LB进行负载转发

· 使用AWS监控服务CloudWatch进行性能级别监控

应用业务架构主要说明

· 业务主要分为四大板块，主要是以xxP应用、mend、xxP-Search和xxxbox

·xxP-web是用户访问门户入口，提供全球各地的SSO单点登录访问，前端初期建设6台EC2组成业务前端集群，并分布于不同的可用区，后续考虑使用Auto-Scaling进行弹性扩缩容

· xxP后端提供API接口，前端通过内部LB进行后端负载均衡访问，数据库存储用户数据和业务数据，分布在不同的逻辑库中

· xxP-Search提供用户倾向分析推荐，分析用户习惯进行定向引流。前端Ec2进行业务访问需求，并进行用户行为分析和数据收集。将处理过的数据存储到数据库存储。

· xxP-Search数据库进行多可用区主备容灾架构，确保数据的安全性、可用性和可靠性

· xxP-Search提供资源搜索引擎，EC2承载数据引擎大模型算法，数据存储于数据库。访问使用LB复杂均衡，流量接入计算节点

· xxxbox提供电商运营管理后台，前端Web提供后台运营访问入口，运营数据和平台数据存储在数据库中。按需生成数据报表和运营数据，以供决策分析

迁移工具选型

根据AWS架构完善框架和最佳实践迁移方案 采用AWS Application Migration Service服务对应用进行迁移。

AWS Application Migration Service通过自动将您的源服务器从物理、虚拟或云基础设施转换为在 AWS 上本机运行，最大限度地减少费时、容易出错的手动流程。

它使您能够在各种不同的应用程序中使用相同的自动化流程，从而进一步简化迁移。

AWS Application Migration Service迁移架构图

云主机迁移规划方案

通过 aws application migration service 工具迁移到 aws，然后制作对应的镜像，通过控制台或API初始化服务，在初始化过程中配置如下服务：

· 创建所需的IAM角色和策略

· 配置所需的模板

IAM角色创建

在初始化期间，将自动创建以下IAM角色

· 应用迁移服务角色

· 应用程序

· 应用程序迁移

· LaunchInstanceWithDrsrole

· LaunchInstanceWithSsmrole

· 应用程序迁移代理角色

IAM角色的权限

配置模版

必须首先创建一个复制模板。

复制模板确定数据复制在添加的每个新服务器上的工作方式。

此模板中配置的设置将应用于每个新添加的源服务器。

创建模板如下图为例：

‍‍‍

迁移主机至AWS

通过以下三种方式进行云主机迁移：

· 在源服务器上安装复制代理

· 在您的数据中心安装 MGN 连接器，然后使用该连接器在您的清单中安装复制代理

· 在您的 vCenter 中安装设备，然后激活无代理复制

‍‍‍

推荐在源端服务器安装Agent的方式进行主机迁移

以下图为例：

‍‍‍

执行成功后，aws的控制台就会显示，迁移服务器的同步进度：

‍‍‍

可用性测试

在 EC2 中测试迁移至AWS的云主机实例，以验证您的应用程序按预期运行。

启动后操作将自动激活。

‍‍‍

对迁移至AWS的主机进行以下维度测试：

· 数据一致性测试

· 应用程序可用性测试

· 完整性测试

通过测试，进行业务切换阶段。

数据库迁移规划方案

迁移概述

· **AWS Database Migration Service (AWS DMS)**是一项云服务，可轻松迁移关系数据库、数据仓库、NoSQL 数据库及其他类型的数据存储。

您可以使用 AWS DMS 将数据迁移到 AWS 云，在本地实例之间（通过 AWS 云设置）进行迁移，或者在云与本地设置的组合之间进行迁移。

· 利用 AWS DMS，可以执行一次性迁移，而且可以复制持续更改以保持源和目标同步。‍

如果要更改数据库引擎，可以使用 AWS Schema Conversion Tool (AWS SCT) 将数据库架构转移到新平台。

然后，可以使用 AWS DMS 迁移数据。由于 AWS DMS 是 AWS 云的一部分，您将获得 AWS 服务提供的成本效益、上市速度、安全性与灵活性。

· DMS通过复制实例，配置源和目标终端节点以及复制任务，可在一站式界面管理帮助客户实现数据库迁移。

在数据库的迁移过程中，我们也发现了以下几个问题：

· 任务分解导致网络带宽占满

· 不支持断点续传

· 数据校验缺少灵活性

为此，依托DMS作为数据库迁移的主基础上，也借助开源工具mydumper/myloader和sync-diff-inspector，并结合DMS解决MySQL同构数据库迁移中需要解决的一系列问题。

AWS DMS迁移3种模式：

· f ull load 完全加载，需要停机，等待源数据库将数据加载到目标数据库。

· full load+CDC 完全加载+持续更新，先完全把源数据库中数据加载到目标数据库，在加载过程中出现的数据更新缓存到复制实例的内存中，也可能会保存到复制实例的磁盘中。

· Only CDC 同构数据库中采用原厂自带的迁移备份工具，仅迁移时间节点之后的更新，采用CDC同步到目标库中。

‍‍‍

实施迁移流程：

· 配置系统架构

· 资源配置（DMS复制实例，DMS源和目标节点，EC2复制实例，RDS/Aurora MySQL）

· 源和目标端网络配置（VPC，子网，Direct Connect/VPN，安全组）

· 数据库配置（源数据库主从配置，目标端数据库参数配置等）

· 源和目标端所需MySQL用户权限

· 数据库全备

· 全量导出检查

· 全量导入和数据一致性校验

· 配置DMS迁移任务开始节点同步数据

· 打开CloudWatch监控

项目中涉及文档数据库，由于AWS 香港region暂时不支持托管DocumentDB，本次采用自建MongoDB进行部署，部署三节点一主两从模式。

后续优化推荐客户将文档型数据库存储到AWS DynamoDB中。原架构中在阿里云也是自建MongoDB方式部署，使用三节点，一主两从模式。

本次复制采用MongoDB主从复制功能，在AWS架构中创建三个从节点，通过vpn链路数据库主从复制机制将数据完成同步到AWS直到切换结束。

数据引擎选型

AWS提供了托管基于MySQL，Oracle，PostgreSQL等关系型数据库服务，支持原先基于这些数据库的数据快速迁移到云上。

同时，AWS还提供了云原生关系型数据Aurora，兼容MySQL和PostgreSQL协议，为用户直接上云提供了更多了选择。

传统数据库遇到的问题

Amazon在日常开发和维护中发现，计算能力和存储性能已经不再是其工作的瓶颈了，取而代之的是网络的流量。

其实对于Amazon来说，只要有钱，CPU能用最好的就能解决计算能力的问题，机械硬盘不够用固态硬盘，固态硬盘不够就上内存，存储性能也解决了，但是网络的延迟靠大带宽是很难解决的，而拉近机房位置也是有上限的，必须要从业务逻辑和服务组件上找问题。

所以他们发现了MySQL在分布式系统中消耗了大量的流量，还提高了延迟。

具体如下图所示

‍‍‍

计算和存储分离

Aurora用WAL也就是Log来整合所有有用的信息并删去无用的信息，既减少了数据传输量又保证了需要保留的信息。

同时，他们使用了链式复制结构代替主从结构，简化了保证数据一致性的复杂度。

具体架构如下图所示

‍‍‍

以三个副本为例，当位于AZ1的主节点收到写请求后，它将请求的相关数据直接写入六个存储节点中，然后，将数据和一些额外的信息通过链式复制结构传递给位于AZ2和AZ3其他节点。

和上图进行对比，明显可以看到主从节点之间网络通信中传输的数据减少了，主节点向存储节点写入数据时也从五种数据变为一种。

这里要特别指出的是，此处的数据已经从MySQ定义的Log变为Amazon为Aurora量身定制的Log。

由于需要传输数据量的减少，同步所消耗的网络带宽也大幅地减少了。

另外，因为主节点负责将Log写入存储节点，而从节点仅存储Log不需要负责写入存储节点，这样就减少了在MySQL中额外的第四步和第五步操作的时间。

而MySQL中的两级EBS存储操作也由一级Quorum的代替，就像上一篇文章提到的，两级存储的时间是两次操作的时间之和，而一级的Quorum操作的时间则是取决于Quorum中最长的应答时间。

这样，Aurora也优化了应答延迟的时间。

基础设施的设计

**· VPC设计：**生产环境VPC用于容纳生产环境，开发和测试VPC独立于生产环境VPC

**· 子网设计：**根据安全分区要求，分为公有子网、私有子网、DB子网；公共子网（DMZ）部署面向公网访问服务器，VPC、NAT Gateway、堡垒机和ELB等；私有子网（External）部署只允许通过NAT Gateway访问外网的应用服务器；私有子网（Internal）部署只允许内部访问且无外网访问需求的服务

**· 资源选型设计：**实例类型、操作系统、EBS类型、IOPS

**· IAM：**研发、运维、管理等部门创建IAM用户和用户组，遵循最小权限策略赋予对应的权限；开启强制设置MFA多因子认证

**· 定义NACL：**控制所有子网层面的进出流量

**· 定义安全组：**控制所有实例层面的进出流量

· 开启CloudTrail记录资源的操作记录，可追溯性

安全组规划设计

安全组充当实例的虚拟防火墙以控制入站和出站流量。

当客户在 VPC 内中启动实例时，可以为该实例指定最多五个 VPC 安全组。

安全组在实例级别运行，而不是子网级别。因此，在 VPC 的子网中的每项实例都归属于不同的安全组集合。如果在启动时没有指定具体的安全组，实例会自动归属到 VPC 的默认安全组。

对于每个安全组，可以添加规则以控制到实例的入站数据流，以及另外一套单独规则以控制出站数据流。

此部分描述了需要了解的有关 VPC 安全组的基本信息以及它们的规则。

下面列出了在AWS中安全组的最佳实践：

· 不要在"默认"安全组中添加规则，应保证并锁定对入站和出站流量的默认最严格控制

· 面向外部网络的安全组应配置最严格受限的端口，仅按需开放端口

· 尽可能在应用堆栈中使用可参考的安全组避免源中包含过多实例，当源超过100时使用CIDR

· 使用不同的安全组区分不同类型的流量，例如应用流量和管理流量

· 所有安全组加总的规则应该少于50条，如果多余50条，分析原因并进行汇总

· 清楚不使用的安全组，因为他们会被计算在账户限制以内

· 使用AWS Config或CloudTrail监控安全组变更，跟踪变更内容及发起者

· 定期检查安全组是否符合定义的标准，在需要时设置告警或安排清除

· 限制能够更改和能够指定安全组的人员，以防火墙方式操作‍

1. 前端ELB安全组规划设计

|------|-----|-----------|----------------------------|
| 协议类型 | 端口 | 源 IP | 备注 |
| TCP | xxx | 0.0.0.0/0 | 允许来自任何 IPv4 地址的入站 HTTP 访问。 |
| TCP | xxx | 0.0.0.0/0 | 允许来自任何 IPv4 地址的入站 HTTPS 访问 |
| TCP | xxx | 0.0.0.0/0 | 允许来自0.0.0.0/0安全组的实例访问。 |

2. 应用安全组规划设计

|------|-----|------|-----------------|
| 协议类型 | 端口 | 源 IP | 备注 |
| TCP | xxx | 内网 | 允许来自内网安全组的实例访问。 |
| TCP | xxx | 内网 | 仅允许来自堡垒机的访问 |

3.数据库安全组规划设计

|------|-----|------|-------------------|
| 协议类型 | 端口 | 源 IP | 备注 |
| TCP | xxx | 指定应用 | 允许来自指定应用安全组的实例访问。 |

IAM账号权限设计

使用IAM时，可通过创建策略向IAM用户、组和角色（我们称为委托人实体）应用权限。

您可以创建两种类型的 IAM，或基于身份的策略：托管策略和内联策略。

传统企业一般会将人员分为如下几类：网络安全、研发（传统研发，不具有云上操作权限）、系统运维、DBA、审计、超级管理员。

利用IAM组，可为不同类的用户指定权限，以便更轻松地管理这些用户的权限。

IAM组设计可以以AWS托管策略为基准模板进行调整，具体建议如下:

|---------|-----------------------|---------|
| IAM组名 | IAM策略名称 | 描述说明 |
| OPS | SystemAdministrator | 系统运维人员组 |
| Network | NetworkAdministrator | 网络安全人员组 |
| DBA | DatabaseAdministrator | 数据库管理员组 |
| Develop | ViewOnlyAccess | 研发人员组 |
| Audit | SecurityAudit | 安全审计人员组 |
| Admin | AdministratorAccess | 超级管理员 |

|------|------------------|-------------|
| OPS |||
| 策略名称 | SystemAdministrator ||
| 策略描述 | 此策略授予在各种 AWS 服务之间创建和维护资源的权限，设置和维护用于开发操作的资源。 ||
| 权限概览 | CloudTrail | 读取，配置日志记录 |
| 权限概览 | CloudWatch | 完全访问权 |
| 权限概览 | Config | 完全访问权 |
| 权限概览 | EC2、Auto Scaling | 读取，实例创建维护相关 |
| 权限概览 | ELB、ELB V2 | 完全访问权 |
| 权限概览 | IAM | 读取，PassRole |
| 权限概览 | RDS | 读取 |
| 权限概览 | SNS、SQS、S3 | 完全访问权 |

|------|----------------|-------------------|
| Network |||
| 策略名称 | NetworkAdministrator ||
| 策略描述 | 此策略授予创建和维护网络资源的权限 ||
| 权限概览 | EC2 | VPC网络操作 |
| 权限概览 | ELB/ELB V2 | 完全访问权 |
| 权限概览 | CloudWatch | 指标读写 |
| 权限概览 | Direct Connect | 完全访问权 |
| 权限概览 | IAM | 角色传递：flow-logs-* |

|------|-----------------|-----------|
| DBA |||
| 策略名称 | DatabaseAdministrator ||
| 策略描述 | 此策略授予创建、配置和维护数据库的权限。其中包括对 AWS 数据库服务（如 Amazon DynamoDB、Amazon Relational Database Service (RDS) 和 Amazon Redshift）的访问权限。 ||
| 权限概览 | DynamoDB | 完全访问权 |
| 权限概览 | ElastiCache | 完全访问权 |
| 权限概览 | RDS | 完全访问权 |
| 权限概览 | Redshift | 完全访问权 |
| 权限概览 | CloudWatch | 指标读写 |
| 权限概览 | CloudWatch Logs | 日志流相关操作 |
| 权限概览 | S3 | 读取、创建桶和对象 |
| 权限概览 | SNS | 创建、订阅主题 |

|------|----------|----|
| Develop |||
| 策略名称 | ViewOnlyAccess ||
| 策略描述 | 此策略授予针对大多数 AWS 服务的资源的 List*、Describe*、Get*、View* 和 Lookup* 访问权限 ||
| 权限概览 | AWS服务和资源 | 读取 |

|------|-----------------|--------|
| Audit |||
| 策略名称 | SecurityAudit ||
| 策略描述 | 此策略授予查看多项 AWS 服务的配置数据并检查其日志的权限。 ||
| 权限概览 | CloudTrail | 读取 |
| 权限概览 | CloudWatch Logs | 读取 |
| 权限概览 | Config | 读取，合规性 |
| 权限概览 | 其他资源 | 读取 |

IAM角色策略设计

IAM角色是在AWS中管理AWS资源的最佳实践，但对于传统应用或开发模型存在一定限制导致不一定适用。

IAM角色类似于用户，因为它是一个 AWS 实体，该实体具有确定其在 AWS 中可执行和不可执行的操作的权限策略。

但是，角色旨在让需要它的任何人代入，而不是唯一地与某个人员关联。

此外，角色没有任何关联的凭证（密码或访问密钥）。

相反，如果将某个用户分配给角色，则将动态创建访问密钥并将该密钥提供给用户。

更多信息请参考：

云原生的应用能够并推荐使用IAM角色管理保存在EC2实例上的临时凭证。

当使用IAM角色时，用户不必在实例上长期保存密钥，而是使用可以对其他资源进行操作的临时许可。

当启动一台实例时，可以为其指定一个IAM角色，运行在该实例中的应用可以使用此角色定义的权限所提供的临时授权进行API请求等操作。

账户安全设计

**· Root帐号管理:**客户拥有root账号，并已为其设置MFA。Root账号仅用于创建IAM管理员组并指派相关的IAM User到IAM管理员组

· IAM管理员用户组等关键用户组设定多因子MFA登录认证

· 按照企业安全要求设定密码规则基线

· 定期更换密钥，可以通过AWS控制台配置密钥自动或手动轮换

· 对于第三方软件供应商/服务商，客户有独立管理需要的部门，均建议构建临时的IAM account，或通过Role进行跨IAM account的账号授权。

· 人员权限遵循最小权限原则。

· 定期清理不用的组、用户、角色、策略等

Landing Zone标签体系设计

Amazon Web Services（AWS）允许客户以标签的形式向其AWS资源分配元数据。

每个标记都是一个简单的标签，由一个客户定义的键和一个可选的值组成，这些值可以使管理、搜索和筛选资源更加容易。

尽管没有固有的标记类型，但它们使客户能够按用途、所有者、环境或其他标准对资源进行分类。

本节介绍了常用的标签类别和策略，以帮助AWS客户实施一致和有效的标签策略。

以下各节假设对AWS资源、标签、详细计费以及AWS身份和访问管理（IAM）有基本的了解。

为AWS资源创建标记策略时，请确保它准确地表示组织相关的维度，并遵循以下标记最佳实践：

· 始终使用标准化的、区分大小写的标记格式，并在所有资源类型中一致地实现它。

· 考虑支持管理资源访问控制、成本跟踪、自动化和组织能力的标记维度。

· 实施自动化工具以帮助管理资源标签。资源组标记API支持对标记的编程控制，使自动管理、搜索和筛选标记和资源更加容易。它还通过每个AWS区域的单个API调用简化了跨所有支持的服务的标记数据备份。

· 错误在于使用太多标签而不是太少标签。

最有效地使用标签的公司通常创建与业务相关的标签分组，以沿技术、业务和安全维度组织资源。

使用自动化流程管理其基础架构的公司还包括其他特定于自动化的标签，以帮助其自动化工作。

技术标签设计规范

**· 名称-**用于标识单个资源

**· 应用程序ID-**用于标识与特定应用程序相关的不同资源

**· 应用程序角色-**用于描述特定资源（如Web服务器、消息代理、数据库）的功能

**· 群集-**用于标识共享公共配置并为应用程序执行特定功能的资源场

**· 环境-**用于区分开发、测试和生产基础设施

**· 版本-**用于帮助区分资源或应用程序的不同版本

自动化标签设计规范

**· 日期/时间-**用于标识资源应开始、停止、删除或旋转的日期或时间

**· Opt-in / opt-out-**用于指示资源是否应自动包含在自动活动中，如启动、停止或调整实例大小

**· 安全性-**用于确定要求，如加密或启用vpc流日志，还用于确定需要额外检查的路由表或安全组

业务标签设计规范

**· 所有者-**用于确定谁负责资源

**· 成本中心/业务部门-**用于标识与资源关联的成本中心或业务部门；通常用于成本分配和跟踪

**· 客户-**用于识别特定资源组服务的特定客户

**· 项目-**用于确定资源支持的项目

安全标签设计规范

**· 机密性-**特定数据机密性级别A资源支持的标识符

**· 合规性-**用于符合特定合规性要求的工作负载的标识符

监控CloudWatch规范方案

跨操作系统从 Amazon EC2 实例中收集更多系统级指标。

除了 EC2 实例的指标之外，这些指标还可以包括来宾中的指标从本地服务器中收集系统级别指标。

这些服务器可能包括混合环境中的服务器以及不是由 AWS 管理的服务器使用 StatsD 和 collectd 协议从应用程序或服务中检索自定义指标。

StatsD 在 Linux 服务器和运行 Windows Server 的服务器上都受支持。collectd 仅在 Linux 服务器上受支持。

从运行 Linux 或 Windows Server 的 Amazon EC2 实例和本地服务器收集日志可以在 CloudWatch 中存储和查看使用 CloudWatch 代理收集的指标，就像任何其他 CloudWatch 指标一样。

CloudWatch 代理收集的指标的默认命名空间为 CWAgent，但可以在配置该代理时指定不同的命名空间。

下载安装CloudWatch代理

|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 使用 S3 下载链接下载 CloudWatch 代理软件包 Centos: https://s3.amazonaws.com/amazoncloudwatch-agent/centos/amd64/latest/amazon-cloudwatch-agent.rpm Windows: https://s3.amazonaws.com/amazoncloudwatch-agent/windows/amd64/latest/amazon-cloudwatch-agent.msi 其他系统的安装包参见AWS CloudWatch用户指南中的对应链接下载。 |

创建IAM角色和用户以用于CloudWatch代理

要访问AWS资源，需要具有相应的权限。创建IAM角色或IAM用户，以授予CloudWatch代理将指标写入CloudWatch所需的权限。如果打算在AmazonEC2实例上使用代理，则必须创建IAM角色。如果打算在本地服务器上使用代理，则必须创建IAM用户。

具体步骤如下：

登录AWS管理控制台并通过以下网址打开IAM控制，在左侧的导航窗格中，选择Roles(角色)，然后选择Create role(创建角色)
对于Choose the service that will use this role(选择将使用此角色的服务)，选择EC2 Allows EC2 instances to call AWS services on your behalf(EC2允许EC2实例代表调用AWS服务)。选择Next: Permissions(下一步：权限)
在策略列表中，选中CloudWatchAgentServerPolicy旁边的复选框。如有必要，请使用搜索框查找该策略。选择完成后下一步
确认Policies(策略)旁边显示CloudWatchAgentServerPolicy。在Role name(角色名称)中，输入角色的名称，例如CloudWatchAgentServerRole。(可选）为其指定说明。然后选择Create role(创建角色)，将立即创建该角色
查看IAM角色
在服务器上安装和运行CloudWatch代理
监控指标收集