Java生鮮電商平臺-生鮮電商架構設計概要，業務、應用、技術、資料架構（小程式/APP）
說明：在Java生鮮電商平臺中，一個好的生鮮電商架構需要包括整體設計，業務，應用，技術等各個方面，下面來簡單的介紹下生鮮電商的架構.
架構設計
在架構設計程序中，我們會根據需要做出不同的架構設計，而在設計時需要涉及一定的架構設計核心要素，
架構設計概要
架構設計是從業務需求到系統實作的一個轉換，是對需求進一步深入分析的程序，用于確定系統中物體與物體的關系，以及物體的形式與功能，架構可根據從業務需求到系統實作的不同需要分為：業務架構、應用架構、資料架構、技術架構，下面以電商系統為例進行架構設計，
業務架構
業務架構是對業務需求的提煉和抽象，使用一套方法論對產品（專案）所涉及需求的業務進行業務邊界劃分，簡單地講就是根據一套邏輯思路進行業務的拆分，開發軟體必須滿足業務需求，否則就是空中樓閣，軟體系統在業務上的復雜度問題，可以從業務架構的角度切分作業交界面來解決，比如在做一個電商網站時，需要將商品類目、商品、訂單、支付、退款等功能很清晰地劃分出來，不要在業務架構中考慮用什么技術開發、并發量是否太大、選擇什么樣的硬體，等等，
這里簡單規劃了電商系統的業務模塊，對其根據業務架構的模塊不斷細化，一直分解到代碼流程，對于軟體開發而言，以業務架構為依托，架構師和開發者能比較清晰地看到系統的業務全貌，架構師能更方便地分析系統復雜度，分解業務邏輯，做好開發的分工，如圖5.1所示，
圖5.1
業務架構是決定一個軟體專案能否順利開展的總綱，軟體架構是業務架構在技術層面的映射，合理的開發分工也應該基于業務架構去做，如果沒有業務架構，進行軟體開發就會很盲目，業務架構是需求和開發的匯聚點，需求分析是否做到位，功能開發是否達到預期目標，都以此為依托，我們在作業中會遇到一些問題，例如研發人員說需求分析做得不到位，而做需求的人員會質疑需求做到怎樣才算到位，為什么開發出的產品和用戶想要的不一致，這些從根上來說，都是因為沒有將業務架構梳理清楚，沒有達成共識，
站在軟體專案的角度來看，在專案前期做好業務架構設計，對整個專案的開發都有重要的意義，
例如，對于比較類似的業務系統，可能業務架構在比較粗的顆粒度上是一樣的，而在細化程序中不一樣，
在做專案時，當手頭有一個現成的系統，需要做一個需求類似的專案時，大家可能會首先嘗試用現成的系統去覆寫新專案，以求利益最大化，對于該想法能否實作，可以通過業務架構來衡量，如果沒有業務架構，則接下來的作業會非常盲目，業務架構的設計原則如下，
（1）將業務平臺化，
1.1 業務平臺化，相互獨立，例如交易平臺、物流平臺、支付平臺、廣告平臺等，
1.2 基礎業務下沉，可復用，例如用戶、商品、類目、促銷、時效等，
（2）將核心業務和非核心業務分離，將電商系統的核心業務和非核心業務如主交易服務和通用交易服務分離，將核心業務精簡（利于穩定），并將非核心業務多樣化，
（3）隔離不同型別的業務，
3.1 交易平臺的作用是讓買家和賣家簽訂交易合同，所以需要優先保證高可用，讓用戶能快速下單，
3.2 履約業務對可用性沒有太高要求，但要優先保證一致性，
3.3 秒殺業務對高并發要求很高，應該和常規業務分離，
（4）區分主流程和輔助流程，要清楚哪些是電商系統的主流程，在運行時優先保證主流程的順利完成；對輔助流程可以采用后臺異步的方式，避免輔助流程的失敗影響主流程的失敗回流，
應用架構
應用架構介于業務與技術之間，是對整個系統實作的總體架構，需要指出系統的層次、系統開發的原則、系統各個層次的應用服務，
如圖5.2所示為將系統分為表現層、業務流程層、服務層、服務構建層、資料層、集成層、資料架構層和服務治理層，并寫明每個層次的應用提供的服務，
在進行系統拆分時，要平衡業務和技術的復雜度，保證系統形散神不散，系統采用什么樣的應用架構，則受到業務復雜度的影響，包括企業的發展階段和業務特點；同時受技術復雜度的影響，包括 IT技術的發展階段和內部技術人員的水平，業務的復雜度（包括業務量大）必然帶來技術的復雜度，應用架構的目標是在解決業務復雜度的同時避免技術太復雜，確保業務架構落地，
圖5.2
應用架構的設計原則如下，
（1）穩定
1.1 一切以穩定為中心，
1.2 架構盡可能簡單、清晰，追求小而美，不要大而全，
1.3 不過度設計，
（2）解耦
2.1 將穩定部分與易變部分分離，
2.2 將核心業務與非核心業務分離，
2.3 將電商主流程和輔助流程分離，
2.4 將應用與資料分離，
2.5 將服務和實作細節分離，
（3）抽象
3.1 應用抽象化：應用只依賴服務抽象，不依賴服務實作的細節和位置，
3.2 資料庫抽象化：應用只依賴邏輯資料庫，不需要關心物理庫的位置和分片，
3.3 服務抽象化：應用虛擬化部署，不需要關心物體機的配置，動態調配資源，
（4）松耦合
4.1 跨域呼叫異步化：在不同的業務域之間盡量異步解耦，
4.2 非核心業務盡量異步化：在核心業務和非核心業務之間盡量異步化，
4.3 在必須同步呼叫時，需要設定超時時間和任務佇列的長度，
（5）容錯設計
5.1 服務自治：服務能彼此獨立修改、部署、發布和管理，避免引發連鎖反應，
5.2 集群容錯：應用系統集群部署，避免單點服務，
5.3 多機房容災：多機房部署、多活，
技術架構
技術架構就是對在業務架構中提出的功能（或服務）進行技術方案的實作，包括軟體系統實作、作業系統選擇和運行時設計，技術架構的邊界比較模糊，對于不同的受眾，內容的詳細程度也不同，技術堆疊自上而下比較關注技術架構，但是各層關注的點不同，技術決策層可能關心的是系統或系統群的技術選型，對整體的把握要保證不因為選型引起其他風險，例如，如果在高性能存盤方面選擇 Redis，就要盡量保證網路的封閉性，避免公網訪問；再如，在選擇以COBOL語言實作的各類產品時，要考慮市場上開發人員數量少，需要承擔更高的迭代成本等，
上述業務架構的一個簡單技術架構如圖5.3所示，
圖5.3
技術架構的設計原則如下，
（1）無狀態，即盡量不要把狀態資料保存在本機上，
（2）可復用，
2.1 復用粒度是有業務邏輯的抽象服務，不是服務的實作細節，
2.2 服務參考只依賴服務抽象，
（3）松耦合
3.1 跨業務域呼叫，盡可能異步解耦，◎ 在同步呼叫時設定超時時間和佇列大小，
3.2 將相對穩定的基礎服務與易變流程服務分離，
（4）可治理
4.1 服務可降級，
4.2 服務可限流，
4.3 服務可開關，
4.4 服務可監控，
4.5 白名單機制，
4.6 制定服務契約，
（5）基礎服務
5.1 基礎服務下沉、可復用，例如時效、庫存和價格計算，
5.2 基礎服務自治、相對獨立，
5.3 對基礎服務的實作要精簡，并可水平擴展，
5.4 對基礎服務的實作要進行物理隔離，包括基礎服務相關的資料，
資料架構
資料架構是對存盤資料（資源）的架構，其設計原則和應用架構
設計大同小異，在設計時需要考慮系統的業務場景，需要根據不同的業務場景對資料進行異構設計、資料庫讀寫分離、分布式資料存盤策略等，如圖5.4所示是電商系統中資料架構的一個概要，
圖5.4
資料架構包括兩部分內容：靜態部分的內容和動態部分的內容，
靜態部分的內容的重點是資料元模型、資料模型，包括主資料、共享動態資料和所有業務相關的業務物件資料的分析和建模；動態部分的內容的重點則是對資料全生命周期的管控和治理，因此，不能單純地將資料架構理解為純靜態的資料模型，業務架構中資料模型的分析重點是主資料和核心業務物件，應用架構中資料模型的分析重點則進一步轉換為邏輯模型和物理模型，直到最終的資料存盤和分布，
資料分兩個層面的生命周期：單業務物件資料的全生命周期，它往往和流程建模中的單個作業流或審批流相關；跨多個業務域物件資料的全生命周期，它體現的是多個業務物件資料之間的轉換和映射，
往往和端到端的業務流程 BPM 相關，這里要注意，資料雖然是靜態層面的內容，但是資料的生命周期或端到端的資料映射往往間接反映了流程，這是很重要的內容，
資料建模的方法包括面向結構的傳統ER模型分析方法，也包括面向物件的物件類模型分析方法，它們都是可行的資料建模方法，只是傳統ER模型分析方法更容易實作向底層物理資料庫模型的轉換，而面向物件的物件類建模方法更容易體現抽象和復用，特別是在企業架構建模中，面向物件和面向結構往往不是嚴格區分的，很多時候都會出現兩種方法混用的情況，但重點是區分每種方法或工具的重點及要解決的問題，與資料相關的矩陣分析相當多，業務架構階段的重點矩陣分析是業務物件和業務流程、業務組件、業務功能間的類CRUD矩陣分析；而應用架構階段的重點矩陣分析是邏輯或物理模型物件和具體的應用模塊或應用功能間的矩陣分析，兩者的思路基本類似，只是關注的層面不同，前者重點關注主資料的識別和業務組件的分析，而后者重點關注應用功能模塊的劃分和模塊間集成介面的初步分析，
根據前面的思路，我們仍然應該將資料集成分析分解為兩個層面的內容：業務層面的分析，以及應用和 IT 實作層面的分析，前者的重點是理清業務流程或業務域之間的業務物件集成和互動，而后者的重點是如何更好地共享資料或如何通過類似的 BI 工具或大資料平臺實作資料的集成和互動，
資料架構的設計原則如下，
（1）統一資料視圖，即保證資料的及時性、一致性、準確性和完整性，
（2）資料和應用分離，
2.1 應用系統只依賴邏輯資料庫，
2.2 應用系統不直接訪問其他應用的資料庫，只能通過介面訪問，
（3）資料異構，即在源資料和目標資料內容相同時做索引異構，在商品庫不同維度的內容不同時（如訂單資料中的買家庫和賣家庫）做資料庫異構，
（4）資料庫讀寫分離，
4.1 將訪問量大的資料庫做讀寫分離，例如訂單庫，
4.2 將資料量大的資料庫做分庫分表，
4.3 將不同業務域的資料庫做磁區隔離，◎ 對重要的資料配置備庫，
（5）采用關系資料庫，除成本因素外，MySQL 的資料庫擴展性和高并發支持能力較強，也比較容易招聘到相關的研發人員和運維人員，
（6）合理利用 NoSQL 資料庫，在資料庫有能力支撐時，盡量不要引入快取，另外，要合理利用快取做容災，
結語
復盤與總結.
總結：
做Java生鮮電商平臺的互聯網應用，無論是生鮮小程式還是APP，系統設計的思路是非常重要的，本文只是起一個拋磚引玉的作用，
希望用生鮮小程式的搭建基礎的架構思路實戰經驗告訴大家一些實際的專案經驗，希望對大家有用.
QQ:137071249
共同學習QQ群：793305035
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/245517.html
標籤：Java