雲遷移的那些事

雲棲號資訊:【點擊查看更多行業資訊
在這裏您可以找到不同行業的第一手的上雲資訊,還在等什麼,快來!

我們的CIO樂樂同學攤上事兒了,攤上大事了!在公司做出了更換公有云服務商的決定後,技術部就開始精心爲這次雲遷移做準備。這並不是我們第一次做雲遷移,技術部也做足了功課,但在公有云的遷移過程中捅出了“簍子”,一時間連發布系統都無法正常使用。爲什麼要做這次雲遷移,樂樂同學在雲遷移的過程中遇到了什麼?下面就讓我們來好好覆盤一下吧。

liscElNJAmNM_600

雲遷移前的系統重構

首先,讓我們來看一下樂樂同學他們在運遷移之前做了一些什麼樣的工作:

樂樂:在雲遷移之前,技術部先做了一件大事,將至頂網已經使用了十多年的業務系統整個進行了重構。

重構的原因很現實,十多年的應用積累,已經讓業務系統變得十分臃腫而龐雜。很多早已不再使用的應用和數據,就像一堆亂麻,不但沒有用,還成爲了病毒和木馬的溫牀,還有很多因底層系統老舊而存留的安全漏洞,也在時常威脅着系統的可靠應用。與其修修補補的將就過日子,還不如干脆推翻重建。重新打造一個系統成熟度更高、操作更加便捷、更加適合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全部都是在線上進行操作,不需要進行資料郵寄,極大縮短了整個備案工作時長,包括審覈週期基本上在十幾個工作日左右就可以完成,效率比以前有了近乎一倍的提升,大大縮短業務上線時間。

而應用功能上的缺陷實際上哪個雲上都有,只不過有一些雲使用的用戶多,早被發現、早被完善而已。而且使用用戶多、功能完善的公有云,它的使用成本可能也高。這一切都需要去綜合的進行考慮。

從這次至頂網在公有云遷移中發生的問題可以看出,問題主要出在以雲主機搭建的系統在不同公有云的配合方面。而近期筆者正在研究的容器可以比較好地避免這樣的問題發生。看來還需要再好好“忽悠忽悠”樂樂同學,讓他什麼時候再來完成一次公有云向容器的遷移。

敬請大家期待!

【雲棲號在線課堂】每天都有產品技術專家分享!
課程地址:https://yqh.aliyun.com/live

立即加入社羣,與專家面對面,及時瞭解課程最新動態!
【雲棲號在線課堂 社羣】https://c.tb.cn/F3.Z8gvnK

原文發佈時間:2020-07-28
本文作者:董培欣
本文來自:“至頂網”,瞭解相關信息可以關注“至頂網

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章