前言

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

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

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

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

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

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

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

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

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

業(yè)務(wù)區(qū)分好之后，就是項目代碼模塊的設(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ù)接口，與外部進行交互。

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

項目 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 包名進行劃分，例如：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ā)，當需要拆分成微服務(wù)的時候就可以直接將業(yè)務(wù)包拆分出去，因為每個業(yè)務(wù)包里面就已經(jī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)查詢會嚴重影響服務(wù)拆分的進度和復(fù)雜度。

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

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

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

所有的參數(shù)校驗也放到 service層，因為如果服務(wù)內(nèi)部調(diào)用也可以使用提高代碼的共用度。當然分層領(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ù)膶ο蟆?/li>
• VO（View Object）:顯示層的對象，通常是Web向模板渲染引擎層傳輸?shù)膶ο蟆?/li>

這樣區(qū)分開的好處是，當你需要對展示層數(shù)據(jù)進行特殊定制化的時候可以靈活變通，例如針對用戶隱私信息身份證號，手機號碼脫敏處理，或者用戶ID加密顯示等。

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

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)驗，有了這些坑就會形成注意點，在我們下次開發(fā)時就會具有指導(dǎo)意義。也許我們程序員就是在踩坑和填坑的過程中成長壯大起來的。

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

最新評論