接下來(lái)，是入?yún)⒌脑O(shè)計(jì)。入?yún)?duì)于讀方法，比較簡(jiǎn)單，不做討論。對(duì)于寫(xiě)方法，我們將入?yún)⒃O(shè)計(jì)成有層次的數(shù)據(jù)模型。首先需要設(shè)計(jì)出公共的數(shù)據(jù)模型，比如訂單數(shù)據(jù)模型，商家數(shù)據(jù)模型，商品數(shù)據(jù)模型等，然后將這些數(shù)據(jù)模型和一些特定業(yè)務(wù)下的個(gè)性數(shù)據(jù)結(jié)合，組成Request對(duì)象，這個(gè)request對(duì)象按照不同業(yè)務(wù)操作不同而不同，對(duì)應(yīng)的返回結(jié)果就是response，它也是隨著不同業(yè)務(wù)返回的參數(shù)不同。

舉個(gè)例子，拿下餐飲訂單來(lái)說(shuō)，首先，我們應(yīng)該識(shí)別出這些業(yè)務(wù)流程中一些比較基礎(chǔ)的數(shù)據(jù)模型，比如餐飲領(lǐng)域的菜品、桌位等，這些模型之所以說(shuō)是基礎(chǔ)模型，是因?yàn)椋还芟率裁床惋嬘唵?，菜品和桌位肯定是逃不了的，它們是可以被?fù)用的！因此，我們分別為這些基礎(chǔ)模型設(shè)計(jì)相對(duì)于的DO（Domian Object）:DishDO（菜品）、BoardDO（桌位）等等，接下來(lái)，我們?yōu)橄虏惋嬘唵卧O(shè)計(jì)一個(gè)請(qǐng)求對(duì)象DishOrderCreateRequest其中DishOrderCreateRequest內(nèi)部包含了DishDO和BoardDO，另外會(huì)包含一些特定的屬性，比如人數(shù)啊，折扣啊等等，這樣一來(lái)就能做到通用和靈活兼顧，DishOrderCreateRequest代表的個(gè)性化的靈活的業(yè)務(wù)入?yún)?，而DishDO和BoardDO等則代表了不易變化的基礎(chǔ)模型。

c) 出參

***，是出參的設(shè)計(jì)。對(duì)于寫(xiě)方法，一般出參比較簡(jiǎn)單。對(duì)于讀方法，出參往往是一個(gè)結(jié)構(gòu)與層次比較復(fù)雜的組合對(duì)象。比如查詢(xún)一個(gè)訂單，這個(gè)訂單有訂單基本信息，還有商品信息，收貨人地址信息等。在設(shè)計(jì)出參的時(shí)候，結(jié)構(gòu)上要設(shè)計(jì)成組合對(duì)象，但是真正查詢(xún)的時(shí)候，通過(guò)查詢(xún)選擇器，去查詢(xún)不同的組合對(duì)象。比如查詢(xún)選擇器設(shè)置商品查詢(xún)?yōu)閠rue，地址查詢(xún)?yōu)閒alse，那么這次查詢(xún)出的訂單就只包含商品，而不包含地址。

2.2.2、業(yè)務(wù)流程

業(yè)務(wù)流程其實(shí)就是對(duì)業(yè)務(wù)規(guī)則的解釋?zhuān)皇沁@種解釋使用代碼去實(shí)現(xiàn)的，我們要做的其實(shí)就是準(zhǔn)確翻譯這些業(yè)務(wù)規(guī)則，并維護(hù)好這些業(yè)務(wù)規(guī)則。

業(yè)務(wù)流程中可以大致分為三種動(dòng)作節(jié)點(diǎn)，1、組裝參數(shù)節(jié)點(diǎn)  2、規(guī)則判斷節(jié)點(diǎn)  3、執(zhí)行動(dòng)作節(jié)點(diǎn)，其中每個(gè)動(dòng)作節(jié)點(diǎn)都是一些業(yè)務(wù)代碼的片段。舉個(gè)例子，下餐飲訂單，我們***步就是將上層傳入的參數(shù)組裝出一個(gè)基礎(chǔ)的DishOrderDO（組裝參數(shù)節(jié)點(diǎn)），然后按照特定的規(guī)則去填充這個(gè)DishOrderDO（規(guī)則判斷節(jié)點(diǎn)），然后就是調(diào)用DAO去創(chuàng)建DishOrderDO（執(zhí)行動(dòng)作節(jié)點(diǎn)）。

