摘要

本文主要介紹當隨著業務的不斷髮展，原本一個服務的內容需要抽象出另外的服務，作為中颱服務，提供給各個業務前臺，提高前臺業務開發效率。

業務架構

隨著業務的擴充套件，一個服務的程式碼越來越多，啟動越來越慢，開發的人數越來越多，不得不進行程式碼拆分，早期有些拆分是按分層拆分，將data,dao層拆分成公共jar，然後很多服務呼叫，結果導致的就是後期無法維護，業務增長了，分屬於不同的開發組了，本來每個開發組的職責都是內斂的，只開發自己那塊的就可以，但是現在對於其他組的業務也得熟悉，因為沒有共同的服務提供出來，都是自己查庫，寫庫的邏輯改了，有可能會影響到很多地方。所以正確的做法是各個業務按照領域劃分，只負責自己的業務部分。

重構過程

重構過程一般分兩大部分，一個部分是收集現有的需求，進行領域模型設計，成為一箇中臺服務，另外一個部分就是遷已有的程式碼。

一. 中臺領域模型設計
對於一些業界比較成熟的方案，這個是很容易劃分職責，區分邊界的，比如電商領域，淘寶都有書籍出版出來了，按照訂單，支付，商品，庫存，計價等中臺設計即可。但是對於自己公司本身的業務，這個可能很難找到現成的參考案例，需要找到公司自己的業務人員，溝通來確定領域設計

二. 遷移老程式碼
一般按照3步走，將遷移服務的影響降到最低

1. 遷移寫，雙寫
   先遷移寫，確保寫入中臺的部分不會出錯，這一步上線了新服務，確保了前臺業務呼叫正常。
   同時將老資料遷移
   需要有個遷移表，記錄兩邊資料遷移過程
   雙寫是以寫入老服務為準，寫入新服務異常，出現異常，都是catch注，打入log，記錄異常原因

2. 遷移讀
   首先需要將寫改為寫入新服務為準，老服務備份。
   同時將讀改為從新服務讀

3. 下掉寫
   1，2都沒問題後，將寫入老服務下掉。

需要說明的時，這種遷移和資料庫分庫分表的遷移有些不同，第一點資料庫分庫分表的拆分一般是同庫，表結構的一般只是增量變更，不會更改已有設計，而中臺通常伴隨著的是領域重新設計，從資料庫，到服務層都會有變更。

重構經驗

1. 程式碼分層
2. ut
3. bean為不為空說明