系統搭建初期,爲對公司業務進行快速支持,每每搭建的系統很是加單,主要爲了知足快速迭代的需求,使用公司初期的高速發展。 隨着業務的愈來愈繁雜,系統會變得愈來愈複雜,除了須要在技術角度去知足系統的高性能,穩定性,高可用等需求外,設計能夠知足業務需求迭代的架構一樣重要。程序員
爲快速支撐複雜業務能力,系統代碼每每採用類中寫幾千行代碼,一個方法中處處if-else,若是再沒有閱讀性好的代碼和註釋,隨着員工離職,接手的程序員很難快速介入代碼進行開發,反過來則限制了系統業務能力的快速迭代。 最壞的結果可能形成由於愈來愈難以迭代,使得系統推翻重作。spring
系統初期每每採用三層架構方式搭建,上層爲controller,中間層爲service,下層的數據訪問爲dao層。數據庫
Controller編程
Controller層每每推薦只做請求參數和響應參數的處理等一些淺邏輯,好比協議轉換等。數組
業務代碼中,每每按照業務領域劃分和組織代碼結構,好比按照訂單,會員等劃分,這樣一樣能夠在Controller層作好請求到領域內的映射。緩存
好比:架構
主要的原則是:網關內對協議進行處理,將業務邏輯進行收斂,不暴漏給外部,這樣在內部邏輯進行重構時,不須要外界感知變化。異步
Service分佈式
業務層是承載業務流程和業務規則的地方,一樣能夠採用分層方式進行代碼邏輯組織:性能
業務服務層
業務服務層能夠做爲按業務領域劃分的領域對外的接口,每一個接口表明一個領域業務,好比訂單領域內邏輯統一放在Order Service,帳戶領域交給User Service。
在接口指責劃分上,能夠採用讀寫接口分離的原則,好比:Order Read Service和Order Write Service,這樣在將來系統在技術角度須要作讀寫分離處理和流量管理時,能夠減小極大的梳理成本。
接口中功能方法的名稱儘可能有意義,好比訂單建立叫作cereate Order,取消訂單叫作 cancel Order,而不是簡單的增刪改查名稱。
參數組織上如:Request,DO,DTO等。
業務流程層
業務流程表明對於規則的解釋和梳理,規則是將PM的需求翻譯成代碼的過程,因此一樣能夠經過多種標準化動做進行控制:
主要原則是將容易變更的地方作到易修改,易測試,減小新功能迭代時的理解成本。 將不易變更的功能進行拆分,固化,變成可維護的業務組件。
業務組件層
業務組件層是將一些可服用的邏輯,可固化的功能進行內聚封裝,能夠有參數組件,規則判斷組件,動做行爲組件等。
業務組件的造成每每是在對業務理解深入以後演進出來的,過早的抽象每每效果很差。
組件內聚以後可能產生如:短信組件,下單組件扽。
多種組件能夠組合產生業務流程的能力。
Dao
數據訪問層一樣能夠由兩部分組成:接口定義,技術組件。
接口定義
底層數據能力須要和上層業務能力分離,經過設計合理的接口,向業務層屏蔽底層複雜度。 能夠基於面向接口編程的思想設計數據庫訪問接口和緩存訪問接口等。
技術組件
系統隨着業務發展和須要承載的用戶愈來愈多,須要經歷單機,集羣,服務化等多個階段,因此須要沉澱下來一些技術組件,來將多個階段問題進行固化封裝,達到系統發展而業務無需感知的能力。 能夠沉澱的技術組件包括:數據存儲,緩存,消息,調度任務,事務,鎖機制等。
數據存儲,底層能夠封裝訪問關係數據庫,日誌系統HBase,文件系統HDFS,本地文件系統等。
緩存,能夠按照不一樣的超時時間緯度或數據量進行選擇,好比本地內存的Encache,集中式緩存Memcache,集中式可持久化的Redis集羣等,同時能夠將緩存擊穿處理等邏輯進行集成。
消息,在系統中經常用來解決異步處理能力,消息的消費每每和調度任務組合起來,能夠按照調度規則,配置一次或者屢次業務邏輯的處理。
事務,每每採用數據庫實現,單機的事務依賴於數據庫事務,可使用spring-tx的事務進行事務控制,業務邏輯中,事務應該儘可能小,能夠將業務邏輯緊密的數據庫操做放在一塊兒。在分佈式場景下能夠根據不一樣的業務需求選擇不一樣的分佈式事務處理機制。
鎖,主要有兩種:樂觀鎖和悲觀鎖。
經過以上方式咱們能夠提煉出針對於業務系統所須要具有的通用能力,在必定程度上知足了業務系統規則易變的特色,固然不一樣業務場景有本身的要求,很難有銀彈,還須要根據本身的業務場景進行提煉和補充。