從零開始搭建一個通用的業務技術架構，這套架構絕了！

1、通用架構概述

創業之初，我們往往會爲了快速迭代出產品，而選擇最簡單的技術架構，比如 LAMP 架構，SSH 三層架構。這些架構可以適應初期業務的快速發展，但是，隨着業務變得越來越複雜，我們會發現這些架構越來越難支撐業務的發展，出現在一個類中寫好幾千行代碼，一個方法中到處都是 if else 語句，如果中間遇到主程序猿離職，後面介入的程序猿幾乎無法理解這些代碼，到最後，產品越來越難迭代，只能推翻重做。如果我們在創業初始就以一種適應性較強的架構去寫代碼，後面就會少走很多彎路。下面的文章是我自己總結出來的一套架構，經過實踐，適應性還算不錯。

2、通用架構實現

總的來說我的通用架構還是以三層架構爲基礎進行演變的，在經典的三層架構中，最上層的是 controller，中間是 service，下層是 dao。在我的架構中，最上層是網關層，controller 只是網關的一種，中間是業務層，service 只是業務層的入口，最下層是基礎層，dao 只是基礎層中的數據存儲組件。

2.1、網關層

網關層本質上是對不同的網絡協議的請求進行處理，比如 HTTP 協議，TCP 協議，當然，也可以對其他協議進行處理。具體見下圖：

2.1.1、HTTP 請求

一般來自 PC 端和 APP 端的請求都是基於 HTTP 協議的，對於處理 HTTP 請求的方案，業內已經非常成熟了。首先，tomcat 容器本身已經把 HTTP 請求處理的複雜性封裝掉了，其次，spring mvc 對請求處理提供了 RESTful 風格的編碼方式，大大降低了開發的複雜度。我們要做的就是對 controller 按照業務領域劃分，比如按照訂單、會員去劃分大的領域，裏面的各種方法就是這個領域內的操作。這裏的 controller 就是統一網關處理層，對於每個 controller 的方法只做三件事，第一，將請求參數解析出來並組裝成內部參數，第二調用下層服務執行業務邏輯，第三組裝返回結果，對於異常情況，需要記錄異常堆棧日誌並轉換錯誤碼，堆棧信息不要暴露到調用方。

2.1.2、TCP 請求

對於處理 TCP 請求的方案，業內也已經很成熟了，比如 Netty。但是，TCP 請求畢竟太底層，我們往往會基於 TCP 協議去開發自己的協議。另外，很多分佈式框架都是基於 TCP 協議的，比如 RPC 框架 Dubbo，消息框架 RocketMQ 等等。從單機系統到分佈式系統，無非就是網關層多了處理 TCP 請求的邏輯，理論上底層的業務是無需感知自己到底是出於單機環境還是分佈式環境，網關層的作用就是要屏蔽這種不同外部調用源的細節。在 Dubbo 服務端中，我們需要實現遠程接口，並對遠程服務調用進行內部的轉發，轉發的邏輯也很簡單，首先是解析參數並組裝內部參數，然後調用業務層的接口執行業務邏輯，最後組裝返回結果，對於異常處理也需要在這裏做掉，防止異常暴露給外部應用。

2.1.3、小結

網關層本質是對協議進行處理，同時將業務邏輯收斂到網關層，而不是暴露給外部，當內部業務邏輯進行重構的時候，外部調用方就不需要感知這些變化，當外部調用源增加時，內部業務邏輯不需要感知這種變化，從而將外部調用方和內部業務邏輯進行了解耦。

2.2、業務層

業務層是一個系統，無論是單機系統還是分佈式系統羣中的某個業務系統，業務層都是承載業務流程和規則的地方。業務層從外到內包含三層：第一層是業務服務，第二層是業務流程，第三層是業務組件。具體如下圖：

2.2.1、業務服務

業務服務是業務層對外的統一門面，它由三方面組成：業務接口、入參、出參。另外，搜索公衆號 Linux 就該這樣學後臺回覆 “電子書”，獲取一份驚喜禮包。

a) 業務接口

