前言

由于近年來的移動端的發(fā)展和 2C模式 的紅利，一些在風(fēng)口的企業(yè)的業(yè)務(wù)得到爆發(fā)式增長。從架構(gòu)層面來說，業(yè)務(wù)驅(qū)動技術(shù)的變革，所以微服務(wù)架構(gòu)的概念得到很多企業(yè)的青睞，因?yàn)榭梢越鉀Q服務(wù)的大流量和高并發(fā)以及穩(wěn)定性的要求。

但是任何架構(gòu)設(shè)計不是一蹴而就的，不能從起步就開始使用微服務(wù)，一般都是先通過單體架構(gòu)來快速實(shí)現(xiàn)需求和搶占市場，然后再迭代式擴(kuò)展。不能一口氣吃個胖子。

這幾年自己有經(jīng)歷從單體到微服務(wù)的架構(gòu)演變，也有直接參與到已經(jīng)落地的微服務(wù)架構(gòu)的項(xiàng)目中。見過好的架構(gòu)設(shè)計，也見過一些孬的設(shè)計。好的架構(gòu)設(shè)計，代碼結(jié)構(gòu)優(yōu)雅，分層清晰，業(yè)務(wù)邊界劃分明朗，業(yè)務(wù)開發(fā)人員職責(zé)清晰。不好的設(shè)計就會導(dǎo)致代碼混亂難以維護(hù)，對新需求無法快速應(yīng)變，開發(fā)人員容易在補(bǔ)丁上打補(bǔ)丁，最后造成積重難返不得不重構(gòu)。

架構(gòu)師需要從業(yè)務(wù)層面和未來業(yè)務(wù)發(fā)展有個全面的規(guī)劃，讓架構(gòu)高可用，易擴(kuò)展，靈活易使用，隱藏其復(fù)雜性。好的架構(gòu)會讓下面的業(yè)務(wù)開發(fā)人員按照既定的模式“傻瓜式”編程。

既然第一步是單體架構(gòu)，那么好的單體架構(gòu)設(shè)計，為我們后期的微服務(wù)拆分會有事半功倍的效果。避免重復(fù)勞動和過多的重寫。我們可以從這些方面進(jìn)行一些有效的設(shè)計。

劃清業(yè)務(wù)邊界

如果對未來的架構(gòu)有微服務(wù)的考慮，那么在單體架構(gòu)的時候就需要理清業(yè)務(wù)邊界的問題，常見的簡單劃分就是以業(yè)務(wù)區(qū)分，例如：用戶，商品，訂單，支付，權(quán)限等等，具體的拆分程度可根據(jù)自身業(yè)務(wù)量和需要做劃分。

當(dāng)前流行的 DDD（領(lǐng)域驅(qū)動設(shè)計）可以作為一個指導(dǎo)原則，但是 DDD 比較偏向于理論，需要執(zhí)行人員有良好的專業(yè)能力才能實(shí)施的比較好。

代碼層次結(jié)構(gòu)

業(yè)務(wù)區(qū)分好之后，就是項(xiàng)目代碼模塊的設(shè)計。在代碼層我們需要根據(jù)MVC的模式，建議的代碼設(shè)計層次如下：

├─demo-common│ │ demo-common.iml│ │ pom.xml│ │ │ └─src│ ├─main│ │ ├─java│ │ └─resources│ └─test│ └─java├─demo-dao│ │ demo-dao.iml│ │ pom.xml│ │ │ └─src│ ├─main│ │ ├─java│ │ └─resources│ └─test│ └─java├─demo-service│ │ demo-service.iml│ │ pom.xml│ │ │ └─src│ ├─main│ │ ├─java│ │ └─resources│ └─test│ └─java└─demo-web │ demo-web.iml │ pom.xml │ └─src├─main│ ├─java│ └─resources└─test └─java

主要包含4個 module 模塊

demo-common：基礎(chǔ)模塊，枚舉，常亮類，工具類，配置類。 demo-dao：Dao層，mapper接口，mapper.xml。 demo-service：服務(wù)接口提供層，業(yè)務(wù)service接口。 demo-web：web層，Controller類，服務(wù)接口，與外部進(jìn)行交互。

