我们的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全部都是在线上进行操作，不需要进行资料邮寄，极大缩短了整个备案工作时长，包括审核周期基本上在十几个工作日左右就可以完成，效率比以前有了近乎一倍的提升，大大缩短业务上线时间。
而应用功能上的缺陷实际上哪个云上都有，只不过有一些云使用的用户多，早被发现、早被完善而已。而且使用用户多、功能完善的公有云，它的使用成本可能也高。这一切都需要去综合的进行考虑。
从这次至顶网在公有云迁移中发生的问题可以看出，问题主要出在以云主机搭建的系统在不同公有云的配合方面。而近期笔者正在研究的容器可以比较好地避免这样的问题发生。看来还需要再好好“忽悠忽悠”乐乐同学，让他什么时候再来完成一次公有云向容器的迁移。
敬请大家期待!
3951 阅读
3647 阅读
3648 阅读
3849 阅读
3744 阅读
3574 阅读
3611 阅读
3592 阅读
3664 阅读
3531 阅读
3238 阅读
4807 阅读
3416 阅读
3391 阅读
4732 阅读
3404 阅读
3387 阅读
4762 阅读
3454 阅读
3585 阅读
3618 阅读
4013 阅读
4201 阅读
3855 阅读
3694 阅读
3946 阅读
3707 阅读
4583 阅读
4693 阅读
4587 阅读
4308 阅读
4255 阅读
4380 阅读
4440 阅读
1063 阅读
958 阅读
1034 阅读
我们的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全部都是在线上进行操作，不需要进行资料邮寄，极大缩短了整个备案工作时长，包括审核周期基本上在十几个工作日左右就可以完成，效率比以前有了近乎一倍的提升，大大缩短业务上线时间。
而应用功能上的缺陷实际上哪个云上都有，只不过有一些云使用的用户多，早被发现、早被完善而已。而且使用用户多、功能完善的公有云，它的使用成本可能也高。这一切都需要去综合的进行考虑。
从这次至顶网在公有云迁移中发生的问题可以看出，问题主要出在以云主机搭建的系统在不同公有云的配合方面。而近期笔者正在研究的容器可以比较好地避免这样的问题发生。看来还需要再好好“忽悠忽悠”乐乐同学，让他什么时候再来完成一次公有云向容器的迁移。
敬请大家期待!