一個業務接口代表一個領域的業務服務，比如訂單域的業務服務就由接口 OrderService 表示，會員域的業務服務就由接口 MemberService 表示。接口可以按照執行性質分爲讀接口和寫接口，比如 OrderReadService 和 OrderWriteService。讀寫分離的好處是可以對集羣進行讀寫分組，從而管理流量，當然，單機系統讀寫分離意義不是太大。領域內的操作則以業務接口中的方法的形式體現，比如訂單域有下單 createOrder，取消訂單 cancelOrder 等等操作。對於這些操作，儘量設計出有業務含義的方法，而不是增刪改查，當然，對於一些簡單的業務，也只能增刪改查。

b) 入參

接下來，是入參的設計。入參對於讀方法，比較簡單，不做討論。對於寫方法，我們將入參設計成有層次的數據模型。首先需要設計出公共的數據模型，比如訂單數據模型，商家數據模型，商品數據模型等，然後將這些數據模型和一些特定業務下的個性數據結合，組成 Request 對象，這個 request 對象按照不同業務操作不同而不同，對應的返回結果就是 response，它也是隨着不同業務返回的參數不同。

舉個例子，拿下餐飲訂單來說，首先，我們應該識別出這些業務流程中一些比較基礎的數據模型，比如餐飲領域的菜品、桌位等，這些模型之所以說是基礎模型，是因爲，不管下什麼餐飲訂單，菜品和桌位肯定是逃不了的，它們是可以被複用的！因此，我們分別爲這些基礎模型設計相對於的 DO（Domian Object）:DishDO（菜品）、BoardDO（桌位）等等，接下來，我們爲下餐飲訂單設計一個請求對象 DishOrderCreateRequest 其中 DishOrderCreateRequest 內部包含了 DishDO 和 BoardDO，另外會包含一些特定的屬性，比如人數啊，折扣啊等等，這樣一來就能做到通用和靈活兼顧，DishOrderCreateRequest 代表的個性化的靈活的業務入參，而 DishDO 和 BoardDO 等則代表了不易變化的基礎模型。

c) 出參

最後，是出參的設計。對於寫方法，一般出參比較簡單。對於讀方法，出參往往是一個結構與層次比較複雜的組合對象。比如查詢一個訂單，這個訂單有訂單基本信息，還有商品信息，收貨人地址信息等。在設計出參的時候，結構上要設計成組合對象，但是真正查詢的時候，通過查詢選擇器，去查詢不同的組合對象。比如查詢選擇器設置商品查詢爲 true，地址查詢爲 false，那麼這次查詢出的訂單就只包含商品，而不包含地址。

2.2.2、業務流程

業務流程其實就是對業務規則的解釋，只是這種解釋使用代碼去實現的，我們要做的其實就是準確翻譯這些業務規則，並維護好這些業務規則。

業務流程中可以大致分爲三種動作節點，1、組裝參數節點  2、規則判斷節點  3、執行動作節點，其中每個動作節點都是一些業務代碼的片段。舉個例子，下餐飲訂單，我們第一步就是將上層傳入的參數組裝出一個基礎的 DishOrderDO（組裝參數節點），然後按照特定的規則去填充這個 DishOrderDO（規則判斷節點），然後就是調用 DAO 去創建 DishOrderDO（執行動作節點）。

業務流程是最容易變化的地方，要想維護好業務流程並不容易，總的思想是將大的業務流程拆分成小的業務流程，抽出每個業務流程中共有的代碼片段，變成可維護的業務組件。

2.2.2、業務組件

a) 基礎組件

業務組件其實是將一些內聚的可複用的代碼片段進行封裝。和業務流程中的三種業務節點相對應，業務組件也分爲三種：組裝參數組件 、規則判斷組件 、動作執行業務組件。業務組件的抽象往往是對業務有了深刻理解之後才進行的，盲目地進行業務組件的抽象，往往到頭來白忙活。

b) 能力