各模塊之間的依賴關(guān)系為：

項(xiàng)目 Module 模塊設(shè)計完成之后，每個模塊的內(nèi)部 package 包如何設(shè)計呢？通常有兩種劃分模式：根據(jù)業(yè)務(wù)模塊然后內(nèi)部按MVC劃分，根據(jù)MVC模式然后內(nèi)部按業(yè)務(wù)劃分。

1、根據(jù)業(yè)務(wù)模塊劃分，就是將每個業(yè)務(wù)模塊作為一個 package，然后每個package里面有自己的 MVC，這樣就做到業(yè)務(wù)模塊的隔離。

2、根據(jù) MVC 模式劃分，先根據(jù) MVC模式劃分不同的包，service，serviceImpl，dto等，然后再是各個業(yè)務(wù)自己的模型和服務(wù)接口。

針對上述的兩個劃分模式，個人的選擇是根據(jù)業(yè)務(wù)模式劃分，這樣的包設(shè)計與后期微服務(wù)拆分有良好的匹配度，拆分的時候只需要將每個業(yè)務(wù)包下的代碼 Copy 到新的微服務(wù)中就行了，易遷移變動小。每個模塊中對不同的業(yè)務(wù)通過 package 包名進(jìn)行劃分，例如：com.example.jajian.service.order、com.example.jajian.service.user等。

└─src ├─main │ ├─java │ │ └─com │ │ └─example │ │ └─jajian │ │ ├─common │ │ │ BaserService.java │ │ │ │ │ └─service │ │ ├─order │ │ │ ├─dto │ │ │ │ OrderDto.java │ │ │ │ │ │ │ └─service │ │ │ │ OrderService.java │ │ │ │ │ │ │ └─impl │ │ │ OrderServiceImpl.java │ │ │ │ │ ├─pay │ │ │ ├─dto │ │ │ │ PayDto.java │ │ │ │ │ │ │ └─service │ │ │ │ PayService.java │ │ │ │ │ │ │ └─impl │ │ │ PayServiceImpl.java │ │ │ │ │ └─user │ │ ├─dto │ │ │ UserDto.java │ │ │ │ │ └─service │ │ │ UserService.java │ │ │ │ │ └─impl │ │ UserServiceImpl.java │ │ │ └─resources └─test└─java

這樣劃分有什么好處？我們單體架構(gòu)的時候這樣開發(fā)，當(dāng)需要拆分成微服務(wù)的時候就可以直接將業(yè)務(wù)包拆分出去，因?yàn)槊總€業(yè)務(wù)包里面就已經(jīng)包含了所有的當(dāng)前業(yè)務(wù)的關(guān)聯(lián)業(yè)務(wù)類。

避免多邊界業(yè)務(wù)的關(guān)聯(lián)查詢

單表關(guān)聯(lián)由于業(yè)務(wù)需要而且簡單方便易使用，所以多表關(guān)聯(lián)查詢在單體服務(wù)中是普遍存在的，如果我們后期不需要做服務(wù)拆分則可以不需要考慮這方面的限制。

但是如果后期有微服務(wù)的規(guī)劃，那么單體服務(wù)的時候如果沒有做這個方面的限制，mybatis 的 mapper.xml中有過多的多表關(guān)聯(lián)查詢，這些關(guān)聯(lián)查詢會嚴(yán)重影響服務(wù)拆分的進(jìn)度和復(fù)雜度。

如果同屬于一個業(yè)務(wù)領(lǐng)域則可以使用關(guān)聯(lián)查詢，而那些微服務(wù)拆分后屬于不同領(lǐng)域的業(yè)務(wù)則應(yīng)避免使用多表關(guān)聯(lián)查詢，因?yàn)椴煌臉I(yè)務(wù)領(lǐng)域后期會被隔離拆分到不同的服務(wù)當(dāng)中，即數(shù)據(jù)庫表都是分布在不同的服務(wù)器上，所有服務(wù)之間都是通過RPC方式進(jìn)行通信，關(guān)聯(lián)查詢這時是無法處理的。

