Java生鮮電商平臺-生鮮系統中微服務架構設計與分析實戰

Java生鮮電商平臺-生鮮系統中微服務架構設計與分析實戰

說明: Java生鮮系統中微服務的拆分應該如何架構設計與分析呢？如下是個人實戰中的設計與經驗分析。

目錄

1. 微服務簡介
2. 當前現狀
3. 特色
4. 原則
5. 目標
6. 整體架構設計
6.1. 業務架構
6.2. 邏輯架構
6.3. 應用架構
6.4. 數據架構
6.5. 數據層次劃分
6.6. 技術架構
6.6.1. 分層設計
6.6.2. 邏輯技術架構

1. 微服務簡介

近年來，在生鮮行業，生鮮電商軟件開發領域關於微服務的討論呈現出火爆的局面，愈來愈多的公司企業傾向於在系統設計與開發中採用微服務方式實現軟件系統的鬆耦合、跨部門開發，被認爲是IT軟件架構的將來方向，Martin Fowler也給微服務架構極高的評價；同時，反對之聲也很強烈，持反對觀點的人表示微服務增長了系統維護、部署的難度，致使一些功能模塊或代碼沒法複用，同時微服務容許使用不一樣的語言和框架來開發各個系統模塊，這又會增長系統集成與測試的難度，並且隨着系統規模的日漸增加，微服務在必定程度上也會致使系統變得愈來愈複雜。儘管一些公司已經在生產系統中採用了微服務架構，而且取得了良好的效果；但更多公司仍是處在觀望的態度。

什麼是微服務架構呢？簡單說就是將一個完整的應用（單體應用）按照必定的拆分規則（後文講述）拆分紅多個不一樣的服務，每一個服務都能獨立地進行開發、部署、擴展。服務於服務之間經過注入RESTful api或其餘方式調用。

 

原架構

 

微服務架構

2. 當前現狀

• 舊有平臺通用性不夠全面，在項目集成過程當中對原有系統業務侵入性高

• 缺少對系統平臺的用戶基礎權限、數據權限及數據字典等通用基礎功能共性維護

• 平臺側的用戶相關權限資源配置維護繁雜，不易集中管理

• 缺少統一的WEB UI標準式封裝，致使項目不少模塊風格迥異

• 開發效率低，缺少自動化生成策略

• 不支持多數據配置，致使項目很難進行讀寫的剝離

• 缺少專業接口對接機制，接口制式多種，更無接口標準API文檔，不利於客戶端對接

• 缺少統一的接口安全機制，可細化控制接口程度低，不利於數據安全

• 系統依舊採用傳統的MVC架構，較爲保守，橫向擴展性差

• 各個模塊之間高度集成，抗風險能力弱.

3. 特色

   系統架構整體設計上體現模塊化，每一個模塊均可以做爲獨立的個體，且獨立運營，傾向於分佈式、去中心化，以便於版本長期迭代。

 

• 使用靈活，能夠整個使用，也能夠只用其一個或幾個部分

• 學習成本低，上手容易

• 核心功能的穩定性，且儘可能少的第三方框架及包

• 應用架構的外延性、連續性，便於集成、複用

• 易於知識積累，真正作到越用越強

• 易於集羣與水平擴展，能作到不間斷提供服務

• 針對業務模塊之間的關係進行解耦

• 無狀態服務，對每次請求的服務器處理是沒有影響的。可使用負載均衡技術（須要解決Session同步問題），實現高可用

在大多數狀況下，若是須要同步更新不少個服務則說明系統的耦合還不夠低，固然咱們也不可能徹底避免耦合，它老是會出如今某些場景下。爲此須要咱們總結提煉一些抽象層將服務之間的交互定在契約上來避免複雜，提高靈活性。這就要求咱們在一開始設計過程當中就要有一種辨別能力，可以找到那些必須放在一塊兒來作處理而不能拆解的功能。若是這些功能是值得放在一塊兒的，那咱們就能夠將它獨立成一個微服務，遵循高聚合的設計緣由。

4. 原則

