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群：793305035