第9期 2020/07/31
云遷移的那些事
我們的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在內容審計上與金山云上的不同之處。
企業網站，最擔心的無非就是在網頁上被掛上木馬。隨著安全技術的進步，網頁掛馬的事情很少發生了，但是利用漏洞在早期的一些網頁上加載一些非法鏈接的情況還是難以避免。除此之外還有一些文章中的敏感詞匯，也是新聞行業中的大忌，雖然我們是專業媒體，但是一旦有小編手滑，一不小心也容易犯下大錯。在金山云上我們就時常為這類事情煩惱。但是沒想到在遷到UCloud之后，UCloud的公有云居然自帶有敏感詞匯的內容審計功能，可以對已知敏感詞匯進行內容比對。在解決困擾多時的敏感詞發布問題后，還順便協助我們查找到以前舊內容中一條被注入的一個非正常網站信息。果然是失之東隅，收之桑榆呀！
小結
回顧這次的云遷移過程，樂樂表示，UCloud雖然存在一些功能不完善的地方，但是從用戶業務請求響應的角度來講，UCloud還是比較令人滿意的。比如，我們的要求是在半秒鐘內對用戶的請求進行響應，而UCloud在300毫秒內就可以提供響應，這個是超過我們的預期的。而且在域名備案上，UCloud全部都是在線上進行操作，不需要進行資料郵寄，極大縮短了整個備案工作時長，包括審核周期基本上在十幾個工作日左右就可以完成，效率比以前有了近乎一倍的提升，大大縮短業務上線時間。
而應用功能上的缺陷實際上哪個云上都有，只不過有一些云使用的用戶多，早被發現、早被完善而已。而且使用用戶多、功能完善的公有云，它的使用成本可能也高。這一切都需要去綜合的進行考慮。
從這次至頂網在公有云遷移中發生的問題可以看出，問題主要出在以云主機搭建的系統在不同公有云的配合方面。而近期筆者正在研究的容器可以比較好地避免這樣的問題發生。看來還需要再好好“忽悠忽悠”樂樂同學，讓他什么時候再來完成一次公有云向容器的遷移。
敬請大家期待！
本文章選自《AI啟示錄》雜志，閱讀更多雜志內容，請掃描下方二維碼
