前面寫過兩篇文章《談一下我對如何做需求分析的理解和思考》、《談一下我對如何設計微服務介面的理解和思考》從需求和外部介面的角度講了開發一下微服務需要考慮的方方面面；本篇進入微服務內部，談一下如何設計微服務內部的子模組。

如何設計一個子系統(微服務)的內部模組？模組的劃分和設計都有一些套路可尋，在微服務架構體系中，使用不同的開發語言 子模組有不同的載體。使用Java開發，子模組可以是不同的Jar包或者同一個專案下的不同package；使用C++開發，不同的子模組是各個dll。一般來說，不同子模組的原始碼是隔離的，它們或者處於不同IDE專案下，或者存放在不同的資料夾目錄下。

一個微服務下的子模組如何劃分通常是由業務決定的。微服務的功能比較複雜劃分的模組就比較多，功能簡單劃分就少。模組分層劃分是基本思想。一般來說，一個服微務的模組會劃分為訊息介面層，業務控制層、演算法邏輯層、資料模型層、資料適配層、公共處理層這六層。下面描述一下這六層模組設計的規則和需要注意事項。

訊息介面層

訊息介面層顧名思義就是用於定義微服務對外發布的介面的。在現今比較流行的SOA架構體系裡面，這層用於定義各種restful介面：包括介面的URL，引數、返回值等。這一層模組的職責是做訊息轉發。

訊息介面中不應該有太多業務邏輯，或者說根本就不應該有業務邏輯。它通常是很薄的一層，最多記一下日誌，記一下介面呼叫時的輸入引數和返回值資訊，方便介面聯調時的問題定位。

按照契約化程式設計的思想，介面的所有權歸客戶所有(方法呼叫的Client端)，我們是不能隨意修改的。在有些專案甚至會對定義介面的原始碼檔案加鎖，不允許修改。

業務控制層

這一層就是常說的controller，接收從訊息介面層轉發過來的訊息，呼叫下層的演算法和資料庫訪問介面實現業務處理邏輯。

業務控制層是一個演算法組裝工廠。在演算法層提供了通用的演算法介面，演算法控制層通過呼叫一個或者多個演算法介面完成整個業務流的處理。對於比較簡單的業務(普通的CRUD操作)，它也可以直接呼叫資料適配層介面查詢或者持久化資料。

演算法邏輯層

演算法邏輯層實現資料組裝，模型轉換等所有業務相關的邏輯處理。如果業務邏輯比較簡單，它可能只做一些簡單的資料庫增刪改查介面的呼叫；對於比較複雜的業務它還可以獨立劃分出一些專用的演算法子模組，如果客戶徵信評估演算法模組、電信網路風險評估演算法模組等。

可以在裡面抽象出一個common模組存放與業務相關的公用演算法，供多個應用層演算法使用，避免相同的邏輯每個人都寫一遍。

資料模型層

資料模型層定義了微服務使用的公共業務模型(介面模型也可以定義在這裡面，但是需要通過不同的子模組區分)。

業務模型是非常穩定的，只要資料庫表不做大的改動業務模型是不需要動的，我們可以在演算法邏輯層和資料庫適配層提供基於業務模型的通用方法，不同的介面和演算法可以共用。

介面模型可能會經常變化，新增一個介面或者介面變更都會改介面模型，這個是正常的。演算法邏輯層所做的重要工作就是將資料資訊從業務模型轉換到介面模型。

資料適配層

資料適配層提供訪問資料庫的介面。如果是使用Spring-Mybatis開發，這個一層是就Mapper層。資料庫適配層封裝了底層資料庫的JDBC訪問介面，提供了各種針對不同業務的封裝。

公共處理層

公共處理層提供的是與業務無關的公共方法，如日期時間的處理，字串處理等。公共處理層中還可以定義微服務使用的常量（數字常量、字串常量）和列舉值。