• 兼容開放式原則：兼容已有技術，避免對系統的顛覆式改造

• 先進性和靈活性原則：採用目前主流的先進的技術、方法，知足系統不斷增長和調整的業務需求；經過修改流程的相關配置文件實現流程的發佈或更新，縮減系統改造週期

• 實用性原則：系統應具備良好的用戶界面，操做簡單方便。充分考慮錄入人員特色，使數據處理工做簡單、方便、快捷，業務流程清晰，符合常規業務處理習慣；對於經常使用的信息查詢操做，系統提供靈活多樣的查詢和統計檢索方式，知足不一樣層次的用戶需求

• 減法原則：從技術經理、技術骨幹到開發人員，工做量範圍與內容愈來愈少

• 高效、經濟：自動組裝、複用資產模塊，由框架進行自動組裝，避免大量的系統配置，同時避免相關參與者作重複的事情

• 約定優於配置：經過約定減小代碼及配置量

5. 目標

   構建基礎框架，同時可以與已有的應用模塊集成，實如今原有的業務上不斷運行。

• 統一的信息整合平臺，將現有的應用系統、資源進行整合，打破系統建設孤島、嚮應用的產品化發展

• 及時、準確、客觀的同互聯網接規，爲產品的多元化提供技術支持

• 架構支持可靈活定製、拓展，實現模塊標準化、通用化，可根據業務須要，與新創建的業務系統有效集成

• 業務系統維護實現分佈式管理，去中心化

• 實現用戶統一的用戶、角色權限、統一日誌、運維監控集中管理

• 實現統一的信息展現

• 業務系統維護直觀、操做簡便、無需專門技術人員

除上述目標外，該系統從設計方面，應兼顧穩定性、操做性、擴展性、先進性、可維護性、安全性等重要原則，在穩定、安全的基礎上能夠隨着業務的發展逐步擴展。

6. 整體架構設計

6.1. 業務架構

採用當前業界流行的微服務架構，遵循統一技術路線，架構設計注重層間的鬆耦合與層間的高內聚，經過對業務對象的抽象內聚，組件化服務模塊，統一服務調用，考慮的拓展性、穩定性、複用性以及可配置性，下降了維護成本和開發成本，使得系統變得更輕量化，可以知足業務不斷的變化帶來的架構挑戰。

以核心功能爲基礎、以公共平臺爲紐帶、服務能力高度共享的分佈式架構體系

• 系統架構新特性：微服務化、服務治理自動化，服務能力開放自動化；自動構建、自動發佈，一鍵完成部署；灰度發佈，系統升級，業務不間斷；

• Cloud 中心：服務標準化共享，知足內部、外部交互，實現運營商自營業務及第三方業務便捷集成，豐富網絡應用與業務生態；

• 能力中心：創建開放的能力體系，實現能力標準化封裝及便捷的服務訪問手段，支撐能力顯性化管理；

• 策略中心：端到端的策略管理，結合用戶的業務需求、狀態和現狀，自主分析與識別，智能的決策與策略下發；

• 編排中心：實現長短流程開通服務編排，能力編排；可將原子能力經過編排組成新的能力自動發佈；

• 採集中心、監控中心：實現系統各種數據採集分析與監控，實時圖形化感知系統運行狀態。

6.2. 邏輯架構

       邏輯架構方面，我就以其中的一個對帳系統爲例:

 

    

 

      說明：這裏的實時應該是說咱們有一些商家 一筆訂單過來，按商家維度生成結算單，而後提交給財務審覈， 高級商家是 保存結算初始訂單數據信息，而後定時任務跑的時候再生成結算單。

                例如：舉個例子，咱們有 1.普通商家（實時） 2.高級商家（月結），通俗點講：我如今要求 1.普通商家（實時） 2.高級商家（月結），這個就是基礎的架構設計.

 

6.3. 應用架構

