貝聊VPC遷移

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複製代碼

步驟1、工程代碼統一配置了內網地址

jdbc.driver=com.mysql.jdbc.Driver
jdbc.host = rm-bp14jsmqx123456.mysql.rds.aliyuncs.com/ibl_test
複製代碼

步驟2、VPC服務器配置/etc/hosts指向經典網絡RDS地址

#RDS地址指向公網IP 
10.118.xxx.xx rm-bp14jsmqx123456.mysql.rds.aliyuncs.com
複製代碼

步驟3、遷移完成後,執行 「一鍵切換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. 面對面溝通會議，避免理解誤差。