架構設計

在架構設計過程當中，咱們會根據須要作出不一樣的架構設計，而在設計時須要涉及必定的架構設計核心要素。數據庫

架構設計概要

架構設計是從業務需求到系統實現的一個轉換，是對需求進一步深刻分析的過程，用於肯定系統中實體與實體的關係，以及實體的形式與功能。架構可根據從業務需求到系統實現的不一樣須要分爲：業務架構、應用架構、數據架構、技術架構。下面以電商系統爲例進行架構設計。跨域

業務架構

業務架構是對業務需求的提煉和抽象，使用一套方法論對產品（項目）所涉及需求的業務進行業務邊界劃分，簡單地講就是根據一套邏輯思路進行業務的拆分，開發軟件必須知足業務需求，不然就是空中樓閣。軟件系統在業務上的複雜度問題，能夠從業務架構的角度切分工做交界面來解決。好比在作一個電商網站時，須要將商品類目、商品、訂單、支付、退款等功能很清晰地劃分出來，不要在業務架構中考慮用什麼技術開發、併發量是否太大、選擇什麼樣的硬件，等等。緩存

這裏簡單規劃了電商系統的業務模塊，對其根據業務架構的模塊不斷細化，一直分解到代碼流程。對於軟件開發而言，以業務架構爲依託，架構師和開發者能比較清晰地看到系統的業務全貌，架構師能更方便地分析系統複雜度，分解業務邏輯，作好開發的分工，如圖5.1所示。markdown

圖5.1網絡

業務架構是決定一個軟件項目可否順利開展的總綱，軟件架構是業務架構在技術層面的映射，合理的開發分工也應該基於業務架構去作。若是沒有業務架構，進行軟件開發就會很盲目。業務架構是需求和開發的匯聚點，需求分析是否作到位，功能開發是否達到預期目標，都以此爲依託。咱們在工做中會遇到一些問題，例如研發人員說需求分析作得不到位，而作需求的人員會質疑需求作到怎樣纔算到位，爲何開發出的產品和用戶想要的不一致，這些從根上來講，都是由於沒有將業務架構梳理清楚，沒有達成共識。架構

站在軟件項目的角度來看，在項目前期作好業務架構設計，對整個項目的開發都有重要的意義。例如，對於比較相似的業務系統，可能業務架構在比較粗的顆粒度上是同樣的，而在細化過程當中不同。併發

在作項目時，當手頭有一個現成的系統，須要作一個需求相似的項目時，你們可能會首先嚐試用現成的系統去覆蓋新項目，以求利益最大化。對於該想法可否實現，能夠經過業務架構來衡量，若是沒有業務架構，則接下來的工做會很是盲目。業務架構的設計原則以下。運維

（1）將業務平臺化。異步

◎ 業務平臺化，相互獨立，例如交易平臺、物流平臺、支付平臺、廣告平臺等。分佈式

◎ 基礎業務下沉，可複用，例如用戶、商品、類目、促銷、時效等。（2）將核心業務和非核心業務分離。將電商系統的核心業務和非核心業務如主交易服務和通用交易服務分離，將核心業務精簡（利於穩定），並將非核心業務多樣化。

（3）隔離不一樣類型的業務。

◎ 交易平臺的做用是讓買家和賣家簽定交易合同，因此須要優先保證高可用，讓用戶能快速下單。

◎ 履約業務對可用性沒有過高要求，但要優先保證一致性。

◎ 秒殺業務對高併發要求很高，應該和常規業務分離。

（4）區分主流程和輔助流程。要清楚哪些是電商系統的主流程，在運行時優先保證主流程的順利完成；對輔助流程能夠採用後臺異步的方式，避免輔助流程的失敗影響主流程的失敗迴流。

應用架構

應用架構介於業務與技術之間，是對整個系統實現的整體架構，須要指出系統的層次、系統開發的原則、系統各個層次的應用服務。

如圖5.2所示爲將系統分爲表現層、業務流程層、服務層、服務構建層、數據層、集成層、數據架構層和服務治理層，並寫明每一個層次的應用提供的服務。

在進行系統拆分時，要平衡業務和技術的複雜度，保證系統形散神不散。系統採用什麼樣的應用架構，則受到業務複雜度的影響，包括企業的發展階段和業務特色；同時受技術複雜度的影響，包括 IT技術的發展階段和內部技術人員的水平。業務的複雜度（包括業務量大）必然帶來技術的複雜度，應用架構的目標是在解決業務複雜度的同時避免技術太複雜，確保業務架構落地。

圖5.2

應用架構的設計原則以下。

（1）穩定

◎ 一切以穩定爲中心。

◎ 架構儘量簡單、清晰，追求小而美，不要大而全。

◎ 不過分設計。

（2）解耦

◎ 將穩定部分與易變部分分離。

◎ 將核心業務與非核心業務分離。

◎ 將電商主流程和輔助流程分離。

◎ 將應用與數據分離。

◎ 將服務和實現細節分離。（3）抽象

◎ 應用抽象化：應用只依賴服務抽象，不依賴服務實現的細節和位置。

◎ 數據庫抽象化：應用只依賴邏輯數據庫，不須要關心物理庫的位置和分片。

◎ 服務抽象化：應用虛擬化部署，不須要關心實體機的配置，動態調配資源。

（4）鬆耦合

◎ 跨域調用異步化：在不一樣的業務域之間儘可能異步解耦。

◎ 非核心業務儘可能異步化：在覈心業務和非核心業務之間儘可能異步化。

◎ 在必須同步調用時，須要設置超時時間和任務隊列的長度。

