場景：
最近公司出了一個資訊洩露的故障，使用者的電話資訊被大量洩露。公司高度重視這次故障，打算給原來的Account資訊做加密。那麼我們該如何設計這個加密流程呢？
YY的流程：
可以確定原來的表裡面儲存了phone欄位，如果要加密必須要使用phone_enc，然後刪除phone欄位。
1.假設做了db表變更，增加了phone_enc注意這個欄位可以解密，那麼下一步肯定是fix data， 預發上寫段程式碼半夜將phone加密給phone_enc欄位。假設這一步資料fix了。
2. 程式碼變更，那麼使用者更換手機號的時候，你的phone_enc肯定要伴隨phone欄位做同步。update SQL的時候要做變更。
3. 程式碼變更，獲取手機getPhone()的時候，使用phone_enc欄位進行解密。
4. 上線
這樣問題基本已經解決了，問題來了根據電話號碼模糊匹配和全電話查詢的時候怎麼辦呢？ 模糊匹配的話任何加密應該都做不到吧，主要考慮全電話查詢的情況。全文匹配的話，其實很簡單，直接把要搜尋的電話加密查詢就可以了。
可是如果你的加密演算法被洩露了，你怎麼辦呢？
還是YY一下能夠想到的思路，第一想法更改加密演算法，那麼所有的加密演算法的程式碼都要改，你程式碼上線的前提是資料已經fix了，如果你還使用原來的欄位的話，但是加密的演算法變了，所以老的程式碼就不相容了。這時候你肯定只能重新做一次db變更了，再重新整一個欄位來儲存新的加密演算法了。這樣搜尋的邏輯也要隨著加密的演算法同步修改，因為你搜尋的是加密串。
正式的加密流程：
目前主要是分為三個階段，我認為還是很合理的，很多類似的操作都可以借鑑下。
第一階段：
表變更：
a) 增加phone_enc欄位，phone_md5_hc欄位同時建立索引
程式碼變更：
a) 雙寫，寫入phone的時候，同時寫入phone_enc
b) getPhone 判斷phone_enc是否為null，不為null的話則直接從phone_enc解密獲得
c) setPhone的時候記得將phone_enc 設定進去
第二階段：
fix data 將所有電話的phone_enc和phone_md5_hc 設定進去
第三階段：
表變更：
a) 去掉表裡面phone欄位
程式碼變更：
a) 物件裡面的欄位可以保留，但是SQL裡面關於phone的欄位要去掉
b) setPhone的時候將phone_md5_hc 欄位設定進去，查詢的時候用phone_md5_hc 欄位查詢。
總結幾點好處：
1) 相容性，可以相容老的程式，平滑升級
2) 支援加密演算法的切換phone_enc = aes+version+ encrypt，升級加密演算法的時候，程式碼基本不用修改
3) 加密演算法的升級不影響phone的搜尋功能
總結幾點：
1) 所有依賴Account-API的模組必須升級，setPhone的時候設定phone_enc到達雙寫的目的，getPhone要對phone_enc進行解密。
2) 如何避免依賴Account-api的應用全部升級？ 可以把setPhone和getPhone對加密的相關的操作都挪到service裡面，這樣只要介面不變，依賴的應用就不用升級。