只需三步，遷移遺留系統到云端

背景

在互聯網大行其道唯快不破的今天，毫不夸張的說，對市場的響應速度甚至會決定一家企業的命運。我們的客戶（房地產垂直搜索平臺）就是這么一家互聯網公司，為了縮短開發周期，減少系統投放市場的時間，我們將現有的基于傳統數據中心的基礎設施遷移到云端，以便獲取這種的能力。本文講從大的方向上，講述了我們在合作的過程中，一起將老的系統向云上遷移的經驗，以及其中的一些實踐。在此之前，我們先來看看他們的現有系統。

現有系統

圖一

圖一是對現有核心系統的一個簡單抽象，我們維護了三條業務線（在這里是指以業務為基礎的，有獨立的產品經理，銷售團隊，獨立結算的團隊，下文簡稱LoB），每個業務線對應的是不同類別的房產的搜索網站，比如商業和住宅。User是用戶管理模塊，該模塊能提供用戶管理，書簽和搜索管理；Location是位置模塊，根據用戶的搜索條件給出實際地址和相鄰地址；Search Engine用于存儲所有信息，并提供搜索功能。可以看出三條LoB雖然是不同的網站，但是它們提供的服務是類似的。不僅如此，它們外觀相似度也非常之高，除了主題之外幾乎沒有差別，同樣的用戶體驗，相同的頁面布局，還有非常顯眼的標識用來說明他們來自于同一家公司。

從上述原因來看，它們應該集成在一個系統內，但其實不然，盡管這些業務線有如此高的相似度，但是從以下方面它們有著非常大的差別：

• 部署和配置不同

  由于不同的房產有不同的搜索條件，因此在部署的時候，需要對不同的網站進行不同的配置。

• 特性和發布時間不同

  不同的房產有不同的目標市場，需求決定了要開發那些特性，做什么樣的市場推廣活動，因此每個業務線都有自己的銷售和開發團隊，并且根據市場變化制定相應的特性開發和發布計劃。

• 不同的流量

  圖一中不同顏色表示不同的流量等級，紅色表示流量最大，黃色表示流量中等，而綠色則表示流量較小。對于不同類型的房產，市場的需求是不同的。

• 目標客戶不同，市場定位不同

  商業地產的目標客戶是那些需要開展商業活動的商家們，而住宅房產的目標客戶則是那些想要生活或者為子女提供更好教育機會的普通老百姓。

業務愿景

在了解了現有系統之后，我們再來了解一下他們的業務愿景，因為沒有一家公司的IT改革是脫離業務驅動的，理解業務愿景有助于更加清晰地理解向云遷移背后的原因。同時云策略的適用場景有一個更加直觀的認識。

• 3年后的年營收翻一番

• 基于LoB的運營模式

  這意味著每個團隊將是完全獨立的全功能團隊，他們擁有獨立的系統，具備獨立開發，部署，運維，市場，銷售的能力。這就為每個團隊提供了非常大的自主權利，對業務的擴張和收縮提供非常好的自適應能力。

• 效率

  這里所說的效率主要是指IT生產活動中的效率問題，本質上講他們是一個互聯網公司，如何能夠提高IT系統的效率來支撐業務的發展這是他們所看重的。比如，提高人的效率，開發，上線，測試，運維，線上反饋等等，各個方面的效率問題。

• 全球擴張計劃

  中國恐怕是全球最活躍的房地產市場之一了，同時對海外房產的投資在中國持續升溫，他們沒有理由放過這個機會的，不僅如此包括在德國，意大利，中國香港都有他們的身影。

基于以上的種種不同，圖一所示的系統架構顯然無法滿足客戶對商業愿景的實現，主要的問題有一下幾點：

• 無法獨立運營

  由于這是一個所有LoB都整合在一起的系統，因此業務線之間存在著耦合。試想一下這種場景，LoB1根據市場的反饋已經完成了對房產中介品牌的增強，并且希望在漲價之前上線，因為這將是一個漲價的合理理由。與此同時LoB2正在開發新的頁面來滿足房產擁有者品牌的需求，但是這個特性只是開發了一半。按照當前的模式我們必須等待LoB2完成特性的開發之后才能一起上線，這樣對于LoB1就錯失了一次漲價的機會，而下一次漲價窗口將是幾個月之后。

• 資源利用效率低

  通過流量監控我們發現網站的訪問量并不是一成不變的，以年為單位，網站流量在圣誕節之前會降低到平時的50%左右，圣誕節之后大概又會回升到平均水平200%左右，而這樣的大流量會持續約1周左右的時間。其實這樣的情況不難理解，因為在圣誕節期間大家休假，收假之后會迎來一波工作潮。從圖一中我們也可以清晰地看到不同組件的不同流量，為了保證整體的響應速度，這個系統始終是以比較高流量的情況部署的，但是由于每個LoB無法獨立部署，導致資源浪費的情況非常明顯。

