公有云(AWS)上的生产环境架构优化案例和迁移套路

本文是我在 gitchat 上的文章云计算生产环境架构性能调优和迁移套路总结（以 AWS 为例）的后半部分，本文对原文有所修改和总结。交流实录请点击这里。

在AWS 上的生产环境性能分析案例一文中，记录了我对客户应用生产环境的一次性能分析。接下来，我们要根据所发现的性能问题进行架构优化，以提升可用性和性能。同时，这篇文章也总结了应用迁移到云上的套路。

设计云计算平台迁移计划和方案

将应用程序迁移到云计算平台上主要的目的是把自行构建的高风险高成本应用以及组件替换为云计算平台上的高可靠性低成本组件/服务。

应用架构的迁移有两种方案：

一种是整体一次性迁移，即重新实现一个架构并完成部署，然后通过金丝雀发布或者蓝绿发布切换。这种方式的好处�是简单，直接，有效，一开始就能按照最佳实践构建应用架构。而且对于现有系统来说影响不大。但如果方案没设计好，容易造成高级别的风险，所以应当进行大量的测试以确保可靠性。

另一种是持续部分迁移，每次引入一点风险，保证风险可控，但缺点就是优化步骤较多。虽然持续部分迁移步骤多，但是总体时间并不一定会比整体迁移更高。

注意：由于自动化基础设施和架构设计会带来一些副作用，特别是配置间的耦合。因此，对于生产环境的直接优化要慎用自动化。如果一定要用，请务必在测试环境上做好测试。但如果你能做到自动化并且有完好的测试，不如直接做整体一次性迁移方案得了。

一般说来，一个完整的云平台迁移方案会分为以下三大阶段：

第一阶段：构建高可用架构以实施水平扩展，从而保证了应用的稳定运行。

第二阶段：引入 APM 并根据 APM 数据进行定向优化，采用云计算的服务来优化应用的资源使用。

第三阶段：构建应用端的持续部署，构建 DevOps 的工作模式。

这三个阶段是大的顺序，而每个大的阶段里又会相互掺杂一些其它阶段的内容。但无论什么样的迁移方案，一定要通过度量进行风险/收益比排序，最先完成代价最小，收益最大的内容。

第一阶段：构建高可用架构

我们之前说过，一个应用架构的第一追求就是业务的连续性和抗风险能力。一个高可用的架构能够在你的应用面对压力的时候从容不迫。因为如果资源满负荷运转，新的请求会因为没有可用资源而导致排队。这是常见的停机或者性能降低的原因。这就是 AFK 扩展矩阵常说的 X 轴扩展：通过复制自己扩展资源从而达到降低排队等待的时间。 此外，水平扩展出来的机器同样也是一个预留资源，能够提高应用的可用性。应用架构不仅仅是应用程序的事情，也包含着资源的分配，二者是相辅相成的。

一般会经历如下几步：

第一步，有状态和无状态分离

第二步，牲畜化（Cattlize）应用实例

第三步，自动化水平扩展（AutoScaling）

第一步：有状态和无状态分离

先回顾一下当前应用的架构 ：

当前应用架构

状态分离的目标是把有状态的组件和无状态的组件分开，以便在做复制的时候降低不一致性。最简单的判定办法是：如果复制当前的虚拟资源，并通过负载均衡随机分配请求访问，哪些部分会造成不一致。

常见的有状态内容比如数据库，上传的文件。所以，我们要把它们独立出来。在“萨瓦迪卡”的例子中，我们首先把数据库独立了出来。如下图所示：

数据库分离

在这个过程中，我们采用 RDS 而不是另外一个 EC2 上构建一套 MySQL 来完成数据库的分离。最主要的原因就是 RDS 提供了更好的可用性和数据库维护支持，例如自动