Web服務分層設計模型

引言

如何寫好代碼，是每個程序員都應該去關注的話題。代碼不僅僅是給機器執行的，更是給人看的。我們都希望自己的代碼寫的好看猶如你的外表，但面對複雜業務需求和多人協同時，如果沒有一套基本的原則規範，很難確保不迷失方向。本文就如何寫好代碼的問題，試圖整理出一套規範。

什麼是分層設計

簡單的理解就是，把系統的邏輯功能按照某些原則抽象出幾個層次，層次內保持高類聚，層次間保持低耦合，整個系統達到概念清晰，邊界清晰，最終功能穩定。

分層設計在軟體架構中是比較常見的，比如OSI七層網路模型、計算機系統分層模型。

同樣的，分層設計這種思想也可以擴展到平時寫的業務代碼中。

Web服務分層設計模型

在討論Web服務分層設計模型前，有必要先了解下微服務的概念，畢竟分層設計模型屬於其中的一部分。

The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

上文是 Martin Fowler 給 microservice 的一個解釋。微服務在當下是非常流行的架構，很多公司採用，也有一些開源的框架實現。實施微服務架構有幾個重要的原則：

• 服務化的組件，組件服務化，通過服務介面來暴露組件

• 按業務能力來組織劃分服務

• 面向產品，而不是項目，團隊應該為產品的整個生命周期負責。

• 基礎設施自動化，即應用的構建、集成測試、發布自動化。

• 還有其他幾條原則…

微服務涉及的概念比較多，需要自己去多多閱讀文檔。下圖是一個簡單的架構描述，我們寫的業務代碼通常都是在其中的左側綠色service部分：

針對其中的service層業務，結合實戰中的經驗，總結出以下分層模型：

• Vo: view object

• Bo: business object

• Co: cache object

• Do: database object

上層可以調用下層，下層不可調用上層，同層之間調用看情況：

• Facade層：對外暴露的服務(dubbo)介面，調用不同的service層服務，處理vo2bo/bo2vo的數據轉換，介面版本兼容處理。同層之間不可以調用。

• Service層：業務領域內複雜邏輯處理(cpu計算密集型)和業務之間的數據交換，調用Component層介面獲取數據。同層之間可以調用，可以越過component層調用cache、dao讀介面。

• Component層：相同業務域service公共邏輯下層到本層，調用cache/dao層提供的介面，最小業務處理單元，不可再拆分。相互之間不可以調用。一般業務比較簡單時，可以先不實現component。業務變複雜後，根據情況把公共部分下層到component層。

• Cache層：cache數據讀寫，包括組合的數據對象cache和單純的dao cache，只處理緩存相關的讀寫，調用dao層介面填充cache。同層之間不可以調用。

• Dao層：database層的數據讀寫，負責業務無關操作，如db更新，數據變更觸發的消息推送。一個dao對應一張表。

關於成本

實施微服務架構帶來的開發/運維成本本身就比單體應用高很多，再去做分層處理，開發成本就更高了。因此對於追求業務快速上線的，沒必要以這種方式去實施，但對於基礎中台服務，穩定性、可維護性要求較高，此規範可做參考。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！