前言

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

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

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

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

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

劃清業(yè)務邊界

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

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

代碼層次結構

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

├─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：基礎模塊，枚舉，常亮類，工具類，配置類。 demo-dao：Dao層，mapper接口，mapper.xml。 demo-service：服務接口提供層，業(yè)務service接口。 demo-web：web層，Controller類，服務接口，與外部進行交互。

各模塊之間的依賴關系為：

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

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

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

針對上述的兩個劃分模式，個人的選擇是根據業(yè)務模式劃分，這樣的包設計與后期微服務拆分有良好的匹配度，拆分的時候只需要將每個業(yè)務包下的代碼 Copy 到新的微服務中就行了，易遷移變動小。每個模塊中對不同的業(yè)務通過 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

這樣劃分有什么好處？我們單體架構的時候這樣開發(fā)，當需要拆分成微服務的時候就可以直接將業(yè)務包拆分出去，因為每個業(yè)務包里面就已經包含了所有的當前業(yè)務的關聯(lián)業(yè)務類。

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

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

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

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

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

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

所有的參數(shù)校驗也放到 service層，因為如果服務內部調用也可以使用提高代碼的共用度。當然分層領域模型最好也能區(qū)分開，

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

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

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}后記

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

以上就是Java從單體架構升級到微服務要注意的一些問題的詳細內容，更多關于Java的資料請關注好吧啦網其它相關文章！