對業務組件進行進一步抽象，可以得到能力。業務能力是具有一定複用性的組件的組合，比如發短信能力 = 組裝短信參數組件 + 發短信組件。對於發短信能力，可以被不同的業務流程複用，比如訂單下單成功發短信，支付成功發短信，邏輯都是相似的，只有內容不同。能力是一種粒度比較大的組件，粒度越大，往往復用性就越小，對能力的抽取，也是基於對特定業務深刻的理解，沒有一勞永逸的銀彈。

c) 更高緯度的抽象

經過本人的實踐，對於互聯網這樣的需求變化極快的場景，更高緯度的組件抽象往往性價比很低，不建議大家去做。

2.3、基礎層

基礎層包含兩個部分，第一是接口定義，第二是技術組件。

2.3.1、接口定義

接口定義是按照不同的技術框架，同時結合業務需要，設計出合理的接口，對於業務組件來說，它們只會感知技術接口，而不會去感知技術實現，我們也不應該將具體的技術細節向上暴露，這也就是所謂的面向接口編程。技術接口往往是業務與技術之間的橋樑，接口本身是含有業務含義的，最常見的就是 DAO 接口，我們設計 DAO 接口的時候，不會設計成 insert、update、query 這樣業務無關的接口，而是設計成 insertUser，updateUserById 等等和業務相關的接口，同樣的道理，設計緩存接口的時候，也不能設計成 put、get 這樣的接口，而應該設計成 cacheUser，deprecateUser 這樣的接口。

2.3.2、技術組件

單機系統的技術組件一般來說分兩種，一種是通用的技術組件，比如：數據存儲、緩存、消息和調度任務、事務、鎖。一種是基礎設施，比如 spring 容器，tomcat 容器。下面稍微談談通用技術組件。

數據存儲：數據存儲包括關係型數據庫、非關係型數據庫以及文件存儲系統。關係型數據庫，比如 MySQL，適合存放絕大部分業務數據。非關係型數據庫，比如 hbase，可以存放歷史日誌，也可以對歷史的 MySQL 數據進行歸檔。文件存儲系統，一般都是基於 Linux 文件系統，比如圖片、html 文件等等，也有基於 HDFS 的，用於大數據分析。

緩存：緩存按響應時間分，可以分爲納秒級緩存，毫秒級緩存和百毫秒級緩存。納秒級緩存就是一般的基於本地內存的緩存，比如 encache，毫秒級緩存一般是集中式的內存緩存，比如 memcache，由於訪問時遠程調用，因此響應時間會延長到幾毫秒，百毫秒級緩存一般是集中式可持久化的緩存，比如 redis，由於存在遠程訪問以及緩存擊穿導致的讀取持久化記錄，它的響應時間會更長些，到幾十甚至上百毫秒。單機系統一般用本地內存緩存就夠了，當緩存被擊穿的時候，直接訪問數據庫。

消息和調度任務：消息和調度任務本質都是一種異步化的手段，區別在於消息無法控制異步的時間，而調度任務可以。一般，消息發送出去後，監聽消息的系統會立即收到消息，從而立即觸發業務邏輯的執行，而調度任務則會按照調度規則，一次或者多次的執行業務邏輯。單機系統中消息和調度任務用到的比較少，在做日誌監控的時候可能會用到消息，在進行數據報表統計的時候可能會用到調度任務。

事務：事務本質都是基於數據庫去實現的，單機系統的事務就是依賴數據庫的事務，我們可以使用 spring-tx 的事務模板進行事務操作，在業務邏輯開發中，一定要把握事務的大小，建議把業務比較緊密的一堆數據庫操作放在一個事務裏，不要隨意的爲每個方法都開啓事務。

鎖：單機系統中主要用到兩種鎖：樂觀鎖和悲觀鎖。樂觀鎖依靠在數據庫的業務表加版本字段來實現，每次更新都會去判斷版本是否變化，如果變化則需要重試，這種鎖的粒度比較小。悲觀鎖是基於 JDK 的 Lock 接口的，對一個業務流程進行加鎖和釋放鎖的操作，鎖的粒度比較粗。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/OaDJ_D4XI0XM0qmfMXHBzA