系統的應用架構能夠劃分爲三個層次，分別是組件層、服務層與應用層，其中組件層是系統業務對象的組件化抽象和最低粒度的組裝，服務是對相關業務組件的集成與更高粒度的封裝，服務面向具體的業務應用；提供標準的調用接口供具體的業務應用直接調用；應用層包括了本系統業務與管理層面須要實現的具體應用。

6.4. 數據架構

系統邏輯數據架構是對系統業務對象的邏輯分類，本系統涉及的邏輯數據對象包括業務數據、字典數據、管理類數據、定義類數據。

6.5. 數據層次劃分

系統的數據層次能夠劃分爲數據源層、緩衝層、基礎層、應用層。

• 數據源層是系統的原始數據，包括字典數據、管理類數據和定義類數據；

• 緩衝層作爲對數據庫數據處理的有效補充，減小對數據庫的直接操做請求，負責對字典數據、部分管理類數據和部分定義類數據進行內存的緩存存儲，依據各個子系統的性能和業務的綜合考慮來肯定是否須要將數據庫數據緩存到緩存層中；緩存層的數據在對應來源數據變動時實時更新。

• 基礎數據層保留全部提交的歷史業務數據，包括表單數據和流程流轉的實例數據。

應用層爲面向各功能模塊提供統一的接口視圖。

6.6. 技術架構

6.6.1. 分層設計

本系統軟件架構設計採用鬆耦合、分層設計的原則， 主要分爲前端門戶層、服務層，其中服務層又業務處理層、數據訪問層。

• 門戶層指用戶界面,是用戶訪問本系統的入口，主要採用JSP+CSS+JavaScript框架來實現；

• 服務層是本系統提供對外業務服務的功能。該層將服務接口和實現分離，實現鬆耦合。同時，服務層主要採用Rest Full協議來實現，

業務處理層是指公共業務處理組件，主要用來處理服務層所共有的業務處理規則、流程等內容。業務處理層採用普通的Java對象來實現；

數據訪問層是指提供對數據庫數據訪問的接口，被業務處理層或服務層直接調用。數據訪問層主要經過系統技術平臺的Spring JPA 和MyBatis來實現；

• 公共組件指按照規範統一實現的公共組件，包括用戶管理、組織機構管理、權限管理、日誌管理等模塊；

• 事務處理指事務的處理機制，事務開始於服務層，採用數據庫的事務管理器對服務層的相關服務進行事務控制處理。

6.6.2. 邏輯技術架構

系統邏輯技術架構包括四個層次：分別是用戶層、訪問控制層、應用服務層和數據存儲層。訪問控制層包括了網絡的物理隔離設備與Web服務器，是系統訪問和請求轉發的第

一層。應用服務層是業務處理中心，負責對用戶提交的操做請求進行業務處理。數據存儲層包括共享存儲設備、數據庫和相應的數據備份設備。

• 利用成熟的開源框架，從新構建項目，對業務進行垂直、精細拆分，經過註冊中心、API Gateway，對外提供可供服務，最終到達基本功能微服務構建

• 利用Shiro安全框架，構建受權、會話管理

• 前端強調頁面表現，如：響應速度流暢，客戶端兼容性強，用戶體驗等

• 後端強調高併發，高可用，高性能，安全，存儲，業務等等

• 完成消息中間件的構建

技術架構：從技術層面描述，主要是分層模型，例如持久層、數據層、邏輯層、應用層、表現層等，而後每層使用什麼技術框架，例如Spring、hibernate、ioc、MVC、成熟的類庫、中間件、WebService等，分別說明，要求這些技術可以將整個系統的主要實現歸納。

應用架構：主要考慮部署，例如你不一樣的應用如何分別部署，如何支持靈活擴展、大併發量、安全性等，須要畫出物理網絡部署圖。按照應用進行劃分的話，還須要考慮是否支持分佈式SOA。

技術架構關注的是：技術的分層及描述（不單純只寫mvc），關鍵技術的方案（如事務處理、緩存與集羣等）

應用架構關注的是：應用功能的劃分、應用功能集成和應用功能部署。

 

實際運營截圖：

 

 

 

聯繫QQ：137071249

QQ羣：793305035