1. 背景
2013年貝聊正式成立，為了加快專案研發節奏，伺服器使用了阿里雲經典網路ECS伺服器，4年後，隨著貝聊業務高速發展，阿里雲經典網路弊端逐漸展示出來。
經典網路伺服器分配的IP地址不是連續的，沒有固定的規則，運維人員需要人工維護繁瑣的安全策略組，存在安全隱患；經典網路ECS預設分配1M的公網IP地址，費用會比VPC網路伺服器貴，而這1M頻寬是個雞肋，滿足不了生產環境業務間呼叫；經典網路給業務帶來擴充套件性問題，跨機房部署在經典網路模式下變得複雜，服務的發現和註冊均需適配解決，且不支援阿里雲高速通道等高階功能。
阿里雲專有網路，簡稱VPC網路，可以很好解決上述的問題，經過技術團隊詳細的評估後，我們決定儘快遷移服務為VPC網路。
2. 目標
1. 遷移的方案儘可能簡單，業務需要改動工作量少
2. 遷移過程服務停機時間儘可能短。
3. 遷移後儲存資料必須保證一致性。
4. 遷移方案必須支援迅速回滾。
3. 技術方案
3.1. 現況
貝聊業務框架大致劃分4層，分別為接入層、Web層、Service層、儲存層，如下圖：
接入層使用阿里雲SLB處理負載均衡，貝聊自建Nginx分發服務；Service層使用開源社群Dubbo框架治理服務；儲存層使用阿里雲RDS資料庫和自建Redis分散式快取。
3.2. 遷移方案
3.2.1. 域名梳理
貝聊使用DNSPod管理域名，歷史因素影響，伺服器存在很多未知用途的域名，遷移會可能會造成部分功能不可用。
這種歷史問題確實沒有非常好的解決方案，只能讓運維匯出所有的域名列表，各部門小組認領，認領後負責人需要登記業務和相關人員資訊。運維對未認領的域名採取Nginx日誌監控告警，避免梳理錯誤業務訪問出錯。
3.2.2. 第三方服務
貝聊部分功能依賴第三方供應商服務(如簡訊傳送服務、支付寶)，服務遷移需要考慮新環境對第三方服務相容性，要對所有依賴第三方服務進行梳理，並測試第三方服務在新VPC環境是否正確工作。
有點大家要注意，VPC網路下ECS伺服器獲取公網IP地址不太一樣，不能通過ifconfig獲取了,如下
Dubbo服務註冊在Zookeeper只會暴露內網ip地址，獲取當前伺服器公網IP地址可以curl ipinfo.io網路請求方式獲取。
3.2.3. IP地址變更
遷移後所有服務重新部署，IP地址均發生變更，而目前大部分工程程式碼配置是硬IP地址，如下：
硬IP配置的方式會給我們專案遷移帶來很大的風險，如果配置漏修改，會導致遷移後服務不可用。
針對上述問題，本次遷移把所有的硬IP地址替換為域名，讓運維管理工作變得更方便，如果後續伺服器出現硬體故障，不需要修改程式碼配置，運維進行域名變更即可。
3.2.4. 資料遷移
貝聊儲存層儲存了使用者的資料交易等核心資料，不允許出現錯誤，儲存層由阿里雲RDS資料庫和Redis分散式快取叢集組成，阿里雲RDS支援“一鍵切換VPC網路”，非常完美幫助本次的VPC遷移工作。
Redis是我們自己搭建的叢集，涉及很多業務，資料量非常龐大，部分快取資料丟失可能會影響使用者正常使用，遷移難度較大。
我們在GitHub發現了唯品會開源了一個好用資料遷移工具redis-migrate-tool，地址：github.com/vipshop/red…
10G遷移資料在可以在幾分鐘內完成傳輸（網路頻寬資源要充足），同時redis-migrate-tool支援增量同步資料。
3.2.5. 測試驗證
服務部署、啟動、測試驗證都是非常耗時過程，我們無法保證遷移當天短時間完成所有服務部署驗證操作，況且遷移新環境存在很多未知因素。
為了規避風險，我們採取使用“提前部署和測試”方案，即提前在VPC伺服器部署所有的服務，並對該服務進行測試驗證，由於服務只對貝聊內部請求白名單開放，不會影響線上使用者的使用。
阿里雲RDS支援同時公網和內網連線運算元據庫，VPC新環境臨時使用公網訪問經典網路RDS，保證“提前部署和測試”測試過程資料是一致性的，等其他遷移工作完成後，RDS執行“一鍵切換VPC網路”，快速完成資料庫轉換。
上圖的VPC服務部署後，只能通過介面呼叫測試驗證，操作非常麻煩，需準備詳細的介面測試用例，辦公電腦Host挾持可以完美解決我們問題，如下
“Host代理”即在我們辦公電腦安裝Charles、Fiddler抓包工具代理，本地電腦配置/etc/hosts，利用hosts解析轉發請求到測試SLB，完美解決APP環境的切換。
3.2.6. Host控制
“IP地址變更”統一採用域名方式解決，“域名化”是本次遷移工作非常重要的變更，涉及Zookeeper、Elastic-job、Redis、Memcached等基礎服務，Host控制管理非常重要。阿里雲RDS也是基於域名地址提供服務的，提供了兩個不一樣的公網地址和內網地址。
VPC提前部署服務測試，通過公網連線經典網路RDS，在遷移完成後，RDS“一鍵切換為VPC網路”。資料網路切換為VPC後，需要修改工程程式碼指向VPC內網地址，並重新發布部署，工作非常繁雜，容易出錯。
基於上述問題考慮，在遷移過程中，我們在每臺伺服器/etc/hosts採取域名繫結控制。
假設資料庫ibl_test地址資訊如下
內網：rm-bp14jsmqx123456.mysql.rds.aliyuncs.com公網：rm-bp14jsmqx123456o.mysql.rds.aliyuncs.com複製程式碼步驟一、工程程式碼統一配置了內網地址
jdbc.driver=com.mysql.jdbc.Driver
jdbc.host = rm-bp14jsmqx123456.mysql.rds.aliyuncs.com/ibl_test
複製程式碼步驟二、VPC伺服器配置/etc/hosts指向經典網路RDS地址
#RDS地址指向公網IP
10.118.xxx.xx rm-bp14jsmqx123456.mysql.rds.aliyuncs.com
複製程式碼步驟三、遷移完成後,執行 “一鍵切換VPC網路”，把/etc/hosts配置移除，重啟服務。
#RDS地址指向公網IP （註釋）
#10.118.xxx.xx rm-bp14jsmqx123456.mysql.rds.aliyuncs.com複製程式碼貝聊在阿里雲100多臺伺服器，域名的切換要支援同時批量操作，ansible工具可以很好解決我們的需求。
Host控制給我們遷移工作帶來了便利，但是也存在缺陷，如Java程式預設會對DNS有快取，運維修改了/ect/hosts，可能無法立刻生效，對此為所有的Java程式配置了JVM引數networkaddress.cache.ttl合理值。
3.2.7. 風險控制
VPC遷移涉及所有貝聊伺服器，風險非常大，本次遷移工作大概風險點：
1. 人工操作錯誤
2. 依賴第三方服務故障
3. 漏覆蓋遷移服務
為了規避人工操作錯誤，我們在wiki制定了遷移過程所有人都必須遵循的操作步驟，如下
wiki上的操作步驟必須命令列、指令碼化，不允許遷移當天再去輸入Linux命令，這樣會浪費大量時間和出現人工操作失誤風險。
wiki雖然制定了操作步驟，每個人對文字步驟理解存在偏差，為此我們在測試環境組織了模擬線上的演練工作，要求每個操作人員都要理解wiki執行步驟，在一定程度規避了人工操作的風險。
如果在新環境出現嚴重的故障，遷移方案必須支援快速回滾，我們準備了一份回滾詳細操作步驟，步驟從反方向執行遷移，完成回滾，下圖
4. 遷移實施
4.1. 準備工作
遷移準備工作是非常繁瑣的事情，涉及貝聊內部多個部門，我們把VPC遷移作為一個專案進行推進，每週同步各個團隊的工作進度，使用wiki記錄各團隊執行的內容項。
4.2. 遷移演練
演練過程，所有關鍵人員必須就位，由一個負責人指揮協調所有的遷移工作，儘可能模擬線上的遷移。測試環境演練結束後，我們發現了很多問題，整個過程溝通不順暢，人工操作錯誤，系統多次出現異常問題一下子暴露出來，導致遷移演練耗時4個小時，超過了我們的預期。
針對演練碰到的問題，所有負責人聚在進行技術覆盤，重新又一次review所有的操作步驟，把不合理的步驟再一次完善。
4.3. 線上遷移
為了減少對使用者的影響，線上遷移我們選擇了凌晨執行，並提前了發客服公告，準了相對應的應急方案。
遷移當天，所有後臺技術人員準時在工位就緒，我們按照wiki準備步驟有條不紊地展開遷移工作，短短的25分鐘過後，我們成功完成了VPC遷移，共涉及100多臺伺服器，300多個Dubbo介面，30多項功能業務，約20G容量Redis記憶體資料遷移。
遷移完成後，所有人員須測試驗證完業務功能，檢查所有的服務執行情況，確保監控正常工作，交接好第二天值班人員事項。
5. 總結
VPC遷移看起來困難很大，但是認真執行後，其實沒有想象中困難，這次遷移工作，我們總結出幾點經驗：
1. 要做詳細遷移技術方案設計，針對關鍵步驟做技術調研，測試。
2. 使用類似wiki的專案管理工具制定統一操作步驟，避免人工誤操作。
3. 遷移演練和步驟review方式避免人工誤操作。
4. 面對面溝通會議，避免理解偏差。