将成本降低90%，并将网站迁移到亚马逊云

把网站迁移到亚马逊云会遇到什么问题？系统迁移到亚马逊云平台，踩了很多坑，收获也很多。因为系统的迁移涉及到各种常见的架构组件，所以有很多细节的棱角。和大多数制度一样，长时间的野蛮生长积累了很多问题。将这样一个旧系统迁移到一个新的平台上，意味着你需要处理所有之前埋下的问题。之前公司聘请了亚马逊推荐的第三方咨询服务来做迁移，但是因为问题太多，拖了很久。

1.亚马逊成熟老系统网站迁移常见问题:

1.
缺少文档:这应该是大公司和小公司的问题。文档化会大大降低开发效率，而互联网项目的特点是多变性和速度，所以详细的文档化并不是一个好的解决方案。这就要求方案和细节的设计要合理，不能做。
“精致”的方案。结构化的设计，而不是分散的组件，这样别人即使没有文档也能理解。

2.
项目中临时方案太多:看起来别扭，后期难以理解；半个项目。系统中有很多“精致”的设计，让后来者很难理解。这也告诉我们，设计要尽量简单易懂，项目设计的沟通也是很重要的一个方面。一位工程师说他花了
花了一个星期才弄清楚Postfix的邮件接收和自动解析过程是如何工作的。

3.代码质量参差不齐:每个大团队都不能保证代码质量问题，所以保持代码库的整洁很重要。

4.复杂的业务

5.代码的缺陷和代码与环境的兼容性

在以前的系统中，配置文件是读写分离的，配置文件由其他系统控制。但是配置文件保证留在代码库中，这意味着如果代码被回滚或检查
如果支出是错误的，配置文件将改变。不该发生的全体会议发生了，这样的事情确实发生了。有些操作写到从库，从库和主库同步失败，这就是典型的裂脑问题。最后，从库中重做同步需要很长时间。这种问题处理并不复杂，而是如何找到这个问题的原因。因为商家奇怪的表现，有时候很难想到问题的根源。

二。网站迁移到亚马逊过程中需要考虑的问题:

1.
完善:性能测试可以采用交通镜像复制。阅读有很多简单可靠的流量文案工具，有时候根本不需要高大上的流量文案系统。而且大部分系统读的多，写的少，所以测试不是什么难事。

功能测试只能尽量做，熟悉系统的用户才能做。

2.无缝迁移:整个过程基本实现了平滑无缝迁移，系统没有停止运行1分钟。由于项目的特点，写作操作较少，重点是阅读。写操作暂停后，将被HaProxy。
一步一步，后端指向新的集群，在所有流量导入新的集群后，修改DNS以指向新的集群。还涉及到DNS TTL从长到短再到长的修改过程。

缓存的预热非常重要，尤其是数据库，需要逐步导入新的集群流量，防止对全站时延的影响。

3.回滚方案:由于写操作暂时停止，即使流量导入到新集群，测试中发现问题，仍然可以指向回旧集群。

4.改进或者保持现状:由于架构组件选择面广，需要很长时间才能让之前的组件配置合理。
回顾.这里我们要权衡是保持原样还是立刻优化。更好的解决方案是，如果不是BUG就保持原样，等系统迁移后再改进。

5.性能的持续监控和对比测试:性能监控工具已经非常成熟，比如AppNeta和New Relic。
你基本上可以控制每个组件的性能。在迁移之前，镜像流量复制还可用于比较和测试新旧集群的性能。

3.网站迁移到亚马逊有什么好处？

1.重新设计的发布自动化:业务代码、系统配置和云架构配置的分离，以及任何操作的版本化，可以回滚。

2.弹性扩张和整体成本降低:迁移到亚马逊的主要原因是高峰和低谷流量的巨大差异。低峰期迁移后，机器成本可节省1.5倍。

3.跨区域容灾，无单点故障:实现多AZ，任何单点故障不影响业务运营。网
前端服务器可以随意关闭，数据库升级和配置更改没有影响。当然这要归功于RDS多AZ功能。

4.降低运维难度，无需运维:系统会根据负载自动增减机器，不用担心压坏机器，单机各种故障也不用人工处理。

亚马逊云平台的特性和组件将在以后的单独文章中详细解释。