一、背景
但是遷移整個系統，工作量和流程不是簡簡單單就可以搞定，需要系統性的思考，完善的遷移方案，最後才可以實施。在開始今天的文章之前，童靴們可以自己思考一下，假如是你主持這場遷移，你需要考慮哪些內容。
二、挑戰
挑戰1：
挑戰2阿里雲的polardb-x雖然相容原生的mysql，但是個別的sql還是不相容，需要根據polardb-x的規則進行修改。所以我們在全面遷移之前，得相容polardb-x的sql規則，保證所有的sql都是可執行的。
挑戰3因為是進行系統遷移，必須要進行回歸測試，不僅僅是api服務的還有資料服務，測試流程長且繁瑣。
三、當前系統
遷移之前先給大家介紹一下當前系統架構，因為這些模組都是必須的，阿里雲平台上面肯定也需要對等的建立這些模組才可以。
技術棧：
架構圖：
四、阿里雲平台服務篩選
4.1 容器服務選擇
阿里雲的容器服務有ack和ask兩種，他們之間最大的區別就是ack需要購買物理節點，而ask不需要。經過研討確定之後，我們最終選擇了無節點的ask容器服務。
4.2 雲盤選擇
只要是程式就必然會產生檔案，現在因為採用ask無節點的容器服務，那日誌就必須通過專門的盤來放置。對這個盤需要有如下幾點要求：
有多種型別可供選擇，像日誌檔案儲存，不需要多強的效能，容量夠用即可，像mq的訊息就要求吞吐量要足夠高才可以。
可以設定過期自動刪除策略，因為像日誌檔案不需要長時間保留，一般保留最近7天就可以。
要有完善的監控服務。
針對上訴要求，最終我們選擇了nas雲盤服務。4.3 監控選擇
因為沒有實際物理節點，很多報警指標都沒辦法設定，只能借助第三方的服務來進行監控和報警，這邊我們選擇了prometheus作為監控和報警。
4.4 rabbitmq選擇
阿里雲有mq佇列服務，可以直接購買使用，但是會有很多限制，所以mq還是只能用原生的。
4.5 redis選擇
五、部署執行
因為阿里雲採用ask容器服務，沒有實際的物理節點，所以之前部署在節點上面的服務都要進行容器化才可以，例如nginx、rabbitmq。
建立映象容器
第一步我們需要建立各個應用對應的映象以及容器，這邊需要注意的時候，映象的命名空間最好以公司為主，容器的命名空間以型別為主。
雖然阿里雲集成了k8s的功能，但是關鍵字、功能等還是採用原生的k8s，上面的命名空間就是k8s的命名空間。匯入測試資料
回歸測試
polardb-x測試資料準備完畢，所有的映象和容器也都建立之後，就可以開始回歸測試了。
如果有測試用例，那測試階段就可以大大提高測試效率，這也是為什麼我們平時最好要寫測試用例的原因之一。六、遷移前準備
polardb-x的sql相容性修改完畢之後，就可以全面遷移資料了，遷移資料還是採用阿里雲的dts來進行，遷移資料可以分多個組進行，同步進行遷移，這種情況可以避免某些表因為頻繁的進行修改，導致bin-log日誌資料量突增，導致遷移的速度小於資料產生的速度（生產大於消費模型）。
當資料全部遷移過來之後，就可以開始正式遷移雲服務平台了，在遷移之前我們需要做如下準備：
redis、rabbitmq指令碼是否正確無誤。
容器中各個服務配置（資料庫、redis、mq等）是否正確。
nginx配置修改。
我們系統服務可以分為四大類：
api服務
監控服務
資料服務
分布式排程服務
除了api服務，其它三類短時間停止，不會有很大問題。6.1 停止推送服務
在停止服務之前，先要確定哪些服務在執行階段是不可被打斷的，如果被打斷就會存在資料缺失的情況，這種任務就得特殊對待，等它執行完再停止。6.2 遷移redis
6.3 啟動阿里雲服務
將阿里雲的api服務全部啟動，保證阿里雲平台的系統可用。
6.4 修改dns**
停止阿里雲dts資料遷移任務，將dns解析修改為阿里雲ip，將原本nginx中**也轉到對應ip中（因為客戶端可能存在dns快取，還是會走之前的ip）。
七、遷移後遺症
7.1 頻寬受限
遷移過來之後，系統頁面可以開啟，但是各個資料服務消費速度異常慢，檢查錯誤發現基本都是網路連線錯誤，也就是丟包問題。容器本身cpu、記憶體、io都是正常的，最終發現是閘道器連線數超標導致的丟包問題，公升級閘道器配置，資料消費服務就正常了。（http請求的tcp連線數過大，應該是應用程式出問題導致的，因為情況比較緊急，所以先公升配置，具體問題後面再檢查）。
閘道器配置公升級不僅僅是連線數公升級，還需要一起公升級頻寬，不然頻寬達到上限也會導致丟包問題發生。7.2 慢sql問題
系統某些頁面開啟發現特別慢，檢查之後發現是慢sql導致的，有些是沒有加分庫鍵導致的，有些是因為複雜sql連連表問題，這些慢sql導致連線池的連線無法釋放，最終導致連線池被耗盡，使用者的請求無法被響應。
7.3 mq非持久化
之前提到過，將mq從linux中變成乙個容器服務，但是因為mq的訊息本身需要持久化，因為mq的容器服務沒有配置好持久化，導致容器重啟之後佇列丟失問題產生。
7.4 nginx配置不對的
7.5 併發負載問題
測試環境沒有進行全量使用者的冒煙測試（使用者不一樣，sql所涉及的資料量也不一樣），導致服務遷移過來之後，流量瞬間上來，導致polardb-x的計算節點記憶體一度溢位，解決辦法只能先公升級，後面再修改具體的問題sql。
7.6 檔案讀取異常
nas分為：普通、高效能、超高效能三種，所以購買的時候就需要確定好自己的服務到底需要哪一種配置，一旦確定下來之後，後期需要修改的成本就非常高了，所以在開始階段一定要調研確定清楚。7.7 多容器配置修改問題
7.8 容器limit限制
容器一定設定limit限制，如果沒有這個限制，容器會無限申請資源，最終導致容器所在的物理機器失控，最終導致容器不可用。
7.9 未設定監控報警
需要對容器設定記憶體、cpu、重啟次數等各方面的報警，防止出現問題，相關開發人員還不知情。
7.10 就緒/存活檢查
容器需要設定就緒檢查和存活檢查，就緒檢查顧名思義，就是檢查容器是否啟動完成，這個就可以保證舊容器和新容器在切換的時候，可以無延遲快速切換，整個過程基本沒有停頓，使用者自然也感知不到重啟卡頓的過程。存活檢查就更簡單了，就是每間隔一段時間就去檢查一下容器是否正常在執行，如果不正常則進行重啟。
nginx容器必須設定就緒檢查，如果一旦nginx配置出現問題，導致容器啟動失敗，那將是毀滅性的災難。7.11 集群網域名稱請求
服務間請求一定要使用服務名稱來請求，不要寫具體ip，不然如果ip發生變動，就需要重新修改ip，構建部署專案，如果呼叫者的數量很多，又沒有做動態配置，那就非常麻煩。
八、總結
雖然在遷移系統之前，做了很多前期準備工作，但是在實際遷移過程中還是出現了很多問題，幸虧都一一解決了，也希望通過這次分享，大家可以在類似的遷移過程中，少走一些彎路。
-----------------------
**：wolzq.com
**無非增刪改查，關注老師給你coding
林老師帶你學程式設計：
一次真實的DDoS攻擊防禦實戰
第一輪進攻 突然發現公司的web server無法訪問，嘗試遠端登入，無法連線，呼叫idc重啟伺服器。啟動後立即登入察看，發現攻擊還在繼續，並且apache所有230個程序全部處於工作狀態。由於伺服器較老，記憶體只有512m，於是系統開始用swap，系統進入停頓狀態。於是殺掉所有httpd，稍後伺服...
DJANGO變動庫的一次真實手動經歷
在變更庫時，由於對欄位規劃和約束性沒考慮完全，需要手工運算元據庫，以便可以重複執行。有以下三點要注意。1，先迎合錯誤輸出，增刪對應的表或字段。2，必要時，修改migrations檔案，以去除唯一性限制。3，再必要時，清除django migrations的最近操作表記錄，重操作進行命令匯入。drop...
一次對抗大規模DDoS的真實經歷
每個 都會面對網路攻擊。唯一的區別在於，如何建設防禦，以及如何進行警報和響應。在網路上很難找到關於防禦黑客攻擊的真實案例。一方面，資訊披露可能會引發官司，另一方面，披露這些資訊往往會導致不良的財務後果，因此各公司往往不情願分享相關細節。然而，如果我們完全不披露這些故事，會使其它人在不知情的情況下犯相...