系統(tǒng)轉(zhuǎn)向微服務(wù)之前，我們后臺(tái)是一個(gè)巨大的單塊服務(wù)，其中包括了在線金融銷售所需要的所有行為。一開始我們按業(yè)務(wù)系統(tǒng)進(jìn)行上下文劃分。

• 會(huì)員中心
  　 系統(tǒng)登錄認(rèn)證（客戶、理財(cái)師）、積分的元數(shù)據(jù)。

• 訂單系統(tǒng)
  客戶訂單、處理第三方商戶訂單(基金、第三方金融平臺(tái))、 處理退單、訂單鏈路跟蹤的數(shù)據(jù)。

• 商品模塊
  正在銷售與正準(zhǔn)備銷售商品的相關(guān)元數(shù)據(jù)。

• 支付中心
  第三方支付管理（與多家支付公司對(duì)接）、支付路由（根據(jù)手續(xù)費(fèi)與支付額度）、支付日志處理、同步基金和第三方金融平臺(tái)支付數(shù)據(jù)與核算等。

• 活動(dòng)中心
  活動(dòng)上下架、產(chǎn)品活動(dòng)限定、新手活動(dòng)推薦算法等。

首先創(chuàng)建相關(guān)業(yè)務(wù)包結(jié)構(gòu)來表示這些上下文，然后把相關(guān)的代碼移動(dòng)到相應(yīng)的位置。因?yàn)橥介_發(fā)與人員問題 ，我們新功能就在新創(chuàng)建的包上進(jìn)行，在這個(gè)過程中，我們會(huì)先把代碼相關(guān)的包依賴引入，共用的提取到共用的comm模塊然后引入；所以相關(guān)的業(yè)務(wù)都會(huì)與之交互。

在這個(gè)過程中業(yè)務(wù)依賴分解是相當(dāng)需要時(shí)間的，我們一個(gè)會(huì)員與支付中心因?yàn)榍捌诘_發(fā)趕進(jìn)度等原因耦合很嚴(yán)重，分解起來相當(dāng)費(fèi)時(shí)團(tuán)體花了將近二個(gè)多月才分離完成，測(cè)試同學(xué)花了半個(gè)月時(shí)間的黑+白盒測(cè)試才算有一個(gè)階段性成果，這個(gè)過程是新的業(yè)務(wù)在工發(fā)，舊的業(yè)務(wù)在分割，慢慢的往上面移，因?yàn)榫€上金融平臺(tái)天天在銷售，所以過程也不是一次性完，是團(tuán)體一天天、一點(diǎn)點(diǎn)的進(jìn)行的有。

分解原因

• 團(tuán)體
  我們團(tuán)體后臺(tái)差不多每一個(gè)都負(fù)責(zé)一個(gè)主要業(yè)務(wù)點(diǎn)并對(duì)應(yīng)不同的終端進(jìn)行同步開發(fā)，在一個(gè)單系統(tǒng)的情況，代碼沖突、包依賴混亂、小白短路、老黑腦抽等一些原因，不同的模塊提交或從分支合并后，經(jīng)常性服務(wù)跑不起來，團(tuán)體成員就開始加班加點(diǎn)找問題修復(fù)，測(cè)試驗(yàn)證、產(chǎn)品驗(yàn)證整人團(tuán)體經(jīng)過幾次都崩潰了。一到后來聽到技術(shù)團(tuán)體說發(fā)布版本至預(yù)生產(chǎn)環(huán)境，測(cè)試與產(chǎn)品部六臉都白的。

• 安全
  因?yàn)槭墙鹑谙到y(tǒng)，很多敏感數(shù)據(jù)都做嚴(yán)密的保護(hù)與隔離。分離后這部分就交由相關(guān)的核心負(fù)責(zé)，并對(duì)這個(gè)服務(wù)做了監(jiān)控、網(wǎng)絡(luò)傳輸、數(shù)據(jù)域的保護(hù)。

• 開發(fā)速度
  按業(yè)務(wù)分解后，相負(fù)依賴與影響提升到服務(wù)層次，再也不會(huì)因?yàn)槟X抽而引起服務(wù)問題，團(tuán)體后期的開發(fā)速度大的加快了。

• 關(guān)鍵的--數(shù)據(jù)庫(kù)
  單系統(tǒng)的情況下，我們數(shù)據(jù)庫(kù)是集成一個(gè)的，無法做多數(shù)據(jù)安全的隔離（總有人喜歡直接操作數(shù)據(jù)庫(kù)，防不勝防。。），分解后我們把相關(guān)的業(yè)務(wù)數(shù)據(jù)干凈的分離出去。

• 業(yè)務(wù)梳理
  頻繁的迭代（2個(gè)星期一版）與新增團(tuán)體成員的磨合使得業(yè)務(wù)代碼層次混亂，有時(shí)候找一個(gè)訂單相關(guān)的BUG，居然會(huì)找到產(chǎn)品模塊去等各種問題都暴露出來。