云迁移的那些事
我们的CIO乐乐同学摊上事儿了,摊上大事了!在公司做出了更换公有云服务商的决定后,技术部就开始精心为这次云迁移做准备。这并不是我们第一次做云迁移,技术部也做足了功课,但在公有云的迁移过程中捅出了“篓子”,一时间连发布系统都无法正常使用。为什么要做这次云迁移,乐乐同学在云迁移的过程中遇到了什么?下面就让我们来好好复盘一下吧。
云迁移前的系统重构
首先,让我们来看一下乐乐同学他们在运迁移之前做了一些什么样的工作:
乐乐:在云迁移之前,技术部先做了一件大事,将至顶网已经使用了十多年的业务系统整个进行了重构。
重构的原因很现实,十多年的应用积累,已经让业务系统变得十分臃肿而庞杂。很多早已不再使用的应用和数据,就像一堆乱麻,不但没有用,还成为了病毒和木马的温床,还有很多因底层系统老旧而存留的安全漏洞,也在时常威胁着系统的可靠应用。与其修修补补的将就过日子,还不如干脆推翻重建。重新打造一个系统成熟度更高、操作更加便捷、更加适合PC端与移动端多平台业务应用的全新系统。
经过技术部全体同仁几个月的努力,具备安全用户登录、更新底层系统架构、对数据库进行大幅精减的全新业务系统,在进行一段时间试运行之后,正式替换了旧版业务系统工作。
全新业务系统上线后,不出所料的“差评不断”。毕竟大家对新事物需要有一个熟悉适应的过程。在经过一系列小规模功能调整之后,业务系统总算是可以稳定运行了。
系统更新告一段落,云迁移也就正式提上了日程。
为了更好的业务体验
当向乐乐同学寻问,为什么最终选择UCloud的时候,乐乐同学义正言辞的回答:“为了更好的业务体验。”
追问一句:”真的是这样吗?”
乐乐回复:“当然使用成本也是我们需要考虑的很重要因素。”
再追问:“所以就掉坑里了吧~~”(阴险)
乐乐:“是……”
“当然,也不能算是完全掉到了坑里,每一次进行公有云迁移,肯定会出现一些不同的问题,必然会有一个发现问题、解决问题的过程。”随后,乐乐同学将这次迁移过程中所发生的问题和解决过程给我们进行了介绍。
至顶网是国内最早一批将自身业务向公有云迁移的IT媒体。在至顶网搞技术的同学始终都保持着一种“生命不熄,折腾不止”的钻研精神(bing)。在公司领导“不试一下,怎么知道好坏”的大力支持下,这已经是第二次进行公有云迁移了。在公有云迁移之前,我们也曾经进行过两轮公有云评测活动。从测试成绩上看,UCloud是完全可以满足至顶网的业务应用需求的,同时在采购成本上还有很好的优势,于是经过慎重考虑(kanjia)之后,还是选定了向UClould进行迁移。
在经历一个半月的准备工作之后,云迁移工作正式开始。之所以需要经历这么长的准备时间,一方面是因为需要对当前正在应用的整个业务系统进行重构,另一方面是对新的公有云架构进行适配。系统重构的情况,在上一段已经介绍过了,下面就具体说一下在迁云过程中所遇到的问题。
迁移的IP配置问题
当询问起迁云过程中所遇到的困难时,乐乐同学的回答是:“IP配置和负载均衡”。
云上业务的正常应用,需要依靠不同云主机来进行支持,应用寻找云主机需要依靠的就是IP地址。业务系统在原公有云上已经定义的体系架构需要平移到新的公有云上,内部系统架构最好是能不变就不变,但问题还是出现了,UCloud的云主机IP无法自动适配我们的系统架构。
至顶网在云上的业务系统规模虽然称不上是庞大,但依靠运维人员手工去对每一台云主机进行区域、配置、镜像等等十几选项一一进行设置,这肯定是不现实的,最后导致在业务上线时,云主机IP与系统内部定义的IP不匹配,系统找不到云主机,业务自然也无法进行应用。最后只能与UCloud技术团队协商,在后台将所有内网IP重新定义,并与系统IP保持一致,才解决了这一问题。看来公有云主机IP的批量定义,自动切换功能也是在公有云选择过程中,需要慎重考虑的一个功能要点。
负载均衡:意料之外的问题
业务系统部署好了之后,还需要将用户请求有效的分配给不同服务器执行,这就需要使用负载均衡。UCloud可以提供基于报文转发和代理模式的负载均衡功能,但是这两种负载均衡应用到我们的业务系统时都存在一些不足。代理模式转发除有限端口外,其它端口访问时,无法获取到准确的外网IP地址,有来无回。报文转发模式虽然没有这个问题,但是需要对虚拟网卡进行重新定义。这些问题最终都可以解决,但是在未定位到问题的故障点之前,就只能是盲人摸象了。
另外,在我们寻求UCloud的技术支持与帮助文档也遇到了挑战。在遇到问题时,技术支持只是简单的发来一些帮助文档,但这些文档并不健全,并不能协助用户有效的找到问题,这也是一个需要改善的地方。
技术支持文档的不健全还会引发一个潜在问题,就是学习成本过高。用户在使用公有云的时候,需要经过一段时间熟悉才能顺利上手,但遇到突发问题时,是没有让用户熟悉的时间的,这样搞不好整个业务线已经挂了。
小结
回头看这次云迁移,乐乐表示,UCloud确实还存在一些功能不完善的地方,但是从用户业务请求响应的角度来讲,UCloud还是比较令人满意的。比如,我们的要求是在半秒钟内对用户的请求进行响应,而UCloud在300毫秒内就可以提供响应,这个是超过我们的预期的。而且在域名备案上,UCloud全部都是在线上进行操作,不需要进行资料邮寄,极大缩短了整个备案工作时长,包括审核周期基本上在十几个工作日左右就可以完成,效率比以前有了近乎一倍的提升,大大缩短业务上线时间。
而应用功能上的缺陷实际上哪个云上都有,只不过有一些云使用的用户多,早被发现、早被完善而已。而且使用用户多、功能完善的公有云,它的使用成本可能也高。这一切都需要去综合的进行考虑。
从这次至顶网在公有云迁移中发生的问题可以看出,问题主要出在以云主机搭建的系统在不同公有云的配合方面。而近期笔者正在研究的容器可以比较好地避免这样的问题发生。看来还需要再好好“忽悠忽悠”乐乐同学,让他什么时候再来完成一次公有云向容器的迁移。
敬请大家期待!
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
OpenJDK 从 Mercurial 迁移到 GitHub
OpenJDK 项目正在从 Mercurial 迁移到 GitHub,预计在2020年9月完成。切换至 Git 代码版本控制系统的部分预期目的是提升性能和对代码审查的更好支持。 OpenJDK 从 2008 年起一直使用 Mercurial 作为源代码管理解决方案,用于存储代码并进行代码审查。如今部分 OpenJDK 项目(如 Loom、Valhalla 和 JMC)已完全从Mercurial迁移至GitHub,还有部分项目例如 JDK 本身正在迁移中,对于这些项目,其仓库已托管在 GitHub 上,但目前仍是只读副本。到 9 月份 GitHub 成为正式的读写主仓库时,JDK 项目将加入其中。 OpenJDK 在 2018 年开始评估 Mercurial 在源代码管理方面的可能替代方案,当时还定义了一系列评估标准,宗旨是“提升所有贡献者(无论是新贡献者还是现有贡献者)的生产力”: 性能:从主仓库进行克隆操作的时间、本地操作的时间等 空间效率 在不同地区的可用性 支持常见的开发环境,例如Linux, Mac 和 Windows 能够轻松托管JDK 的整个历史项目文件和未来十年基于其历史...
- 下一篇
AI +边缘计算——边缘人工智能真的存在吗?
EdgeAI不再处于蓝图阶段。它已经进入主流应用,并且以惊人的速度增长,但是EdgeAI到底是什么呢? Edge受到全球企业的喜爱,作为一种新时代的感应技术,它具有巨大的实时观察用户的能力,以获得更多的意识,采取智能有力的行动。有争议的问题仍然存在,边缘人工智能真的存在吗?专家说,是的!例如,带上您的智能手机,只需注册并识别您的脸部,它就能在几秒钟内解锁您的手机。自动驾驶汽车是另一个复杂的例子,其中汽车无需任何人工干预即可自行驾驶。数据就在您的汽车或手机中,没有时间将这些数据发送到云中并等待见解。 行业中的边缘人工智能 无论是在企业层面还是在个人层面,我们都在使用EdgeAI的许多其他实例。从提醒你交通状况的谷歌地图到语音再到文本算法,智能人工智能无处不在。EdgeAI拥有巨大的潜力,根据Itractica的一份报告,到2025年,AIEdge设备出货量将从2018年的1.614亿台增加到26亿台。流行的人工智能支持的边缘设备包括头盔显示器、智能扬声器、手机、PC/平板电脑、汽车传感器、机器人、安全摄像头和无人机。此外,可穿戴健康传感器将具有很高的可采用率。 EdgeAI最有可能使包括...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Hadoop3单机部署,实现最简伪集群
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- 设置Eclipse缩进为4个空格,增强代码规范
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- Windows10,CentOS7,CentOS8安装Nodejs环境
- CentOS7设置SWAP分区,小内存服务器的救世主
- CentOS关闭SELinux安全模块
- SpringBoot2更换Tomcat为Jetty,小型站点的福音