幾經實踐，阿里架構師提煉出這份通用的業務技術架構
創業之初，我們往往會為了快速迭代出產品，而選擇最簡單的技術架構，比如LAMP架構，SSH三層架構。這些架構可以適應初期業務的快速發展。
但是，隨著業務變得越來越複雜，我們會發現這些架構越來越難支撐業務的發展，出現一個類中寫好幾千行程式碼，一個方法中到處都是if else語句，如果中間遇到主程式猿離職，後面介入的程式設計師幾乎無法理解這些程式碼，到最後，產品越來越難迭代，只能推翻重做。
如果我們在創業初始就以一種適應性較強的架構去寫程式碼，後面就會少走很多彎路。下面的文章是我自己總結出來的一套架構，經過實踐，適應性還算不錯。
二、通用架構實現
總的來說我的通用架構還是以三層架構為基礎進行演變的，在經典的三層架構中，最上層的是controller，中間是service，下層是dao。
在我的架構中，最上層是閘道器層，controller只是閘道器的一種，中間是業務層，service只是業務層的入口，最下層是基礎層，dao只是基礎層中的資料儲存元件。
1、閘道器層
閘道器層本質上是對不同的網路協議的請求進行處理，比如HTTP協議，TCP協議，當然，也可以對其他協議進行處理。具體見下圖：
HTTP請求
一般來自PC端和APP端的請求都是基於HTTP協議的，對於處理HTTP請求的方案，業內已經非常成熟了。
-
首先，Tomcat容器本身已經把HTTP請求處理的複雜性封裝掉了；
-
其次，Spring MVC對請求處理提供了RESTful風格的編碼方式，大大降低了開發的複雜度。
我們要做的就是對controller按照業務領域劃分，比如按照訂單、會員去劃分大的領域，裡面的各種方法就是這個領域內的操作。
這裡的controller就是統一閘道器處理層，對於每個controller的方法只做三件事：
-
第一，將請求引數解析出來並組裝成內部引數；
-
第二呼叫下層服務執行業務邏輯；
-
第三組裝返回結果，對於異常情況，需要記錄異常堆疊日誌並轉換錯誤碼，堆疊資訊不要暴露到呼叫方。
TCP請求
對於處理TCP請求的方案，業內也已經很成熟了，比如Netty。 但是，TCP請求畢竟太底層，我們往往會基於TCP協議去開發自己的協議。
另外，很多分散式框架都是基於TCP協議的，比如RPC框架Dubbo，訊息框架RocketMQ等等。從單機系統到分散式系統，無非就是閘道器層多了處理TCP請求的邏輯，理論上底層的業務是無需感知自己到底是出於單機環境還是分散式環境，閘道器層的作用就是要遮蔽這種不同外部呼叫源的細節。
在Dubbo服務端中，我們需要實現遠端介面，並對遠端服務呼叫進行內部的轉發，轉發的邏輯也很簡單，首先是解析引數並組裝內部引數，然後呼叫業務層的介面執行業務邏輯，最後組裝返回結果，對於異常處理也需要在這裡做掉，防止異常暴露給外部應用。
小結
閘道器層本質是對協議進行處理，同時將業務邏輯收斂到閘道器層，而不是暴露給外部。當內部業務邏輯進行重構的時候，外部呼叫方就不需要感知這些變化，當外部呼叫源增加時，內部業務邏輯不需要感知這種變化，從而將外部呼叫方和內部業務邏輯進行了解耦。
2、業務層
業務層是一個系統，無論是單機系統還是分散式系統群中的某個業務系統，業務層都是承載業務流程和規則的地方。業務層從外到內包含三層：第一層是業務服務，第二層是業務流程，第三層是業務元件。具體如下圖：
1）業務服務
業務服務是業務層對外的統一門面，它由三方面組成：業務介面、入參、出參。
業務介面
一個業務介面代表一個領域的業務服務，比如訂單域的業務服務就由介面Order Service表示，會員域的業務服務就由介面Member Service表示。
介面可以按照執行性質分為讀介面和寫介面，比如Order Read Service和Order Write Service。讀寫分離的好處是可以對叢集進行讀寫分組，從而管理流量，當然，單機系統讀寫分離意義不是太大。
領域內的操作則以業務介面中的方法的形式體現，比如訂單域有下單create Order，取消訂單cancel Order等等操作。對於這些操作，儘量設計出有業務含義的方法，而不是增刪改查，當然，對於一些簡單的業務，也只能增刪改查。
入參
接下來，是入參的設計。入參對於讀方法，比較簡單，不做討論。對於寫方法，我們將入參設計成有層次的資料模型。
首先需要設計出公共的資料模型，比如訂單資料模型，商家資料模型，商品資料模型等，然後將這些資料模型和一些特定業務下的個性資料結合，組成Request物件，這個request物件按照不同業務操作不同而不同，對應的返回結果就是response，它也是隨著不同業務返回的引數不同。
舉個例子，拿下餐飲訂單來說，首先，我們應該識別出這些業務流程中一些比較基礎的資料模型，比如餐飲領域的菜品、桌位等，這些模型之所以說是基礎模型，是因為，不管下什麼餐飲訂單，菜品和桌位肯定是逃不了的，它們是可以被複用的！
因此，我們分別為這些基礎模型設計相對於的DO（Domian Object）：Dish DO（菜品）、Board DO（桌位）等等，接下來，我們為下餐飲訂單設計一個請求物件Dish Order Create Request其中Dish Order Create Request內部包含了Dish DO和Board DO，另外會包含一些特定的屬性，比如人數啊，折扣啊等等。
這樣一來就能做到通用和靈活兼顧，Dish Order Create Request代表的個性化的靈活的業務入參，而Dish DO和Board DO等則代表了不易變化的基礎模型。
出參
最後，是出參的設計。
-
對於寫方法，一般出參比較簡單。
-
對於讀方法，出參往往是一個結構與層次比較複雜的組合物件。
比如查詢一個訂單，這個訂單有訂單基本資訊，還有商品資訊，收貨人地址資訊等。在設計出參的時候，結構上要設計成組合物件，但是真正查詢的時候，通過查詢選擇器，去查詢不同的組合物件。比如查詢選擇器設定商品查詢為true，地址查詢為false，那麼這次查詢出的訂單就只包含商品，而不包含地址。
2）業務流程
業務流程其實就是對業務規則的解釋，只是這種解釋使用程式碼去實現的，我們要做的其實就是準確翻譯這些業務規則，並維護好這些業務規則。
業務流程中可以大致分為三種動作節點：
-
組裝引數節點；
-
規則判斷節點；
-
執行動作節點。其中每個動作節點都是一些業務程式碼的片段。
舉個例子，下餐飲訂單，我們第一步就是將上層傳入的引數組裝出一個基礎的Dish Order DO（組裝引數節點），然後按照特定的規則去填充這個Dish Order DO（規則判斷節點），然後就是呼叫DAO去建立Dish Order DO（執行動作節點）。
業務流程是最容易變化的地方，要想維護好業務流程並不容易，總的思想是將大的業務流程拆分成小的業務流程，抽出每個業務流程中共有的程式碼片段，變成可維護的業務元件。
3）業務元件
基礎元件
業務元件其實是將一些內聚的可複用的程式碼片段進行封裝。和業務流程中的三種業務節點相對應，業務元件也分為三種：組裝引數元件、規則判斷元件、動作執行業務元件。
業務元件的抽象往往是對業務有了深刻理解之後才進行的，盲目地進行業務元件的抽象，往往到頭來白忙活。
能力
對業務元件進行進一步抽象，可以得到能力。業務能力是具有一定複用性的元件的組合，比如發簡訊能力=組裝簡訊引數元件+發簡訊元件。
對於發簡訊能力，可以被不同的業務流程複用，比如訂單下單成功發簡訊，支付成功發簡訊，邏輯都是相似的，只有內容不同。
能力是一種粒度比較大的元件，粒度越大，往往復用性就越小，對能力的抽取，也是基於對特定業務深刻的理解，沒有一勞永逸的銀彈。
更高緯度的抽象
經過本人的實踐，對於網際網路這樣的需求變化極快的場景，更高緯度的元件抽象往往價效比很低，不建議大家去做。
3、基礎層
基礎層包含兩個部分，第一是介面定義，第二是技術元件。
1）介面定義
介面定義是按照不同的技術框架，同時結合業務需要，設計出合理的介面，對於業務元件來說，它們只會感知技術介面，而不會去感知技術實現，我們也不應該將具體的技術細節向上暴露，這也就是所謂的面向介面程式設計。
技術介面往往是業務與技術之間的橋樑，介面本身是含有業務含義的，最常見的就是DAO介面，我們設計DAO介面的時候，不會設計成Insert、Update、Query這樣業務無關的介面，而是設計成Insert User，Update User By Id等等和業務相關的介面。
同樣的道理，設計快取介面的時候，也不能設計成put、get這樣的介面，而應該設計成cache User，deprecate User這樣的介面。
2）技術元件
單機系統的技術元件一般來說分兩種，一種是通用的技術元件，比如：資料儲存、快取、訊息和排程任務、事務、鎖。一種是基礎設施，比如Spring容器，Tomcat容器。下面稍微談談通用技術元件。
資料儲存
資料儲存包括關係型資料庫、非關係型資料庫以及檔案儲存系統。
-
關係型資料庫，比如MySQL，適合存放絕大部分業務資料。
-
非關係型資料庫，比如HBase，可以存放歷史日誌，也可以對歷史的MySQL資料進行歸檔。檔案儲存系統，一般都是基於Linux檔案系統，比如圖片、HTML檔案等等，也有基於HDFS的，用於大資料分析。
快取
快取按響應時間分，可以分為納秒級快取，毫秒級快取和百毫秒級快取。
-
納秒級快取就是一般的基於本地記憶體的快取，比如Encache；
-
毫秒級快取一般是集中式的記憶體快取，比如Memcache，由於訪問時遠端呼叫，因此響應時間會延長到幾毫秒；
-
百毫秒級快取一般是集中式可持久化的快取，比如Redis，由於存在遠端訪問以及快取擊穿導致的讀取持久化記錄，它的響應時間會更長些，到幾十甚至上百毫秒。單機系統一般用本地記憶體快取就夠了，當快取被擊穿的時候，直接訪問資料庫。
訊息和排程任務
訊息和排程任務本質都是一種非同步化的手段，區別在於訊息無法控制非同步的時間，而排程任務可以。
一般，訊息傳送出去後，監聽訊息的系統會立即收到訊息，從而立即觸發業務邏輯的執行，而排程任務則會按照排程規則，一次或者多次的執行業務邏輯。
單機系統中訊息和排程任務用到的比較少，在做日誌監控的時候可能會用到訊息，在進行資料報表統計的時候可能會用到排程任務。
事務
事務本質都是基於資料庫去實現的，單機系統的事務就是依賴資料庫的事務，我們可以使用spring-tx的事務模板進行事務操作，在業務邏輯開發中，一定要把握事務的大小，建議把業務比較緊密的一堆資料庫操作放在一個事務裡，不要隨意的為每個方法都開啟事務。
鎖
單機系統中主要用到兩種鎖：樂觀鎖和悲觀鎖。
-
樂觀鎖依靠在資料庫的業務表加版本欄位來實現，每次更新都會去判斷版本是否變化，如果變化則需要重試，這種鎖的粒度比較小。
-
悲觀鎖是基於JDK的Lock介面的，對一個業務流程進行加鎖和釋放鎖的操作，鎖的粒度比較粗。
三、總結
以上是我經過很長一段時間的實踐後摸索出來的業務技術架構，自認為還算通用，而且能夠在一定程度上支撐易變的業務。
當然這套架構肯定不是銀彈，不可能解決所有業務場景，所以最終還是需要圍繞到具體的場景加以借鑑。