業(yè)務(wù)流程是最容易變化的地方，要想維護(hù)好業(yè)務(wù)流程并不容易，總的思想是將大的業(yè)務(wù)流程拆分成小的業(yè)務(wù)流程，抽出每個(gè)業(yè)務(wù)流程中共有的代碼片段，變成可維護(hù)的業(yè)務(wù)組件。

2.2.2、業(yè)務(wù)組件

a) 基礎(chǔ)組件

業(yè)務(wù)組件其實(shí)是將一些內(nèi)聚的可復(fù)用的代碼片段進(jìn)行封裝。和業(yè)務(wù)流程中的三種業(yè)務(wù)節(jié)點(diǎn)相對(duì)應(yīng)，業(yè)務(wù)組件也分為三種：組裝參數(shù)組件 、規(guī)則判斷組件 、動(dòng)作執(zhí)行業(yè)務(wù)組件。業(yè)務(wù)組件的抽象往往是對(duì)業(yè)務(wù)有了深刻理解之后才進(jìn)行的，盲目地進(jìn)行業(yè)務(wù)組件的抽象，往往到頭來(lái)白忙活。

b) 能力

對(duì)業(yè)務(wù)組件進(jìn)行進(jìn)一步抽象，可以得到能力。業(yè)務(wù)能力是具有一定復(fù)用性的組件的組合，比如發(fā)短信能力=組裝短信參數(shù)組件+發(fā)短信組件。對(duì)于發(fā)短信能力，可以被不同的業(yè)務(wù)流程復(fù)用，比如訂單下單成功發(fā)短信，支付成功發(fā)短信，邏輯都是相似的，只有內(nèi)容不同。能力是一種粒度比較大的組件，粒度越大，往往復(fù)用性就越小，對(duì)能力的抽取，也是基于對(duì)特定業(yè)務(wù)深刻的理解，沒(méi)有一勞永逸的銀彈。

c)更高緯度的抽象

經(jīng)過(guò)本人的實(shí)踐，對(duì)于互聯(lián)網(wǎng)這樣的需求變化極快的場(chǎng)景，更高緯度的組件抽象往往性?xún)r(jià)比很低，不建議大家去做。

2.3、基礎(chǔ)層

基礎(chǔ)層包含兩個(gè)部分，***是接口定義，第二是技術(shù)組件。

2.3.1、接口定義

接口定義是按照不同的技術(shù)框架，同時(shí)結(jié)合業(yè)務(wù)需要，設(shè)計(jì)出合理的接口，對(duì)于業(yè)務(wù)組件來(lái)說(shuō)，它們只會(huì)感知技術(shù)接口，而不會(huì)去感知技術(shù)實(shí)現(xiàn)，我們也不應(yīng)該將具體的技術(shù)細(xì)節(jié)向上暴露，這也就是所謂的面向接口編程。技術(shù)接口往往是業(yè)務(wù)與技術(shù)之間的橋梁，接口本身是含有業(yè)務(wù)含義的，最常見(jiàn)的就是DAO接口，我們?cè)O(shè)計(jì)DAO接口的時(shí)候，不會(huì)設(shè)計(jì)成insert、update、query這樣業(yè)務(wù)無(wú)關(guān)的接口，而是設(shè)計(jì)成insertUser，updateUserById等等和業(yè)務(wù)相關(guān)的接口，同樣的道理，設(shè)計(jì)緩存接口的時(shí)候，也不能設(shè)計(jì)成put、get這樣的接口，而應(yīng)該設(shè)計(jì)成cacheUser，deprecateUser這樣的接口。

2.3.2、技術(shù)組件

單機(jī)系統(tǒng)的技術(shù)組件一般來(lái)說(shuō)分兩種，一種是通用的技術(shù)組件，比如：數(shù)據(jù)存儲(chǔ)、緩存、消息和調(diào)度任務(wù)、事務(wù)、鎖。一種是基礎(chǔ)設(shè)施，比如spring容器，tomcat容器。下面稍微談?wù)勍ㄓ眉夹g(shù)組件。

數(shù)據(jù)存儲(chǔ)：數(shù)據(jù)存儲(chǔ)包括關(guān)系型數(shù)據(jù)庫(kù)、非關(guān)系型數(shù)據(jù)庫(kù)以及文件存儲(chǔ)系統(tǒng)。關(guān)系型數(shù)據(jù)庫(kù)，比如MySQL，適合存放絕大部分業(yè)務(wù)數(shù)據(jù)。非關(guān)系型數(shù)據(jù)庫(kù)，比如hbase，可以存放歷史日志，也可以對(duì)歷史的MySQL數(shù)據(jù)進(jìn)行歸檔。文件存儲(chǔ)系統(tǒng)，一般都是基于Linux文件系統(tǒng)，比如圖片、html文件等等，也有基于HDFS的，用于大數(shù)據(jù)分析。