（5）容錯設計

◎ 服務自治：服務能彼此獨立修改、部署、發佈和管理，避免引起連鎖反應。

◎ 集羣容錯：應用系統集羣部署，避免單點服務。

◎ 多機房容災：多機房部署、多活。

技術架構

技術架構就是對在業務架構中提出的功能（或服務）進行技術方案的實現，包括軟件系統實現、操做系統選擇和運行時設計。技術架構的邊界比較模糊，對於不一樣的受衆，內容的詳細程度也不一樣，技術棧自上而下比較關注技術架構，可是各層關注的點不一樣。技術決策層可能關心的是系統或系統羣的技術選型，對總體的把握要保證不由於選型引發其餘風險，例如，若是在高性能存儲方面選擇 Redis，就要儘可能保證網絡的封閉性，避免公網訪問；再如，在選擇以COBOL語言實現的各種產品時，要考慮市場上開發人員數量少，須要承擔更高的迭代成本等。

上述業務架構的一個簡單技術架構如圖5.3所示。

圖5.3

技術架構的設計原則以下。

（1）無狀態，即儘可能不要把狀態數據保存在本機上。

（2）可複用。

◎ 複用粒度是有業務邏輯的抽象服務，不是服務的實現細節。

◎ 服務引用只依賴服務抽象。

（3）鬆耦合

◎ 跨業務域調用，儘量異步解耦。◎ 在同步調用時設置超時時間和隊列大小。

◎ 將相對穩定的基礎服務與易變流程服務分離。

（4）可治理

◎ 服務可降級。

◎ 服務可限流。

◎ 服務可開關。

◎ 服務可監控。

◎ 白名單機制。

◎ 制定服務契約。

（5）基礎服務

◎ 基礎服務下沉、可複用，例如時效、庫存和價格計算。

◎ 基礎服務自治、相對獨立。

◎ 對基礎服務的實現要精簡，並可水平擴展。

◎ 對基礎服務的實現要進行物理隔離，包括基礎服務相關的數據。

數據架構

數據架構是對存儲數據（資源）的架構，其設計原則和應用架構

設計大同小異，在設計時須要考慮系統的業務場景，須要根據不一樣的業務場景對數據進行異構設計、數據庫讀寫分離、分佈式數據存儲策略等。如圖5.4所示是電商系統中數據架構的一個概要。

圖5.4

數據架構包括兩部份內容：靜態部分的內容和動態部分的內容。

靜態部分的內容的重點是數據元模型、數據模型，包括主數據、共享動態數據和全部業務相關的業務對象數據的分析和建模；動態部分的內容的重點則是對數據全生命週期的管控和治理。所以，不能單純地將數據架構理解爲純靜態的數據模型。業務架構中數據模型的分析重點是主數據和核心業務對象，應用架構中數據模型的分析重點則進一步轉換爲邏輯模型和物理模型，直到最終的數據存儲和分佈。

數據分兩個層面的生命週期：單業務對象數據的全生命週期，它每每和流程建模中的單個工做流或審批流相關；跨多個業務域對象數據的全生命週期，它體現的是多個業務對象數據之間的轉換和映射，

每每和端到端的業務流程 BPM 相關。這裏要注意，數據雖然是靜態層面的內容，可是數據的生命週期或端到端的數據映射每每間接反映了流程，這是很重要的內容。

數據建模的方法包括面向結構的傳統ER模型分析方法，也包括面向對象的對象類模型分析方法，它們都是可行的數據建模方法，只是傳統ER模型分析方法更容易實現向底層物理數據庫模型的轉換，而面向對象的對象類建模方法更容易體現抽象和複用。特別是在企業架構建模中，面向對象和麪向結構每每不是嚴格區分的，不少時候都會出現兩種方法混用的狀況，但重點是區分每種方法或工具的重點及要解決的問題。與數據相關的矩陣分析至關多，業務架構階段的重點矩陣分析是業務對象和業務流程、業務組件、業務功能間的類CRUD矩陣分析；而應用架構階段的重點矩陣分析是邏輯或物理模型對象和具體的應用模塊或應用功能間的矩陣分析。二者的思路基本相似，只是關注的層面不一樣，前者重點關注主數據的識別和業務組件的分析，然後者重點關注應用功能模塊的劃分和模塊間集成接口的初步分析。

根據前面的思路，咱們仍然應該將數據集成分析分解爲兩個層面的內容：業務層面的分析，以及應用和 IT 實現層面的分析。前者的重點是理清業務流程或業務域之間的業務對象集成和交互，然後者的重點是如何更好地共享數據或如何經過相似的 BI 工具或大數據平臺實現數據的集成和交互。

數據架構的設計原則以下。

（1）統一數據視圖，即保證數據的及時性、一致性、準確性和完整性。

（2）數據和應用分離。

◎ 應用系統只依賴邏輯數據庫。

◎ 應用系統不直接訪問其餘應用的數據庫，只能經過接口訪問。

（3）數據異構，即在源數據和目標數據內容相同時作索引異構，在商品庫不一樣維度的內容不一樣時（如訂單數據中的買家庫和賣家庫）作數據庫異構。

（4）數據庫讀寫分離。

◎ 將訪問量大的數據庫作讀寫分離，例如訂單庫。

◎ 將數據量大的數據庫作分庫分表。

◎ 將不一樣業務域的數據庫作分區隔離。◎ 對重要的數據配置備庫。

（5）採用關係數據庫。除成本因素外，MySQL 的數據庫擴展性和高併發支持能力較強，也比較容易招聘到相關的研發人員和運維人員。