契機
對於單元化，我一直都是一知半解，今天被老板問到了一些關於單元化的問題，“XXX有沒有單元化” “為什么不單元化” ，既然要回答老板的問題，那就順便把單元化里面的一些邏輯理一理，學習一下。
what？什么是單元化
所謂的單元化就是將所有的服務全部都部署在同一個機房里面作為一個單元，然后請求將按照UID進行路由到具體某個單元。單元化可以解決的問題：
1、通過異地多活的方案解決系統的穩定性；
2、服務都部署到同一個機房，可以降低RPC遠程調用過程中的性能損耗；
why？為什么要做單元化？
如果將服務器都部署在同一個地區，從整體上可以看做是一個單元，那么其容災能力、整體穩定性等就會受到影響，單元化正是為此而生。
實現了單元化的好處
1、每個單元都可以處理請求，分擔流量，從這個角度來看，單元化就是在做橫向擴展，並且我們所做的單元化不受地域影響，這就意味着橫向擴展的能力會非常強；
2、每個單元內部都可以處理一個完整的業務流程，避免跨機房調用，降低RPC遠程調用的性能損耗；
3、增強了系統的容災能力，即使某一地的單元由於外部原因導致其全部崩潰，在進行切流后也能保證用戶請求被正常處理；
how？怎么實現單元化？
1、請求路由
既然存在多個單元都在執行相同的業務功能的話，那么就需要對請求按照某種維度進行路由，並且可以保證同一類型的請求后續都會落到同一個單元中，否則的話，數據會存在不一致的問題。一般會按照買家的維度來拆分，買家及訂單相關的數據都可以在本單元進行讀寫，實現單元內部的讀寫封閉，避免多個單元去更新某一共享數據。
但是也存在部分數據是所有買家都需要的，也就是商家與商品數據，所以，單元這個東西也被划分了類型，能夠向其他單元同步數據的單元就是中心，而像商品或者賣家等需要被所有買家知曉的共享數據會在中心被處理，並且中心也會接收普通單元的買家數據，最終，連同自身的共享數據同步到每個單元，也就是說，每個單元最終都會獲取到全部數據，但這只是保證數據的最終一致性。
2、切流方案
如果某個單元內出現了問題，需要切到其他單元，但是切流過程中也會存在問題，如果兩個單元之間數據還沒還有完全同步，用戶切到新的單元之后可能就看不到之前的操作記錄了，或者只能看到一部分，這時候如果用戶繼續操作，將會導致兩個單元數據不一致。怎么辦？
1) 禁寫：為了保證數據一致性,會先對路由變更的用戶禁寫,為了讓切流后新增數據不受影響,必須支持只禁止更新，但是可以新增，也就是說此時用戶還可以繼續下單，這一步的話是通過TDDL的SqlMonitor機制實現的；
2).切流：推送單元路由規則，應該是針對CDN的規則，會講買家流量切換到新的單元中，不至於說讓買家的頁面就這樣處於卡死崩潰的狀態，影響用戶體驗；
3).同步：通過DRC來將故障發生到切流的這個時間段的數據同步到新的單元；
4).執行：等數據同步過來后，就可以正常用戶對原數據的更新操作了；