淺談各類架構遇到的問題解決方案

在討論分層架構的過程當中，咱們經常會被問答一下幾個問題：

• 1: 是否須要先後端分離，什麼時機分離
• 2: 是否須要服務化，什麼時機服務化
• 3: 是否須要引入DAO層，什麼時機引入
• 4:是否須要抽取通用中臺業務，什麼時機抽取

同道們的這些提問，其實很難回答。在不瞭解業務發展階段，業務規模，數據量併發量的狀況下，妄下YES或NO的結論，自己就是不負責任的。下面我給出一些，咱們架構演進的一些觀點，同時也經歷過系統的一系列的拆分，隨便說說本身的感悟。

1 單體應用階段（第一節段）

如上圖所示，爲應用在單體應用的時候的通常架構圖(咱們用的技術框架以流行的ssm爲例子) 這時候的應用簡單，須要的資源少，能夠徹底支撐起簡單的業務，這時，咱們的包應該會這樣的劃分使用的，好比咱們有3張表A,B,C 這時就與對應的3個entity, 咱們完美的想法是entity與表字段是一 一隊應的(注意：是完美構想)entity 分別是A,B,C 這時也有對應的Mapper接口 對應的CURD,AMapper, BMapper, CMapper, 在業務層的service，咱們也會有這樣的劃分Aservice（AserviceImpl）,Bservice(BserviceImpl), Cservice(CserviceImpl)。 此時，咱們規定AserviceImpl-->AMapper, BserviceImpl-->BMapper,CserviceImpl-->CMapper,咱們是絕對不容許AserviceImpl-->BMapper這種狀況發生的，只能AserviceImpl-->Bservice。這樣會有利於後期服務化應用的拆分，不會產生膠水代碼。 固然，這種狀況每每是咱們想象的完美狀況，可是實際中咱們應用的發展，不會這樣的，好比，咱們有一個統計功能，須要left join A表和B表，這是後，會在entity 中添加一些非表的屬性全部的字段，或新增一個DTO的實體來處理這種狀況，而保留entity 與DB 表的一一對應的純潔性，保持純潔性以有利於咱們對業務的梳理。此時 service 層可能會增長一個Manager層的包，處理各個service的數據聚合的業務處理。manager層中的包不會含有Mapper。

若是此時業務量在迅猛發展(公司資金流和人口紅利大)，須要加入緩存來解決一系列業務的時候，能夠考慮拆分的問題。

這個階段可能會遇到的問題，以及解決方案：

問題	解決方案
restful-code	連接1
MySQL 使用自增ID主鍵和UUID	連接1
單JVM事務傳遞	連接

2 兩段式架構

若是要實施服務化，他的架構多是這樣的：

• 客戶端：型調用方是browser或者APP
• 站點應用層（web-service）：實現核心業務邏輯，從下游獲取數據，對上游返回html或者json
• 業務層(mod-service): 提供服務的業務處理的。
• 數據-緩存層：加速訪問存儲
• 數據-數據庫層：固化數據存儲（可能不是RDBS）

這個階段會遇到的問題，以及解決方案：

問題	解決方案
spring事務	單JVM事務

3 三段式架構

注意，架構分層越多，維護層本就越大，資源的費用也是越大的，這是團隊不斷快速發展，增長人手，快速迭代的分層演進。

這個階段會遇到的問題和解決方案：

問題	解決方案
跨應用的事務處理	連接1 連接2
業界難題-「跨庫分頁」的四種方案	解決方案

4 業務方案

問題	解決方案
淘寶網商品SKU系統設計經驗分享	連接
提一個問題，單JVM 跨庫 的替代事務的方案，和 跨應用多JVM的替代事務方案， 有區別性的考量嗎？	待補充

參考

• http://mp.weixin.qq.com/s/4UB4AZe2R0lVCT6f5ExEMw