緩存：緩存按響應(yīng)時(shí)間分，可以分為納秒級(jí)緩存，毫秒級(jí)緩存和百毫秒級(jí)緩存。納秒級(jí)緩存就是一般的基于本地內(nèi)存的緩存，比如encache，毫秒級(jí)緩存一般是集中式的內(nèi)存緩存，比如memcache，由于訪(fǎng)問(wèn)時(shí)遠(yuǎn)程調(diào)用，因此響應(yīng)時(shí)間會(huì)延長(zhǎng)到幾毫秒，百毫秒級(jí)緩存一般是集中式可持久化的緩存，比如redis，由于存在遠(yuǎn)程訪(fǎng)問(wèn)以及緩存擊穿導(dǎo)致的讀取持久化記錄，它的響應(yīng)時(shí)間會(huì)更長(zhǎng)些，到幾十甚至上百毫秒。單機(jī)系統(tǒng)一般用本地內(nèi)存緩存就夠了，當(dāng)緩存被擊穿的時(shí)候，直接訪(fǎng)問(wèn)數(shù)據(jù)庫(kù)。

消息和調(diào)度任務(wù)：消息和調(diào)度任務(wù)本質(zhì)都是一種異步化的手段，區(qū)別在于消息無(wú)法控制異步的時(shí)間，而調(diào)度任務(wù)可以。一般，消息發(fā)送出去后，監(jiān)聽(tīng)消息的系統(tǒng)會(huì)立即收到消息，從而立即觸發(fā)業(yè)務(wù)邏輯的執(zhí)行，而調(diào)度任務(wù)則會(huì)按照調(diào)度規(guī)則，一次或者多次的執(zhí)行業(yè)務(wù)邏輯。單機(jī)系統(tǒng)中消息和調(diào)度任務(wù)用到的比較少，在做日志監(jiān)控的時(shí)候可能會(huì)用到消息，在進(jìn)行數(shù)據(jù)報(bào)表統(tǒng)計(jì)的時(shí)候可能會(huì)用到調(diào)度任務(wù)。

事務(wù)：事務(wù)本質(zhì)都是基于數(shù)據(jù)庫(kù)去實(shí)現(xiàn)的，單機(jī)系統(tǒng)的事務(wù)就是依賴(lài)數(shù)據(jù)庫(kù)的事務(wù)，我們可以使用spring-tx的事務(wù)模板進(jìn)行事務(wù)操作，在業(yè)務(wù)邏輯開(kāi)發(fā)中，一定要把握事務(wù)的大小，建議把業(yè)務(wù)比較緊密的一堆數(shù)據(jù)庫(kù)操作放在一個(gè)事務(wù)里，不要隨意的為每個(gè)方法都開(kāi)啟事務(wù)。

鎖：?jiǎn)螜C(jī)系統(tǒng)中主要用到兩種鎖：樂(lè)觀鎖和悲觀鎖。樂(lè)觀鎖依靠在數(shù)據(jù)庫(kù)的業(yè)務(wù)表加版本字段來(lái)實(shí)現(xiàn)，每次更新都會(huì)去判斷版本是否變化，如果變化則需要重試，這種鎖的粒度比較小。悲觀鎖是基于JDK的Lock接口的，對(duì)一個(gè)業(yè)務(wù)流程進(jìn)行加鎖和釋放鎖的操作，鎖的粒度比較粗。

3、總結(jié)

以上是我經(jīng)過(guò)很長(zhǎng)一段時(shí)間的實(shí)踐后摸索出來(lái)的業(yè)務(wù)技術(shù)架構(gòu)，自認(rèn)為還算通用，而且能夠在一定程度上支撐易變的業(yè)務(wù)。當(dāng)然這套架構(gòu)肯定不是銀彈，不可能解決所有業(yè)務(wù)場(chǎng)景，所以最終還是需要圍繞到具體的場(chǎng)景加以借鑒。

關(guān)于作者

吳極心，目前在杭州旅居星球擔(dān)任架構(gòu)師，專(zhuān)注于技術(shù)架構(gòu)治和產(chǎn)品架構(gòu)。

本文鏈接：http://www.codeceo.com/article/business-framework.html
本文作者：碼農(nóng)網(wǎng) – 吳極心