架構設計不是架構師的專屬工做，對非技術人員甚至是開發人員來講，從實實在在的需求到高神莫測的架構設計彷彿是一個神祕的過程，只有具備架構師頭銜的人才能掌握各中玄妙，這篇文章就是從最基本的事物關係來回答如何根據需求進行架構設計的問題。安全
根據我前面的文章，架構的本質是事物與事物之間恰當的關係，不一樣領域的架構，其事物的指代不一樣，好比對於組織架構而言，事物指的是人與機構；建築架構，事物指的是鋼筋混凝土與空間。那在軟件領域，事物指的是什麼呢？咱們知道，軟件系統的本質是人類將自身沒法處理的大量業務相關的數據進行篩選分類，並轉換成計算機能夠識別的格式，藉助其強大計算能力來輔助處理。所以在軟件領域，架構中的事物指的是業務數據與基於運算能力的業務邏輯，說的再寬泛一點就是數據與處理數據的計算能力。那麼，架構設計其本質就是尋找數據、計算以及它們之間的平衡關係，這裏麪包括三個方面的要素，即數據、計算、以及平衡關係，其中數據和計算是架構設計的基礎，根據實際業務需求通常不難找出，而平衡關係是綜合考慮多方面獲得的一種狀態，也是衡量一個架構設計優劣的核心要素。
（一）數據服務器
在對一個系統進行架構設計時，首先咱們須要作的就是依據本系統所承載的業務需求，找出須要處理的最重要或最核心的數據，這些數據通常隱藏在線下的紙質材料裏，或者記錄在平常辦公的筆記裏，或是約定俗成的共同認識，只要從實際業務出發，找這些數據並不難。若是你無從下手，這裏有個小竅門能夠利用，找一個出現率很高的業務，在該業務處理前儘量多的記錄一些可能與該業務相關的數據狀態，待業務處理完成後，再次記錄，並與以前的數據進行比較，那些發生了變化的每每就是咱們須要重點關注的重要數據。舉例來講，若是這是一個政府行政辦公的系統，那麼辦公流轉過程就是數據，每一個環節辦理狀態就是數據；若是這是銀行信用卡管理系統，那麼用戶信用卡可用金額、帳單、有效期等狀態信息就是數據，每筆刷卡流水就是數據；若是這是電子商務系統，那麼商品信息、用戶訂單、購物車信息就是數據。。。等等，全部那些在實際業務過程當中會變化的，而且是與該業務緊密相關的數據，都是咱們須要找到的數據，在全部已經找到的數據中，再依據實際業務的重要程度，找出最重要最核心的數據，做爲在架構設計中咱們須要重點處理的對象，其餘次重要的數據在覈心數據充分處理的前提下做爲平衡關係的備用因素。
（二）計算 網絡
重要數據找到後咱們還須要肯定如何處理這些數據，即計算，說的明白一點就是計算邏輯是什麼，計算邏輯相似但並不徹底等同於業務邏輯，它是業務邏輯在計算機世界裏的一種體現，業務邏輯在真實世界裏須要考慮人、時間、空間的因素，而計算邏輯在計算機的世界裏，是二進制碼、CPU、內存、存儲、網絡等因素，仍是以上面的例子來講，政府行政辦公系統須要將線下的紙質簽字蓋章從發起請求到辦結的全過程搬移到線上由系統處理，那就須要轉化成線上的在線申請、辦理、流轉、通知、辦結、存檔等過程，這些過程在線下可能有不一樣的部門來負責，可是線上將由咱們設計的系統徹底支撐；對於銀行信用卡管理系統，須要將銀行對信用卡的管理業務轉化成具體的設置或查詢可用金額、帳單、有效期等信息的功能，還有記錄和統計用戶消費流水等，若是業務有需求，甚至須要根據用戶的消費流水對用戶畫像，以便進行精準營銷等所謂的大數據分析模塊；電子商務系統也是同樣，須要系統提供向用戶展現商品信息，記錄用戶點擊購買後的購物車信息，建立或更新用戶的訂單信息，以及跟蹤訂單從倉庫打包到送達的物流信息。。。等等，這些都是咱們對數據進行的動做，而動做不是咱們憑空想象出來的，是從實際的業務處理轉化到計算機領域而來的，在轉化的過程當中咱們須要時刻對應現實中的處理動做如何轉換成計算機世界裏的處理數據的能力。因爲尋找計算是一種業務動做的轉化，在轉化時咱們能夠多問本身指望系統應該如何幫我更好的處理數據，那些利用機器能很好的完成而人工較難作到的但又是常常須要作的且與業務相關的動做通常都是咱們須要找的，常見的動做有數據跟蹤記錄、查詢統計、修改更新、導出展示、彙總分析等。固然有一點須要注意，咱們在尋找計算因素的時候必定要基於計算機世界的客觀現實，畢竟計算機不是萬能的。架構
（三）關係
明確了數據及如何處理數據，架構設計接下來要作的就是如何平衡好各類相互影響的關係，這些關係是全部咱們能想到的會影響到系統的矛盾體，如數據處理效率與處理能力的關係、數據體量與存儲能力的關係、數據展示與用戶要求的關係、系統部署與網絡環境的關係、系統建設與建設成本的關係、系統易用性與客戶要求的關係等等，在作架構設計的時候要儘量多的考慮到這些關係，並根據實際狀況劃分關係的重要程度，重點保障那些重要性高的關係，畢竟再完美的架構設計也沒法平衡好全部的關係，從這個角度來講，架構設計是一種平衡的藝術。固然，要準確找出這些關係，並對它們劃分重要性等級，還須要作到按等級進行平衡是須要經驗積累的，非一朝一夕之功，這也是人人都能作架構設計，但不是人人都能作好架構設計的緣由。好在這一步並非徹底無規律可循的，首先咱們講如何找出這些關係，雖然涉及影響一個系統的矛盾體不少，可是大體上咱們能夠從如下 3 個方向來挖掘出這些關係：併發
- 第一個方向是與人相關的，這裏的人包括籌建系統的甲方、建設系統的乙方、以及使用系統的用戶，對於籌建系統的甲方來講，他通常關注系統的建設進度、成本、質量等，對於建設系統的乙方來講，重點會關注建設範圍、風險、開發工具、實施環境等，而對於用戶來講，更關係系統易用性、界面友好，操做舒暢、能幫其解決實際問題等。涉及到與人相關的關係，除了從經驗中獲取，更重要的是須要在前期系統設計的過程當中經過調研的方式，多與相關的干係人溝通，從他們那裏獲取，這也是爲何系統建設通常都是有需求調研過程的緣由。針對與人相關的關係這部分設計內容通常體如今架構設計說明書中的概述裏，包括項目目標、項目背景及其餘說明等，固然與用戶相關的通常也會在非功能性上有所體現，如易用性、可用性、安全等；
- 第二個方向是與外部系統相關的，主要指其運行所在的操做系統及服務器，以及與之交互的外部系統，系統須要運行在服務器特定的操做系統上，受服務器操做系統計算存儲網絡等因素影響，須要考慮服務器計算能力是否能處理數據、存儲能力是否足夠、網絡是否穩定、若是服務器計算存儲網絡能力不夠如何擴展等；與外部系統的交互方面，本系統須要從外部系統獲取哪些數據與能力、須要爲外部系統提供哪些數據與能力、交互方式是什麼、交互協議如何等。通常來講，服務器的能力老是會有不夠的，尤爲是設計大數據量處理，大量用戶同時訪問的系統時，這就須要咱們根據系統的特色提早作好擴展的設計，高併發處理、分佈式理論、多機房部署等這些技術概念能夠給咱們很好的指引，這也是爲何架構師必定要眼界開闊的緣由。這部分的設計內容通常體如今架構設計說明書中的邏輯架構、技術架構、接口設計、部署架構、以及相關性能、可維護、可擴展等非功能性設計上；
- 第三個方向是數據相關的，數據是系統處理的主體，須要劃分本系統所處理的數據與外部數據的邊界，明確與外部數據的流向關係，還須要根據實際業務來區分數據內部之間的關係，數據如何劃分、各部分數據的邊界在哪、與總體數據的關係如何等等。在劃分與外部數據的邊界時要基於本系統所承載的實際業務內容，從業務出發，那些只受本業務影響的數據確定在邊界內，而本業務與其餘業務共同影響的還須要進一步分析哪方是影響主體，若是本業務是影響主體，那麼在邊界內，可是須要考慮提供給外部系統的交互接口，若是本業務非影響主體，那麼再看是否有間接影響或關聯影響，通常來講這部分數據都要考慮與外部系統的交互關係。對於邊界內的數據關係也是如此，能夠根據業務特色劃分一些區塊，每一個區塊內又是一個相對獨立的單元，與相關的其餘區塊單元存在哪些數據上的直接或間接影響，他們之間如何交互等。全部這些關係都是咱們須要發現並在架構設計時考慮的。針對這部分的設計內容通常體如今架構設計說明書中的數據架構、總體架構裏。
人、外部系統、數據是咱們在發掘關係時能夠參考的方向，根據系統各自的特色，在架構設計過程當中還會有一些須要實際去考慮的關係，這些關係通常都是所謂的系統最大的特色或特殊狀況，常見於重大需求，特點需求，亮點需求等形式，通常也不難找出。待把全部這些關係找出後，能夠先作一個粗略的重要性分級，分級的依據是關係的相關性，通常是重要需求相關 > 特點亮點需求 > 甲方相關 > 用戶相關 > 乙方相關 > 外部系統相關 > 外部數據相關 > 內部數據相關 > 其餘次重要的數據，在進行架構設計時優先知足重要性高的關係，得出一個基本的架構雛形，再根據弱一級的關係不斷地優化完善架構模型，待大部分關係均可以知足後，架構設計也就出來了。固然，不少關係之間都是矛盾的，好比籌建系統的甲方要求的低成本與高質量、系統間數據交互與操做舒暢等，須要咱們在作架構設計時不斷權衡，儘量的兼顧, 對於實在沒法兼顧的，須要進行權衡取捨。
綜上來講，架構設計就是一個找準數據主體、明確處理邏輯、平衡矛盾關係的過程，須要根據實際業務進行適當的抽象，使之適合體如今計算機的世界，每一步都須要咱們明確主體，分清主次，並儘量的平衡更多的關係，這須要不斷的積累經驗，也靠一點悟性，有時候也須要一些靈感。不管如何，架構設計都不僅是架構師的工做，而是任何人均可以作的一項有趣的工做，願你開完此篇文章後對架構設計再也不迷茫，逐步成爲一個優秀的架構師。分佈式
文章出處：http://www.cnblogs.com/dimmacro/高併發