Controller層盡量不做業(yè)務(wù)邏輯處理

常看到很多 coder 會在Controller 層做一些業(yè)務(wù)處理，個人認(rèn)為這是很不規(guī)范的。Controller層是控制層，是和前端進(jìn)行數(shù)據(jù)轉(zhuǎn)換的，這里我們應(yīng)該只做請求的接受和返回，也無需做一些異常的try...catch...的捕獲，異常可以通過全局通用攔截器統(tǒng)一進(jìn)行攔截然后返回給前端異常提示語，提升代碼的簡潔性。

所有的參數(shù)校驗(yàn)也放到 service層，因?yàn)槿绻?wù)內(nèi)部調(diào)用也可以使用提高代碼的共用度。當(dāng)然分層領(lǐng)域模型最好也能區(qū)分開，

DO(Data Object)：此對象與數(shù)據(jù)庫表結(jié)構(gòu)--對應(yīng)，通過DAO層向上傳輸數(shù)據(jù)源對象。 DTO（Date Transfer Object）：數(shù)據(jù)傳輸對象，service或Manager向外傳輸?shù)膶ο蟆? VO（View Object）:顯示層的對象，通常是Web向模板渲染引擎層傳輸?shù)膶ο蟆?p>這樣區(qū)分開的好處是，當(dāng)你需要對展示層數(shù)據(jù)進(jìn)行特殊定制化的時候可以靈活變通，例如針對用戶隱私信息身份證號，手機(jī)號碼脫敏處理，或者用戶ID加密顯示等。

最后就是統(tǒng)一通用返回類了，通過這種格式的封裝我們將數(shù)據(jù)格式進(jìn)行全局格式化，這里的狀態(tài)碼可以自己設(shè)計的更詳細(xì)一點(diǎn)。

public class CommonResult<T> { public static final String CODE_SUCCESS = '0'; public static final String CODE_FAILED = '9999'; private String code; private T data; private String msg; private CommonResult(String code, T data, String msg) {this.code = code;this.data = data;this.msg = msg; } public boolean isSuccess() {return CODE_SUCCESS.equals(code); } public static <T> CommonResult<T> success() {return new CommonResult<>(CODE_SUCCESS, null, null); } public static <T> CommonResult<T> success(T data) {return new CommonResult<>(CODE_SUCCESS, data, null); } public static <T> CommonResult<T> success(T data, String msg) {return new CommonResult<>(CODE_SUCCESS, data, msg); } public static <T> CommonResult<T> failed() {return new CommonResult<>(CODE_FAILED, null, null); } public static <T> CommonResult<T> failed(String errorCode, String msg) {return new CommonResult<>(errorCode, null, msg); } public static <T> CommonResult<T> failed(String msg) {return new CommonResult<>(CODE_FAILED, null, msg); } public static <T> CommonResult<T> failed(T data, String msg) {return new CommonResult<>(CODE_FAILED, data, msg); } public static <T> CommonResult<T> failed(String errorCode, T data, String msg) {return new CommonResult<>(errorCode, data, msg); } // 省略 setter、getter}后記

以上只是列舉了單體服務(wù)未來規(guī)劃做微服務(wù)時需要注意的一部分簡單內(nèi)容，每個人在做單體架構(gòu)拆分成微服務(wù)的時候都會踩到各種各樣的坑，這些坑成了我們的開發(fā)經(jīng)驗(yàn)，有了這些坑就會形成注意點(diǎn)，在我們下次開發(fā)時就會具有指導(dǎo)意義。也許我們程序員就是在踩坑和填坑的過程中成長壯大起來的。

以上就是Java從單體架構(gòu)升級到微服務(wù)要注意的一些問題的詳細(xì)內(nèi)容，更多關(guān)于Java的資料請關(guān)注好吧啦網(wǎng)其它相關(guān)文章！