【引言】
如今移動網際網路行業呈爆發式發展，隨著業務使用者規模和業務邏輯趨向複雜，後端系統的開發和維護變得越來越困難，目前業界湧現出各種各樣的技術文章介紹分散式快取設計、分散式資料庫設計、負載均衡、HA策略等等，這些都是支撐分散式資料訪問層的基石，不過，我從另一個角度探討分散式資料訪問層 (Data Access Layer)的框架設計。
本文要介紹的是2-3法則（2個維度，3個原則）在分散式DAL框架設計中的指導原則，兩者共同完成DAL層封裝，主要分為兩點：1）從水平與垂直維度正交分析業務系統設計；2）定義3條必須遵守的設計原則，最重要的是DAL層從水平維度抽象資料訪問策略模型，即個3原則中的第3條。
文章的最後一節，對分散式資料訪問框架做了探討，提出了兩種實現框架的思路。
【分散式DAL解決的問題】
在分散式系統中，每一臺伺服器都需要訪問本地快取、分散式MC快取、分散式後臺資料庫，對於同一個業務模組，隨著業務變複雜，需要定義越來越多的資料Model，按照一定的規則儲存在本地快取、分散式快取以及後臺資料庫中。
目前，業界的資料訪問層定位於應用程式與持久化資料庫之間，比如淘寶的TDDL、IBatis Sharding等，主要完成資料的分庫分表、讀寫分離等，本文的資料儲存涵蓋快取、資料庫、檔案系統，現有的資料庫DAL中介軟體、Redis客戶端、MC客戶端將作為本文的水平維度的Adaptor，主要解決的問題：
- 資料訪問在水平資料儲存維度的一致性問題。
- 快速增加資料Model的能力。
- 優雅、清晰、模組化的資料訪問層程式碼。
【兩個維度抽象設計】
對於上節的問題，下面列舉了水平和垂直維度抽象思考例子。
假設水平維度：
- 部分熱資料儲存在本地快取，本文使用ehCache。
- 部分熱資料儲存在前端快取中，本文使用MC。
- 全量資料儲存在資料庫快取，本文使用MySQL。
假設垂直維度：
- 資料模型FileMeta，需要同時儲存在LocalCache、Redis和MySQL中。
- 資料模型BlockMeta，需要儲存在LocalCache、MC中。
- 資料模型Context，需要儲存在MC、MySQL中。
按照上面的分析，我們畫出系統兩個維度正交設計圖，如下：
【Composition 而不是Inheritance】
我們可以想到垂直維度定義N = 3個資料模型介面，水平維度定義N = 3個分層介面，但是水平維度和垂直維度是什麼關係呢？
在本文的設計中，對問題做了進一步思考，水平維度的介面全部由垂直維度的資料模型介面組合（Composition）而成，完成所有業務只需要定義N + M + 1個介面，而不是N * M + 1個介面，多餘的那個是DAL介面，完成資料訪問層封裝工作，第一節例子中的介面定義見下圖：
【設計原則】
上節主要介紹了介面設計，這裡說一下實現，資料模型類非常簡單，只要MC Client、TDDL、ehCache在不同層完成相應介面實現，最重要的是DAL實現類，需要完成水平各個維度的策略儲存，比如對一個Model，順序寫入MC和MySQL，根據業務實踐經驗，總結出3條設計原則：
- 每一個資料模型都有CRUD方法，即資料操作的增刪改查，對於MC或者LocalCache來說，增加操作和修改操作可能是一致的，這種情況也必須嚴格定義CRUD方法。
- DAL層封裝所有的資料訪問，保證資料的一致性儲存和可靠性，DAL層的實現呼叫ILocalCacheService、IMCService、IDAOService，根據不同資料模型的儲存策略，分別去呼叫快取和資料庫服務，資料模型如果僅存在MySQL或者MC，也需要在DAL層做封裝，這樣雖然對開發效率有一定影響，但是整體開發和維護成本降低很多。
- DAL實現抽象出一個DALContext和一個Executor，對於不同的資料模型，配置出不同的DALContext，比如順序儲存在MC和MySQL或者同步寫入MC非同步寫入MySQL，DAL也需要負責出錯處理、水平維度的容災切換等。
【分散式資料訪問框架】
對於網際網路後端應用來說，最主要的功能就是處理資料，對DAL層的探索與優化是非常有價值的，基於本文提出的2-3法則，感興趣的讀者可以構建一個DAL開源專案，有兩種思路。
第一種思路是：
- 定義資料模型以及儲存配置策略規範，可以使用類似protobuf的規範。
- 根據業務定義的資料模型和儲存配置策略，生成業務程式碼。
- 開發者在此基礎上擴充完善業務程式碼。
第二種思路是：
- 定義資料模型以及儲存配置策略規範，可以使用類似protobuf的規範。
- 開發DAL中介軟體（容器），根據業務定義的資料模型和儲存配置策略，執行時完成所有的資料訪問操作代理。
第一種相對容易，第二種比較複雜，讀者可以自己選擇其中一種,這是架構系列的第一篇，後面還有更多。