把网站迁移到亚马逊云会遇到什么问题?系统迁移到亚马逊云平台,踩了很多坑,收获也很多。因为系统的迁移涉及到各种常见的架构组件,所以有很多细节的棱角。和大多数制度一样,长时间的野蛮生长积累了很多问题。将这样一个旧系统迁移到一个新的平台上,意味着你需要处理所有之前埋下的问题。之前公司聘请了亚马逊推荐的第三方咨询服务来做迁移,但是因为问题太多,拖了很久。
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.降低运维难度,无需运维:系统会根据负载自动增减机器,不用担心压坏机器,单机各种故障也不用人工处理。
亚马逊云平台的特性和组件将在以后的单独文章中详细解释。
评论前必须登录!
注册