架構設計
在架構設計過程中，我們會根據需要做出不同的架構設計，而在設計時需要涉及一定的架構設計核心要素。
架構設計概要架構設計是從業務需求到系統實現的一個轉換，是對需求進一步深入分析的過程，用於確定系統中實體與實體的關係，以及實體的形式與功能。架構可根據從業務需求到系統實現的不同需要分為：業務架構、應用架構、資料架構、技術架構。下面以電商系統為例進行架構設計。
業務架構業務架構是對業務需求的提煉和抽象，使用一套方法論對產品（專案）所涉及需求的業務進行業務邊界劃分，簡單地講就是根據一套邏輯思路進行業務的拆分，開發軟體必須滿足業務需求，否則就是空中樓閣。軟體系統在業務上的複雜度問題，可以從業務架構的角度切分工作交介面來解決。比如在做一個電商網站時，需要將商品類目、商品、訂單、支付、退款等功能很清晰地劃分出來，不要在業務架構中考慮用什麼技術開發、併發量是否太大、選擇什麼樣的硬體，等等。
這裡簡單規劃了電商系統的業務模組，對其根據業務架構的模組不斷細化，一直分解到程式碼流程。對於軟體開發而言，以業務架構為依託，架構師和開發者能比較清晰地看到系統的業務全貌，架構師能更方便地分析系統複雜度，分解業務邏輯，做好開發的分工，如圖5.1所示。
圖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 的資料庫擴充套件性和高併發支援能力較強，也比較容易招聘到相關的研發人員和運維人員。
（6）合理利用 NoSQL 資料庫。在資料庫有能力支撐時，儘量不要引入快取。另外，要合理利用快取做容災。