• 擴張成本高

  前文我們提到了全球擴張計劃，他們想進入中國市場，于是需要為中國的用戶設計一個獨立的網站用于提供房源，同時也要將這一擴張作為模式，為將來的向其他國家的房地產市場擴展做準備，為了實現這一目標，我們需要IT基礎設施的支撐，能夠快速靈活的橫向擴張。但是基于現有的數據中心的模式，這將是一個痛苦的過程。

架構愿景

通過對原有IT架構的分析，我們發現它是很難支持業務愿景的實現的，因此針對這樣的業務愿景，我們勾勒出了能夠很好支撐業務愿景的IT架構愿景。

• 獨立業務線

  必須能夠按照業務線來獨立運營

• 擴展性

  容易擴展或伸縮

• 關注

  解決從開發到部署的所有問題，開發人員更加集中的關注如何更快的交付特性，而非各種環境問題，部署問題，發布問題

• 效率

  提高資源利用率，根據不同的流量情況自適應分配資源。

基于這樣的愿景，我們發現云平臺能夠很好幫助我們實現這樣的一種IT愿景，如圖二描述了系統遷移到云端之后的架構。

(點擊放大圖像)

圖二

首先，所有的業務線都是獨立運營，他們能夠自主選擇自己何時發布上線，自主選擇合適的SLA以及資源來適應流量的變化；其次，對于所有業務線共同分享的組件，獨立于業務線之外，分開部署和運營，并且它們也能夠根據流量的變化調整不同的資源進行適應。

遷移三部曲

當我們知道了現有系統的目標狀態之后，下一步就是如何實現這個目標了。

(點擊放大圖像)

圖三

如圖三所示，在向云端遷移的時，從現有系統到目標系統的遷移，這個過程不是一蹴而就的，不是一次遷移就能完成的，而是周期性地持續進行，每一次的前進都是相關系統集成的結果。如果我們將目光聚焦在其中某一個遷移的周期內，這個過程大概分為三個階段：

第一階段：識別

識別就是要弄清楚遷移什么。

對于原有的集成在一起的系統來說，這一過程與聚合更好相反，是把所有聚合在一起的功能特性分析并拆解，這個活動的目的就是深入理解當前系統承擔的職責。在弄清楚職責之后，我們就可以更好的識別哪些職責是可以被剝離，拆分，并獨立出去的。比如對這個房產搜索網站來說，識別之后發現我們的它的職責主要有：前段展示（桌面，移動），房產搜索，搜索的管理，用戶管理，地理位置查詢，同時還提供了部分API。在完成了識別之后，就是我們要選擇從哪些職責開始入手遷移。這個過程并不是隨機的，而是要根據現有的團隊能力，業務目標，綜合所決定的。

我的建議是從簡單的，相對獨立的職責入手，如果同時還能對業務發展有所支撐，那就是再好不過了，因為難度低，所以能夠在遷移初期給團隊帶來自信和經驗，隨著遷移經驗和自信的積累，那些耦合度高，依賴多的職責也能夠輕松的遷移。以該房產搜索平臺為例，在遷移初期，我們選擇用戶管理職責來遷移，一方面是因為它相對簡單，相對獨立，另一方面則是因為它對我們進行iOS開發提供了API支撐。

第二階段：提取

在識別出系統職責并確定要遷移的職責之后，則是提取該職責為獨立云服務的階段了。

圖四

如上圖所示，這一階段的核心就是將識別出來的職責獨立于原系統之外，成為獨立的云服務。這個過程有幾點需要注意的是：快速創建，它需要快，多快呢？理想狀態是創建成功（空服務）后就直接上線（灰度發布），或許這個目標在剛開始遷移的時候比較不容易實現，但是隨著遷移自信和經驗的積累，它是完全可行的，當然這也是為什么我們要從簡單并相對獨立的職責做起的另一個原因了；快速部署，我們創建新的服務是從空服務開始的，也就是說除了能在產品環境運行之外，它什么都沒有。在這個階段，我們的目標是將服務提取的兩大痛苦階段：創建和部署，變得簡單高效。

第三階段：集成

集成就是將新的云服務與原系統進行對接。

如果說前面兩個階段都是在做準備的話，那么這個階段就是實施遷移的過程了，可以說這是最為重要的階段，因為它是新老系統交割的一個時期。在這個階段會有這樣一些活動，首先，識別新服務需要哪些對外的接口，這需要對現存系統有比較深入的了解（當然如果接口比較簡單，這一步也可以放在提取階段來實現）；其次，將現有系統中對要遷移職責的依賴切換到新服務上，這個過程有可能是一次完成，也有可能需要持續完成，主要取決于職責的獨立程度以及現有系統依賴管理的復雜程度。最后，將該職責在原系統中移除。以用戶管理職責為例，這一階段就是將現有系統與用戶服務集成，并將其該職責從系統中移除。

遷移技巧

