導讀
“平臺遷移那些事”是eBay CCOE EEE (Engineering Ecosystem and Experience) 團隊最新推出的系列文章，本文爲總起篇。從V3平臺的陳舊應用無縫轉移到eBay最新的Raptor.io平臺，該項目涉及eBay百億級流量的遷轉，並要求在整個遷移過程中不影響任何實時服務，對eBay用戶保持透明。
01 緣起
身處互聯網時代，我們每天都面臨着技術的升級換代，以及全新技術的不斷湧現。相應地，eBay內部的開發平臺也在不斷演化。目前, eBay就有應用分別存在於三代Java開發平臺上，平臺名字分別爲V3、Raptor、Raptor.io。
首先我們簡單介紹下這三代的Java開發平臺。
V3 Platform - eBay較老的開發平臺，最早開發於20年前，當時的操作系統還是Windows2008（Batch Jobs 跑在Solaris機器上），運行着 IBM JDK 1.6，使用 IBM Geronimo Web服務器。所有代碼的開發、打包、編譯都是eBay自主定義的規範。
Raptor/Raptor.io - Raptor/Raptor.io是V3的下一代平臺，操作系統基於Linux，使用開源的OpenJDK 和Tomcat Web服務器。代碼的開發，打包、編譯分別基於Spring/Spring boot、Maven、Git 等開源工具。Raptor.io 相較於Raptor更爲輕量化，模塊化且更好地支持雲原生環境。
時至今日，大部分基於V3平臺的應用都已經被業務團隊升級到了Raptor/Raptor.io平臺。但是也有部分V3應用因爲年代久遠、功能複雜，遲遲不能被順利遷移到新平臺。
“平臺遷移那些事”系列文章，將重點分享如何抽絲剝繭，將基於V3平臺的陳舊應用無縫轉移到eBay最新的Raptor.io平臺。項目本身涉及eBay百億級流量的遷轉，並要求在整個遷移過程中不影響任何實時服務，對eBay用戶保持透明。
02 V3的世界
V3的存在已經將近20年了。在這20年中，V3已經發展到代碼近八千萬行，每天的流量達到百億甚至千億規模。時光流逝，隨着新技術和新架構的不斷湧現，V3在開發、編譯、打包、部署和容器化等等方面都顯得力不從心, 慢慢地成爲eBay的技術負債。要想平滑地將V3平臺上的應用遷移到新平臺上，就必須先充分了解V3的平臺組成，所謂知其來路，才能明其去向。
下圖非常清晰地描述了V3平臺的具體框架結構和組成。完整的V3環境包括核心類庫，業務類庫, 五種類型的應用類型，以及相關的開發支持工具。
顯而易見，淘汰V3環境已經成爲eBay的當務之急。原因在於，很多老爺車現在即使eBay願意支付服務費，但開發廠商也已經不再維護，譬如IBM JDK。一旦無法升級，所產生的安全隱患將是eBay這樣的大公司絕對不能忽視的。因此需要將IBM JDK 變成 Open JDK，Web服務器由Geronimo變成Tomcat，操作系統由Windows 變成 Ubuntu。基礎運行環境的消失，意味着V3應用也失去了生存的土壤，它們必須被遷移到新一代的平臺。
03 挑戰荊棘之路——從V3到Raptor.io
從V3平臺到Raptor/Raptor.io的遷移就像要把一個蘋果變成一個梨，都是水果，但是滋味完全不同。這當中有許多的挑戰。eBay 數次嘗試讓業務部門自己把V3的代碼重寫來消除技術負債。但是收效甚微。因爲對於業務部門來說，平臺遷移意味着天翻地覆的變化，更因爲隨着部門成員的更迭，某些V3應用的領域知識早已消失殆盡，遷移應用似乎成爲了一項“不可能完成的任務”。下面我們具體羅列6項平臺升級中的主要挑戰。
3.1 平臺核心類庫衝突
首當其衝的挑戰就是平臺核心類庫的變化。即使是同樣的功能，由於平臺不同，實現的方式也不同。這些核心類庫在V3 平臺是eBay 自己實現的，而Raptor 平臺是基於Spring，Raptor.io 平臺則是基於Spring Boot。平臺變化後，要能保證新的核心類庫和V3現有的業務類庫能夠正常工作。無論是啓動順序，還是核心功能，抑或是接口都需要兼容。不僅是應用需要調整，新平臺的核心類庫也需要進行代碼調整以應對沖突。這就需要拆遷團隊和平臺團隊合作，把核心類庫的修改應用到新的平臺版本中去。同時拆遷隊也要保證遷移的應用V3的核心類庫從傳遞依賴中剝離乾淨，防止衝突。
3.2 新舊框架適配
下表是不同類型的應用在不同平臺下，核心框架的變化。
從上表可以看出，應用的遷移不僅涉及到平臺的遷移，也涉及到每種應用類型框架的遷移。拆遷團隊不僅要能夠處理V3 和Raptor/Raptor.io平臺之間的差異，還要能夠處理不同代的應用類型框架之間的差異。
3.3 應用功能無人描述
由於這些應用大多產生於10多年前，人員的流動導致這些應用做需要實現的功能已經沒有團隊成員能夠完整描述。
而最大的問題是，代碼遷移後如何進行測試，它有哪些測試用例，又有多少種輸入組合，這些，均無人知曉。在缺少測試用例、缺少領域知識、系統輸入組合不定的情況下，如何保證遷移的質量？更何況在遷移之後，不僅要保證功能正確，還要確保系統穩定、所有的運行指標正常。
3.4 應用特殊配置難以發現
由於多年間歸屬團隊的更替，某個應用有沒有特殊配置，有哪些特殊的配置？如果要複製這些配置需要什麼團隊的合作？這一連串的問題，我們不知道、用戶也不知道。如果這些設置會導致系統運行直接失敗，那麼也比較容易發現。但是有些配置只是影響災備或者致使性能緩慢降低，這些就很難被發現了。這在後文成功案例的章節中會有介紹。以系統響應變慢爲例：
系統變慢（比如cache沒有設置），不影響功能。看起來問題不大，但是它意味着吞吐量的下降，會導致雪崩效應或者鏈式反應。這是系統隱患，必須解決。我們不能放過任何一個可疑的指標變化，必須找出每一個方法變慢的原因。在毫秒級別的差距中找到疑點並確認。
3.5 網絡層搬遷難以複製
要是一個應用能夠正常工作，光靠代碼遷移是不夠的。這個應用要連接到上、下游的應用，只有和所有的上下游都能正常通訊，這個應用才能正常工作。我們需要逐個檢查才能保證網絡層搬遷成功。
應用網絡層的搬遷常見檢查有防火牆、白名單、證書、https/http支持、安全配置等。以防火牆爲例，在eBay就有軟件防火牆，硬件防火牆。在新的應用下，原來的硬件防火牆規則都需要遷移到軟件防火牆。硬件防火牆的規則堆積了很多年，需要找出哪些是需要複製的，哪些是不需要複製的。即使找到了要複製的規則，也要考慮軟件防火牆可以設置三個不同層級的防火牆規則。新的應用需要在哪一層複製原來的規則都是非常複雜的問題。這一部分好在有eBay Altus的依賴發現服務，幫助我們省去了大量的查找工作。在此需要強烈感謝基礎架構團隊給予我們的大力支持。
3.6 無間斷應用導致風控難度高
eBay提供的是24*7無間斷的服務。每個應用遷移都只能是實時在線的流量切換。在總流量達到幾百億的規模下，我們要保證線上服務不中斷。在流量切換過程中儘早發現問題，在危急關頭做出正確的評估，哪些問題可以選擇快速修復，哪些問題只能採取立即回撤，這些問題時刻考驗着拆遷團隊的臨場指揮能力，必須依靠平日積累的現場作戰經驗。
04 策略分析及解決方案——整屋拆遷
所謂兵來將擋，水來土掩。針對以上的各種挑戰，V3拆遷團隊需要逐個擊破，並制定全方位的解決方案。經過縝密的研究，一種稱之爲”整屋拆遷”(Forklift)的方案浮出水面。
理想情況下，在新的平臺上重寫一套新的應用是最好的選擇。重寫不僅滿足了新平臺的需求，而且對應用團隊完全掌握代碼的功能、理解新平臺的規範、優化以前的實現都有巨大的幫助。但是重寫的代價非常昂貴。近八千萬行代碼的重構，在缺少測試用例的情況下，風險巨大。而且重寫不僅意味着這個應用本身的改動，也意味着這個應用的上下游也可能受到影響，所以難度就成倍數增加了。更復雜一點的情況，如果一個調用鏈上都有應用重寫，那麼這個依賴鏈條上的優先級和進度更是難以保證。因此，全部重寫對於eBay這樣體量的網站來說，是很難實現的。
整屋拆遷的概念就好像是搬家，房子是新的，水電煤是新的。但是格局、房間裏的傢俱，管道和插座都沒有變化。 對應到應用遷移，就是不觸碰用戶的業務代碼邏輯，專注於讓用戶的代碼能夠跑在新的平臺上。這種方法通過分階段、自動化的方式負責所有應用的遷移。從代碼遷移開始，直到舊的環境全部回收，一條龍服務，全程負責。用戶只需要負責必要的測試和校驗。尤其對於V3 SOA, Trading, Shopping, BES這些後端服務，“整屋拆遷”最大限度地提高了成功率並降低了風險。
經過反覆論證，V3拆遷團隊即將開始整屋拆遷V3的應用。我們即將從理論探討縱身一躍，進入真刀真槍的實幹階段。一些聞所未聞的深坑，也在靜靜地等待挑戰者的到來。下一章節，我們將深入探討遷移期間所遇到的困難和具體實施解決方案。
05 整屋拆遷(Forklift)——“痛並快樂着”
下面這張圖說明了整屋拆遷的流程。它分爲五個階段，目標是儘量減少客戶工作量， 同時保證安全可靠。
5.1 代碼遷移
代碼遷移是第一步也是重中之重。工欲善其事，必先利其器。代碼遷移工具主要目標是實現代碼遷移自動化。工具必須具備的能力是把V3的應用源碼自動變成Raptor/Raptor.io 的源碼，同時能夠讓幾千個不同類型的應用在覈心平臺類庫、框架變化的情況下，業務代碼邏輯不改變、用戶不參與源碼改動、無縫地進行代碼遷移。
那麼我們要考慮3個平臺(V3/Raptor/Raptor.io)，5種框架(SOA/Batch/BES/Trading/Shopping) 的適配，也就是前面提到的“核心類庫衝突，不同框架適配”的挑戰。這就需要對所有涉及到的知識都有深入的掌握，然後才能處理這些問題。比如V3Batch是eBay自己寫的框架，Raptor Batch基於Spring Batch，兩個核心框架接口完全不同，如何保證遷移的應用代碼邏輯不改變還能正常工作？拆遷團隊最終在工具層面解決了這些問題。我們會在本系列的後續文章中詳細介紹。
在解決平臺和框架挑戰的同時，我們也要提高代碼遷移效率。這個工具要能提高遷移團隊的效率，用更少的人解決更多的問題。在以前的遷移歷史中，每種應用都有一個自己的開發工具。這種方式其實在某種程度上造成了資源浪費。例如，當同一個問題發生在覈心類庫時，在不同類型的應用中錯誤的表現並不一樣。每個工具都有自己的解決辦法。這就帶來了一些問題：這些知識點不能在多個團隊中共享，不同團隊的解決方案的質量也參差不齊，不僅浪費時間，關鍵是相同癥結還會重複出現。
爲解決這兩個問題，代碼遷移的工作不再是簡單的單打獨鬥，而是用遷移平臺的理念進行一站式遷移。
從圖3上看，我們把工具平臺分爲三層。
前兩層是工具自動化處理部分。 底層有兩個Platform converter，一個是Raptor 的converter，一個是Raptor.io的converter。這兩個platform converter 能夠處理平臺級別的差異。第二層可以集中處理各種應用框架之間的差異。對於每一個框架差異，都有一個插件來處理。通過底部兩層的邏輯處理，對一個應用運行命令後，拆遷平臺就生成了初始遷移代碼。
第三層是人工處理部分。 在自動產生的代碼之上，拆遷隊需要解決每個應用特有的問題。到了這個階段，大部分問題在下面兩層已經被解決了。拆遷隊所面臨的是不論哪種應用類型都存在的問題。對於那些常規重複的， 遷移團隊很容易建立知識庫。通過人工處理之後，就可以拿到可以運行、測試的代碼了。
針對這樣的分析，對於下面兩層，由於需要對平臺和框架有深入的瞭解，所以由我們的資深成員在工具層面進行開發來解決。對於頂部，面臨的問題沒有那麼大挑戰性，主要是由我們的外包同事來承擔。這樣的策略，充分發揮了每個人的能力。這也是爲什麼遷移團隊只有不到10個人，就能完成所有的V3 應用遷移的原因。
在這一步，特別要強調的是工具要能提供應用拆分的能力。V3的應用是多個項目（project）聚合在一起，在打包的過程中才變成一個獨立的應用。這些項目可以來自於同一個團隊，也可以屬於不同的團隊。那麼拆遷就有各種需求：
- 屬於同一個團隊的應用要求整體拆遷，和V3一樣是一個獨立應用。
- 屬於不同團隊的應用，有需求把各自團隊的項目拆走，變成一個個獨立應用。
- 有些沒用的項目不需要拆遷。
我們的工具滿足了這樣的需求，用戶滿意而歸。但是對於後面的流量遷移和就地環境的回收，給拆遷隊帶來了很多額外的工作量。
5.2 應用校驗
校驗分爲拆遷團隊校驗和用戶校驗。當拆遷團隊認爲遷移的代碼沒有任何問題後，用戶才進行必須要的校驗。“應用功能無人描述的挑戰” 就對拆遷團隊提出了很高的要求：不知道業務邏輯，缺少測試用例，但是要保證測試質量。該怎麼做？
爲了這個目的，框架團隊又開發出了兩套流量鏡像(Mirror) 工具。基本的思路是：白盒測試很困難，那麼我們走黑盒測試。任何一個應用，給定一個輸入必定有一個輸出。假如能夠直接使用V3線上的請求作爲拆遷應用的測試輸入，拆遷應用的輸出和V3應用的輸出進行對比，就能夠進行測試了。詳見下圖：
基於這個理念，我們做了基於流量的Traffic Mirror 工具來測試服務應用，和基於事件的 BES Mirror 工具來測試消息應用。解決了下面三個問題：
a. 功能性測試。就是把V3的請求分給拆遷的應用一份，運行同樣的方法後，響應發到後臺分析服務，通過比較差別來達到測試的目的。
b. 負載測試。把線上的實際最大流量複製到拆遷的應用，可以進行指標監控。可以真實地知道遷移的應用能不能撐起這個流量。
c. 創造測試用例。通過線上的實際輸入，我們拿到實際輸出，基本上一個測試用例所需要的元素就齊全了。那麼可以反向生成這些測試用例，擺脫測試用例缺乏的困境。
5.3 流量遷移
流量遷移是整個拆遷過程中最重要的一環，也就是6大挑戰中的”無間斷應用導致風控難度高”這一挑戰。如果這一步出了問題，直接就是生產問題。我們必須保證安全平穩地進行。因此，下面會多花點筆墨進行介紹。
“在無間斷應用導致風控難度高” 的挑戰下，流量遷移需要回答兩個問題：1. 怎麼遷 2. 怎麼控制風險。首先我們回答怎麼遷移的問題。
1）怎麼遷
原本整個應用的流量遷移，是比較容易的。但是由於前文提到的應用拆分，就讓流量遷移變得沒那麼簡單了。針對不同的應用拆分場景，我們需要確定拆分模型，確定流量引入策略。
流量遷移模型
eBay的流量遷移需要考慮Software LB 和Hardware LB兩條通路的遷移，非常複雜。在後續的文章中會詳細說明。本文以Hardware LB流量遷移的四個常見用例來說明。
左上 是V3 整個應用都遷移到Rapor 新Pool。這種情況只需要保留相同的CName名稱，修改GTM配置將其導入到新的Pool中。
左下 是一個V3應用被拆成2個或更多個服務，每個服務在V3都有獨立的CName，並且這些服務的客戶端都使用這些CName進行調用，這時候只要單獨在GTM 層面遷移每個CName即可。
右上 是一個V3應用拆成多個服務，這些服務在V3他們還是分享同一個CName。在這種情況下，我們可以依據請求路徑和請求頭來設定LB的路由規則，然後將服務流量分配到相應的Pool中。
右下 是一個deliverable有個前置網關的情況，通常我們有兩種選擇：
a. 直接把網關的調用地址改成新pool的地址。這種是最乾淨的。但是這樣的改動，流量上去就是100%，沒有任何緩衝。通常只適用於流量非常小的Pool。
b. 網關先不改調用地址，還是根據情況按照其他三個情況之一進行遷移。等完全穩定了，再進行調用地址的修改。
生產環境上的流量引入策略
在生產環境，我們需要有漸進地增加流量的遷移，來應對隨時可能出現問題並實現回滾。我們將使用1%, 10%, 25%,50%, 75%, 100% 的遷移策略，一步步增加流量的遷移。
2）強化風控
任何人都不能保證線上流量遷移的時候沒有一點問題。對於風險第一是預防，第二是控制。預防靠數據，控制靠流程。我們依靠數據和流程這兩樣武器，硬是闖出了一條安全通道。
預防
風險預防靠數據。道路千萬條，安全第一條。在流量遷移中，無數次化險爲夷，靠的就是我們堅定地不打折扣地實行數據預防。風險預防主要體現在以下幾個方面，在流量遷移的每一個階段我們都要重複地進行如下工作：
-
異常對比。
我們收集V3應用的所有異常，同時也收集新的應用在這個階段的異常，從而進行比對。如果出現V3的清單裏所沒有的異常，必須進行研究，給出結論。如果發現問題，必須完全解決。
-
功能驗證。 主要依靠：
線上日誌
監控系統
-
狀態驗證。 我們需要監控這些數據：
內存
CPU利用率
GC Overhead
剩餘物理內存
請求耗時對比
-
負載均衡驗證。 流量均衡是保證能夠長期穩定運行的一個基礎。主要檢查：
每個區域的流量
每個機器的流量
遷移的流量百分比是否正常
只有這些步驟完全正常，我們才能進行到下一步。一旦有任何異常，都不能放過。有些應用（比如下文提到的buyingsvc) 有1000多臺機器。那麼意味着僅僅對這一個應用，我們就要監控1000多臺機器的性能指標。同時這又不是一次性工作，流量遷移過程中每一個階段，都要重複地進行不同區域、不同時間、不同流量下新老應用的數據對比。這就要求拆遷隊不僅要有決心，更重要的是要有超人的耐心去承擔巨大的工作量。
控制
風險控制靠流程。再嚴的家門，也不可能完全防住碩鼠。風險不僅要預防，還要控制。真出事了怎麼辦？誰來解決？根據什麼來操作？這就是流程控制的作用。風險控制是一場團隊響應時間與錯誤時間的對決。
-
準備階段
拆遷隊找到FE團隊進行遷移前的溝通，確定目標和方案。同時通知用戶，讓大家都知道預定計劃。
拆遷隊發出ticket給FE 團隊，描述遷移方案。FE團隊收到請求後，根據方案，在FE的工具中設置好配置。
-
流量遷移
通知產線監控團隊後，拆遷隊用FE團隊的工具自主開始切換預定流量。切換好之後，通知用戶。
-
監控
用戶和拆遷隊會繼續監控流量進入的情況。如果萬一有問題，拆遷隊可以用FE的工具在一分鐘內回滾。如果十分緊急一時還找不到人的情況下，根據協議，用戶可以找產線監控團隊回滾。
-
迭代增加流量
流量遷移100%完成後，這個應用遷移就全部完成了。剩下的就需要觀察一段時間後，進行舊環境的回收工作。
06 成功案例
這裏，我們以buyingsvc 爲例，說明整屋拆遷的效果。buyingsvc 是搜索部分一個重要的基礎應用。當用戶登錄eBay，輸入關鍵字進行搜索後，就會調用這個服務。可以說，buyingsvc和用戶體驗息息相關。它就是在拆遷的應用中作用最大的那個：機器超過 1000臺 ，每天的流量超過 110億 。它的遷移成敗是決定性的。如果遷移失敗，那就意味着V3遷移的失敗。通過我們整屋拆遷的流程，這個應用順利地完成了拆遷。雖然結果令人滿意，但是實際過程並非一帆風順，拆遷隊和所有相關的團隊合作，嚴格遵循流程才能圓滿地完成任務。
6.1 結果——系統指標全面提升
對於這麼大的流量，我們用了比原來更少的機器，同時機器的配置還降低了一半，卻達到了系統性能的全面提升和本地開發體驗的改善。
6.2 過程——戰鬥在踩坑和填坑之間
下面就以我們是如何發現隱藏的配置爲例，來說明我們是如何克服搬遷的困難的。
buyingsvc配置到底有多少，無論是對拆遷隊還是現有的應用團隊都是未知的。如果找不全，就意味着功能的缺失。這個發現的過程需要巨大的努力，需要拆遷隊、應用團隊、流量控制團隊和線上管理團隊的信息交互。對於buyingsvc，我們有三個意外的發現，也填補了三個前所未知的“坑”。
1）高效溝通——發現未知的後臺調控系統
對於buyingsvc調用的後臺架構，左邊的圖是我們猜想的架構，右邊是實際的架構。我們以爲後臺就是一個集羣，但是實際的架構中有個中間件系統，它可以任意把流量切到不同區域的後臺，這是一個重要的災備能力。要讓新的應用也有這樣的能力，必須在中間件部分對新的應用進行配置，同時需要進行演習來驗證配置的正確性。如果不是和線上管理團隊的溝通，我們是不可能知道這樣的配置的。
2）性能比較——發現缺失的數據庫配置
通過Traffic mirror的數據比對，我們發現buyingsvc的響應時間V3要比Raptor.io平均快10ms。但是所有的功能都正常。我們認爲，從理論上看，Raptor.io的整體性能一定比V3好。如果個別的服務響應慢一些是可以接受的，尤其是那些響應時間只有幾毫秒的服務。但是所有的服務速度都慢是不正常的，我們需要找到原因。
我們發現在三個區域SLC、LVS、RENO中，RENO的速度比V3快，其他兩個區域明顯要慢。通過查找代碼，發現原來需要在數據庫中增加配置，來進行後端匹配。例如，SLC的機器找到SLC的後端。如果沒有配置，所有SLC，LVS，RENO的機器都會連到缺省的RENO後端。由於不在一個地點，有網絡延時，所以SLC，LVS的速度會變慢。通過增加數據庫的配置，Raptor.io就全面比V3的響應速度快了。
3）流量覈對——發現丟失的GTM 配置
流量切換，如果比率不準，就是個大問題。如果流量過大，可能會導致當前的容量不夠，把新的應用沖垮。如果流量過小，流量的切換設定無法覆蓋所有的流量分支，那就會導致最後流量不能100%遷移。
在這個應用中，當我們切換10%流量的時候，進入到Raptor.io應用的流量要比理論的值少很多。左圖是拆遷隊理解的的模型，把所有屬於GTM的CName配置好切換比率，流量就可以按照預想切換。但是實際上，有一些CName沒有配置在GTM的管理中，因此這些CName的流量始終還是流向V3。按照這樣的配置，即使GTM切到100%，V3還是有流量。這是以前配置的疏漏，需要把這些失落的CName加入到GTM的管理中。這樣流量切換就正常了。
07 總結
任何一個V3 的Pool 的消亡都是不容易的，感覺拆遷隊真的是殫精極慮。治大國猶如烹小鮮，V3遷移是一個浩大的工程，但是每一個V3的應用的遷移，又都是一個獨立成章的故事。我想分享的是，做一個項目，不僅僅是考驗技術能力，還有項目的執行能力和團隊的紀律性也都是成功的基礎。說到做到、風險控制和風險預防，這些道理很簡單，難就難在嚴格的執行，在日復一日的工作中始終做到一絲不苟。
對於拆遷團隊，對於每一個應用，都有根據標準模板生成的文檔來規範我們的行爲，任何人都可以通過這個文檔瞭解我們的工作進度和工作內容。從應用創建到應用流量遷移完成，每一步都有詳細的數據和根據這些數據得出的結論，每一步的關鍵點都有檢查結果，每個數據異常都是要刨根問題。任何光鮮成功的背後，其實都是千百次枯燥、無趣的堅守。
依靠嚴謹的態度，我們挑戰了看似不可能完成的任務。不僅提升了技術，同時也鍛鍊了團隊。回顧這一年曆程，大家都覺得意義非凡。在後續的系列文章裏，我們還會分不同的專題來與大家分享“平臺遷移那些事兒”，道一道咱們這支eBay“V3拆遷隊”的酸甜苦辣。
本文轉載自公衆號eBay技術薈（ID：eBayTechRecruiting）。
原文鏈接：