現在大型專案的設計架構都是進行服務精細化、微服務的設計。最近也是接觸到真實億級流量專案，大致記錄一下較為優秀的專案結構設計。不過師傅也說，總有更精妙的架構設計，只是目前我還沒有見過，所以本文只是記錄一些粗鄙之見。
為了方便說明，這裡舉個例子，比如我們有個簡單的網售咖啡**，網售咖啡平台專案名為 祺平（qpcoffee）。我們整個咖啡零售分為管理後台、首頁門戶、訂單支付、發貨售後等等服務，每個服務我們可以對應建立乙個微服務專案，來實現所有的功能。
我們四個服務對應設計八個微服務，每個微服務最終都可以進行打包構建成docker映象，啟動多個容器例項，整個系統部署成分布式集群應用，最終支撐起整個咖啡館的業務流量。
所有的工程服務分別如下：
服務名工程名
門戶核心介面服務
qpcoffee-api
門戶核心任務服務
qpcoffee-task
管理後台介面服務
qpcoffee-console-api
管理後台任務服務
qpcoffee-console-task
訂單支付介面服務
qpcoffee-order-api
訂單支付任務服務
qpcoffee-order-task
發貨售後介面服務
qpcoffee-delivery-api
發貨售後任務服務
qpcoffee-delivery-task
對於任意 qpcoffee-***-api 和 qpcoffee-***-task 一組的兩個微服務，我們可以在乙個專案/工程 qpcoffee-*** 中進行實現，api 負責暴露 http 介面，task 負責一些後台任務，比如經常執行類似統計分析使用者消費習慣等排程任務（這一塊可以涉及一些分布式任務排程）。
以 qpcoffee-console-api 和 qpcoffee-console-task 兩個微服務舉例，我們需要搭建乙個名為 qpcoffee-console 的工程，該工程下所包含的模組如下：
模組名功能
qpcoffee-console-api
負責最上層暴露http介面
qpcoffee-console-core
負責核心業務實現，主要包括service層業務邏輯實現
qpcoffee-console-contract
負責暴露一些rpc服務介面，dto，相關列舉類，以及請求本服務的出入引數等
qpcoffee-console-intergation
負責呼叫其他服務的rpc介面，引入其他服務的contract包，封裝呼叫方法
qpcoffee-console-repository
負責封裝資料層的操作，包括db、快取、大資料等的操作
qpcoffee-console-domain
主要包含一些領域模型，比如資料庫的實體對映等等
qpcoffee-console-common
主要包含一些通用性元件，比如工具類、自定義異常、常量
qpcoffee-console-task
負責最上層實現一些後台任務
我們在專案搭建時，需要考慮模組間的依賴關係。根據上面描述的模組職責，可以較為統一的設計出模組間的依賴關係如下：
以上是對整個專案的乙個結構設計，具體在各個模組間的資料流動則依靠各種領域物件。對於各個層之間的互動的領域物件，主要可以分為以下：
領域物件
含義使用
do（data object）
資料物件，和資料庫字段一一對應
用於repository層，由於orm的存在，do在這一層作為資料互動的物件
dto（data transfer object）
資料傳輸物件，用於rpc層的物件傳輸
用於core模組中的service層暴露rpc服務時的傳輸物件
vo （view object）
檢視物件，用於展示檢視的物件
用於api模組中的controller層暴露http介面時返回的檢視物件
bo （business object）
業務biz使用物件，可能會組裝多個其他物件
可能業務需要，進行組裝多個物件中的屬性
request
請求引數物件
前端post請求傳入引數封裝物件
配合我們的專案結構，具體的使用如下：
所有微服務開發完畢後需要進行部署執行。我們這樣設計的乙個微服務架構，其實是較為方便解耦的。
首先我們利用打包工具將所有的 qpcoffee-***-contract 進行打成jar包，便於上游其他服務呼叫rpc介面；然後將所有的微服務構建成容器映象，並部署到多台機器即可；最終整個分布式集群的應用跑起來，提供服務。
微服務軟體架構設計
在軟體內部經過綜合各種因素考量 權衡，選擇特定的技術，將系統劃分為不同的部分並使用這些部分相互分工，彼此協作，為使用者提供需要的價值 軟體架構進化考慮的因素 傳統架構 單體架構 概念優勢 挑戰微服務架構 定義使用一套小服務來開發單個應用的方式，每個服務執行在單獨的程序，一般採用輕量級的通訊機制互聯，...
微服務架構設計模式綜述
隨著微服務的大量應用，在實踐中也會遇到很多之前單體架構所沒有的問題，微服務架構設計模式也應運而生。架構方面的權威chris richardson先生從多個角度歸納了42個設計模式，我將其歸納整理如下表，以饗讀者。後面會陸續出關於微服務架構設計模式的文章，更加深入的闡述richardson先生關於微服...
架構設計之 微服務入門
微服務這幾年不可謂不火，很多技術團隊都開始在自己的專案上引入了微服務。一方面這些團隊確實很好的推動了微服務的應用和發展，另一方面也可以看到一些盲目追技術熱點的行為所帶來的危害，比如很多中小團隊對微服務的基礎知識只是做了很淺顯的了解就開始盲目的推動微服務的實施，最後導致了專案的失敗。微服務要想做好是乙...