理解完這三個階段之后，不難看出，每兩個階段之間的轉換是否高效，流暢，無障礙，對整個的系統向云端遷移都起著至關重要的作用。在長時間的遷移經驗的積累下，我們發現以下的一些技巧能夠幫助我們在整個遷移階段中，平滑過渡。如圖五所示，當識別出遷移職責后，Stencil＋DevOps能夠幫助我們快速創建和部署云服務，在原系統與云服務對接時，可以由測試來驅動，對接之后，監控能為我們本次遷移周期提供很好的反饋，以便開啟一下個遷移周期。下面我們同樣以該網站為例，來介紹一下不同階段之間轉換的技巧：

圖五

技巧一：快速上線：Stencil + devOps

前文提到，這一過程一定要高效，也就是要迅速地創建并部署新的服務，只有這樣做我們才能講這一過程常態化，如何才能做到呢？我們采用了Stencil+devOps。

Stencil就是一個服務模版，它能幫助我們快速生成一個空的服務，包括遵循組織規范的目錄結構，標準的監控配置和接口，初始化的構建腳本等，使用Stencil的好處就是能夠快速創建符合組織標準化的服務；devOps則用于服務的部署上線，維護，持續集成和發布環境的搭建，當然它同樣遵循著組織的標準規范。如下所示，該模版主要包括3個部分：應用本身，部署腳本（AWS Cloudformation），docker配置（用于構建）。

技巧二：測試：消費者驅動測試

當我們快速上線一個空服務之后，下一步就是如何快速做兩個系統之間的集成，在進行系統間集成時，基本可以分為兩個小步驟：定義新服務的接口＋與現有系統的對接。定義服務接口可以是很簡單的過程，也可以是很復雜，主要取決于原有系統中該職責的復雜程度。但不管復雜與否，定義服務接口的過程都是一致的——消費驅動。不同于將新服務的所有接口預定義出來，它是按照消費者的需求，驅動新服務提供應有接口的，當然這里的消費者指的是現有系統。

圖六

從圖六中我們可以看出來，現有系統（即消費者）和新服務（即服務）集成過程是由兩組失敗＋成功的測試組成，或者說是由兩組 BDD 組成。首先是消費者側的BDD，中間人扮演了服務的角色，并且我們假定新服務的接口已經按照消費者的要求實現完成，此時由于消費者并沒有完成相應代碼的編寫，所以我們會得到一個失敗的測試，接著便是真正的編碼，到我們得到一個成功的測試時，意味著消費者端的集成工作就完成了；接著就是服務側的BDD，此時的中間人扮演的是消費者的角色，由于服務并沒有定義期望的接口，所以我們會得到一個失敗的測試，經過編碼，我們得到了成功的測試，此時就意味著兩個系統之間完成了互聯互通，并且有了測試來保證。

技巧三：監控

在我們拆分原有系統之前，所有的模塊都被整合在同一個系統之中，對系統的監控是統一的。但是當我們將現有系統拆分之后，就轉變為多個獨立系統，如何保證新服務良好運行，或者說如何實時監控新服務的運行狀態對整個系統的穩定至關重要。在實施監控的時候，我們應該考慮這些方面：

• 資源利用度

  以某個虛擬機節點為整體做的關于系統資源的監控

  (點擊放大圖像)

  

  比如說CPU利用率，硬盤讀寫，內存利用率等，主要的目的是檢查當前的節點是否出現過載或空閑的狀態，得到這些狀態信息之后，就能做出相應的處理。過載就說明資源無法滿足當前的流量，應該增加節點，部署更多的服務來適應大流量情況；空閑就意味著資源是有富余的，應該減少節點，以便降低成本。

• 健康檢查

  以服務為整體做的粗粒度的監控

  (點擊放大圖像)

  

  主要的目的是為了檢查當前服務是否處于運行狀態。如果檢測出服務屬于不可用狀態的話，云端的負載均衡會根據預先的配置，刪除該服務，并新增加一個全新的服務用于填補空缺。也就是說，基于當前的架構我們更傾向于重建服務而非修復不可用的服務。

• 日志

  所有服務內部狀態的監控

  (點擊放大圖像)

  

  上面兩種監控都無法得到服務內部運行狀態，因此日志監控在這里就顯示出了極大的重要性，尤其是兩個系統之間集成的日志，通過對系統日志的監控，使我們具有了監控系統內部邏輯的能力，有了這種能力我們就能夠追蹤事故的發生并得到關鍵信息，進而優化服務。

總結

從傳統數據中心的基礎設施向云端遷移是一個長期的過程，有可能還有很多未知的問題等著我們，但是我們發現在這同時又是一個對現有系統重新認識的過程，在這期間，我們有發現了其中的一些規律，每個功能的遷移都有各自的特點，同時又是相似的，這種相似性提取出來就是，識別，提取和集成。

感謝張凱峰對本文的策劃，崔康對本文的審校。

給InfoQ中文站投稿或者參與內容翻譯工作，請郵件至editors@cn.infoq.com。也歡迎大家通過新浪微博（@InfoQ，@丁曉昀），微信（微信號： InfoQChina ）關注我們。