合抱之木,生於毫末；九層之臺,起於壘土；千里之行,始於足下。-----------送給在碼農之路上搬磚的自己。

本次遷移所能夠設想到的內容，以後遷移方案可以按照這個步驟來：

1>券包遷移方案需要滿足的要求：
1)daily／gray上釋出，因為無法保證一次將優惠券移到另一個trade不會發生問題，儘量以介面或介面部分流量為單位進行遷移則可以大大降低出錯率。
2)客戶端無感知，平滑遷移，系統長時間不可用是無法接受的。
3)可回滾，一旦出現異常問題可以快速回滾，避免造成較大影響。必須有回滾方案。
4)易實現，儘量避免大量地操作，操作多意味著犯錯的可能性更大，回滾的難度也大，在風險可控的情況下選擇最優最易實現的方案。
5)資料校驗，遷移方案確定之後，功能都能夠實現，對線上環境最重要的是 線上資料遷移之後進行的資料校驗確保 遷移前後資料一致。

2>資料庫部分需要滿足的要求：
1)建新表儘量建新表以避免對老資料的破壞。
2)假如需要減欄位，那麼請考慮臨時替代的方案，比如新建一張臨時表，讓程式先取臨時表資料，最後等新表建立後再切換過來，匯入資料。
3)CACHE等需要序列化，反序列化的部分。一定要相容原先在快取中的資料，例如SID千萬不要變化，否則反序列化失敗，假如有欄位需要增加，那麼考慮第一次讀入先取資料庫。
4)外部介面相關的，能不要求外部介面聯調，儘量就不做聯調，一是麻煩，二是風險大。儘量對原介面傳入和傳出的資料保持相容。假如有變化，考慮用介面卡封裝，實在沒辦法再實行下策。
5)注意操作的先後順序，這個也是非常重要，例如你先發了資料庫，但是程式還是老的，並且會受到影響，那麼就掛了。

3>優惠券遷移方案的詳細流程：

 1>本次遷移設計到哪些專案／模組／功能

2>本次遷移設計的controller層

3>遷移設計到的service

4>設計到資料庫表

5>相容老的服務介面

6>dubbo服務的更新

7>釋出，根據易現實性，在風險可控的情況下選擇最好釋出線上的設計

 7.1>線上釋出在保證資料準確性下的具體流程。設計到nginx的請求重定向等等。

7.2>nginx流量的跳轉控制等

總結：這次優惠券的遷移花了一週的時間，跟CTO對過之後，在具體的遷移過程中沒有對著自己所列的注意事項一項一項遷移，導致釋出gray的時候dubbo／service都沒有更新，許多dto都是使用jar包上的，也沒有遷移。導致時間往後delay了3天。還有許多小細節自己也沒有處理好，處理問題緩慢等原因。

 以後遇見遷移的問題可以直接往上面套，不僅僅是遷移一次就完了，以後再次需要遷移就是從1-->n的而不是還是從0-->1的過程。