業務架構設計

A. 系統架構設計師的工作職責

根據系統需求規格說明書，結合應用領域和技術發展的實際情況，考慮有專關約束條件，設計正確、合理屬的軟體架構，確保系統架構具有良好的特性；能夠對項目的系統架構進行描述、分析、設計與評估；能夠按照相關標准編寫相應的設計文檔；能夠與系統分析師、項目管理師相互協作、配合工作；具有高級工程師的實際工作能力和業務水平。

B. 用什麼工具畫 軟體架構設計圖

1、Microsoft Office Visio

Office Visio 是office軟體系列中的負責繪制流程圖和示意圖的軟體，是一款便於IT和商務人員就復雜信息、系統和流程進行可視化處理、分析和交流的軟體。

2、ProcessOn

是一款網頁版的在線作圖工具，優點是無需下載安裝、破解這些破事，同時支持在線協作，可以多人同時對一個文件協作編輯，而且上手比較容易，它提供很多流程圖模版，可以方便的畫出流程圖、思維導圖、原型圖、UML圖。

3、OmniGraffle

OmniGraffle可以用來繪制圖表，流程圖，組織結構圖以及插圖，也可以用來組織頭腦中思考的信息，組織頭腦風暴的結果，繪制心智圖，作為樣式管理器，或設計網頁或PDF文檔的原型。只能於運行在Mac OS X和iPad平台之上。

4、億圖

是一款基於矢量的繪圖工具，包含大量的事例庫和模板庫。可以很方便的繪制各種專業的業務流程圖、組織結構圖、商業圖表、程序流程圖、數據流程圖、工程管理圖、軟體設計圖、網路拓撲圖等等。

5、Axure RP

Axure RP是美國Axure Software Solution公司旗艦產品，是一個專業的快速原型設計工具，讓負責定義需求和規格、設計功能和界面的專家能夠快速創建應用軟體或Web網站的線框圖、流程圖、原型和規格說明文檔。

C. 軟體概要設計中應突出軟體架構還是業務流程

你說的點不正確。實際上，用一句話來說，要看情況而定。
到底以什麼為概要設計重點，不同的項目，完全不同。

D. 架構師必看：談軟體架構師如何做好架構設計（

此文轉載至：帳前卒
1 前言
軟體架構設計是軟體設計的一部分，相當於總體設計，是軟體設計過程中一個決定性的環節，架構確定了，軟體基本也就定型了。而軟體架構師則是軟體項目的領軍人物，是軟體設計過程中最具挑戰性的角色，從技術角度來講，他承擔了項目的成敗責任。
EEEC給「架構師」的定義為「軟體架構師是技術主管」，這就意味著他不僅要有高超的技術才能，還要有很好的領導才能，他的領導能力在團隊中和軟體質量控制中起著十分重要的作用。作為一個架構師，他要掌握整個軟體項目的前景，調節各小組間關系，要讓所有的項目組成成員了解大家共同的目的和目標，並發布標准和章程；要能正確理解軟體過程，要在宏觀上擁有專業知識，應該擁有很好的設計技巧；要是一個很好的溝通員和談判代表，要能做出正確的決策等，除此，還有許多他要具備的其它素質。
2. 做好需求調研和分析
為保證軟體的可用性，要從需求出發設計架構，即：做軟體先做需求，這是軟體業內人士的共識，但這項工作做得好的卻很少。根據調查，屬於需求分析和軟體設計錯誤與缺陷的約占軟體錯誤與缺陷的64%；而屬於程序代碼錯誤的僅佔36%；而因軟體錯誤積累與放大效應，造成整個軟體項目拖延或失敗情況的高達20%～60%。這些數據表明，搞好需求調研和分析是軟體設計和開發的第一步。架構師必須要在需求調研的初期就介入，以保證需求獲取的及時、可靠、准確，並對下步工作起指導作用。進行需求調研，不能就事論事，對用戶的需求調研要全面、細致。需求要進行全局性的分析，需要有全局的觀點，而不是分散地、根據具體的應用開發而進行的調研，這樣才能系統地、本質地、概括地把握軟體的功能結構。在調研過程中，自始至終都要有用戶方的業務人員參加，尤其是強調高層管理人員的重視和親自參與，架構師及其相應的工作小組要有足夠的溝通和理解能力，要能使業務人員在需求調研階段起主導作用，架構師僅起協助和引導作用，並提供需求調研的科學方法和過程。
2.1 熟悉建設單位，定義職能域
在需求調研階段，架構師首先要全面了解用戶中所有人員的需求，首先要了解建設單位的組織機構、業務關系，並根據建設單位中的一些主要業務活動領域，研究定義職能域，這是第一重要任務。職能域是用戶功能規劃的抽象，應符合建設單位內部各種業務的邏輯關系，而不是現行機構部門的翻版，一經識別，就要保持相對穩定。研製職能域模型時，需要特別注意，要自頂向下規劃，並把握好設計職能域的數目；注意用戶需求的主次關系，按照重要性、優先順序進行權衡取捨。
2.2 詳細調研各項業務過程及其功能分解
每個職能域都包括一定數目的業務過程，業務過程可以繼續分解為業務活動（對應於未來的軟體功能），每個功能再分解為更低層的功能，逐級向下分解，直到產生最基本的、不可再分的最小功能單元。
職能域和業務過程都要獨立於當前的組織機構，因為組織機構可能變化，部門的分工也會變化，但整個單位的基本職能和業務相對穩定。職能域或業務過程可能橫跨兩個或多個業務部門。業務過程的確定可以對照組織機構中各部門負責人的職責來考慮，這樣，也可能獲得未來軟體的操作許可權、數據許可權的分配和功能模塊的劃分，這些業務過程是一個單位運作的基本工作，不受報告層次和具體負責人變動的影響。
調研前，架構師要對調研的內容事先准備，針對不同管理層的用戶詢問不同的問題，列出問題清單，將操作層、管理層、決策層的需求既聯系又區分開來，形成一個金字塔，使下層滿足上層的需求。調研時，要收集用戶工作中涉及的所有內容，如各種單據、報表、處理規則，再將其串成流程圖，以流程圖為主線，同時把握以下方面：
（1）該流程中是否存在不必要的環節；
（2）流程是否可以簡化，是否可以省略一些環節；
（3）流程中的每個處理環節是否起到了增值提效的作用；
（4）哪些流程可以並行處理。
2.3 在調研具體業務時工作小組要把握的重點
（1）平均頻度
業務發生的頻繁程度稱為頻度，這個數字可以是一個平均值或統計值。頻度越高，數據量越大，對響應時間、易操作性等要求就越高。在數據存儲時，對大頻度的業務或單據要進行充分的考慮。
（2）高峰期的頻度
必須保證軟體在高峰期的響應時間，對軟體進行測試時，要模擬高峰期的業務頻度。
（3）單據要求
單據上的內容也就是單據的屬性，它是進行數據結構設計的最基本依據。數據的精度是定義資料庫中欄位長度的依據；計算生成方法是設計演算法的依據；取值范圍與計算生成方法是數據完整性檢測的依據。
（4）利於減輕工作量
減輕人員的工作量是採用新軟體的一個目的，花費時間最多、處理方法最復雜的地方往往是軟體最關鍵的地方，也是用戶將來驗收時最關心的地方。實際上有很多報表由於工作量相當大，用戶沒有足夠的人力與時間來進行處理，這時他便想到了計算機。
（5）單據報表流程
要了解單據或報表的來源、單據聯數、每聯用途、送交單位、送交時間，對來源與去向的追蹤可以調查出各個業務、各個單據、各個報表及各個部門之間的聯系。
（6）特殊情況的處理與糾錯
對於特殊情況的處理，體現了軟體靈活性，但這其中也隱含著安全危機。用戶領域中有很多「合理但不合法，不合理也不合法」的特殊情況，它們出現的機會比較少，在調研時要將這些易遺漏的問題挖掘出來，這些特殊情況有時是軟體必須要處理的。
當用戶在某個作業環節出現失誤時，手工軟體有的採用正規的手續進行糾錯，有的則相當隨便，這些情況出現的概率也很小，在調研時，可採用窮舉的方法，假定在每一個環節都出現失誤，逐個環節詢問用戶的處理方法，防止遺漏。這些細節如果不調研清楚，往往會對軟體產生深遠的影響。
（7）考慮長遠
將來用戶需求的變化是很正常的現象，如果僅僅著眼於現在，而不對將來有所考慮，軟體的壽命便不會長久，要將以後可能的變化考慮在內。需求獲取後，務必要將調研的成果編制為文檔，可視化需求調研，提供不同的圖給不同層次的用戶進行確認。對高層領導，可提供總體職能域圖或業務流程圖，對業務管理人員可提供業務流程圖或業務活動圖，甚至可以畫出用戶界面的草圖。
3 需求分析與設計
架構師所帶領的團隊做出的關於軟體體系結構的決策，將直接影響軟體開發的難度和軟體維護的難易度，最終決定軟體開發的成敗。
作為一個架構師，在進行架構設計時，必須具備以下基本能力：
（1）他要把整個團隊組織在架構周圍，並積極地投入到計劃活動上，要把架構轉化完成任務的先後順序，這樣才能及時地確定在什麼位置用什麼技術。
（2）架構師要在技術上做宏觀決策，不必關心細節化的事情，由於技術的變化過於頻繁，架構師要時與這些變化同步；架構師必須至少能對各種技術有一個整體上的了解，能夠熟知每種技術特點及優缺點，只有這樣，架構設計師才能在特定的應用場景下，正確地選擇各種技術來設計軟體架構。
（3）架構師要能預測最小化項目中可能出現的風險，因為這直接影響到軟體架構的穩定性。
（4）架構師要能與開發人員保持良好的溝通，確保軟體設計的實現。

E. 怎樣的架構設計才是真正的數據倉庫架構

一直想整理一下這塊內容，既然是漫談，就想起什麼說什麼吧。我一直是在互聯網行業，就以互聯網行業來說。
先大概列一下互聯網行業數據倉庫、數據平台的用途：

• 整合公司所有業務數據，建立統一的數據中心；

• 提供各種報表，有給高層的，有給各個業務的；

• 為網站運營提供運營上的數據支持，就是通過數據，讓運營及時了解網站和產品的運營效果；

• 為各個業務提供線上或線下的數據支持，成為公司統一的數據交換與提供平台；

• 分析用戶行為數據，通過數據挖掘來降低投入成本，提高投入效果；比如廣告定向精準投放、用戶個性化推薦等；

• 開發數據產品，直接或間接為公司盈利；

• 建設開放數據平台，開放公司數據；

• 。。。。。。



• 上面列出的內容看上去和傳統行業數據倉庫用途差不多，並且都要求數據倉庫/數據平台有很好的穩定性、可靠性；但在互聯網行業，除了數據量大之外，越來越多的業務要求時效性，甚至很多是要求實時的 ，另外，互聯網行業的業務變化非常快，不可能像傳統行業一樣，可以使用自頂向下的方法建立數據倉庫，一勞永逸，它要求新的業務很快能融入數據倉庫中來，老的下線的業務，能很方便的從現有的數據倉庫中下線；


• 其實，互聯網行業的數據倉庫就是所謂的敏捷數據倉庫，不但要求能快速的響應數據，也要求能快速的響應業務；


• 建設敏捷數據倉庫，除了對架構技術上的要求之外，還有一個很重要的方面，就是數據建模，如果一上來就想著建立一套能兼容所有數據和業務的數據模型，那就又回到傳統數據倉庫的建設上了，很難滿足對業務變化的快速響應。應對這種情況，一般是先將核心的持久化的業務進行深度建模（比如：基於網站日誌建立的網站統計分析模型和用戶瀏覽軌跡模型；基於公司核心用戶數據建立的用戶模型），其它的業務一般都採用維度+寬表的方式來建立數據模型。這塊是後話。


• 整體架構下面的圖是我們目前使用的數據平台架構圖，其實大多公司應該都差不多：


• 邏輯上，一般都有數據採集層、數據存儲與分析層、數據共享層、數據應用層。可能叫法有所不同，本質上的角色都大同小異。


• 我們從下往上看：


• 數據採集數據採集層的任務就是把數據從各種數據源中採集和存儲到數據存儲上，期間有可能會做一些簡單的清洗。



• 數據源的種類比較多：



• 網站日誌：



• 作為互聯網行業，網站日誌占的份額最大，網站日誌存儲在多台網站日誌伺服器上，


• 一般是在每台網站日誌伺服器上部署flume agent，實時的收集網站日誌並存儲到HDFS上；



• 業務資料庫：



• 業務資料庫的種類也是多種多樣，有Mysql、Oracle、SqlServer等，這時候，我們迫切的需要一種能從各種資料庫中將數據同步到HDFS上的工具，Sqoop是一種，但是Sqoop太過繁重，而且不管數據量大小，都需要啟動MapRece來執行，而且需要Hadoop集群的每台機器都能訪問業務資料庫；應對此場景，淘寶開源的DataX，是一個很好的解決方案（可參考文章 《異構數據源海量數據交換工具-Taobao DataX 下載和使用》），有資源的話，可以基於DataX之上做二次開發，就能非常好的解決，我們目前使用的DataHub也是。


• 當然，Flume通過配置與開發，也可以實時的從資料庫中同步數據到HDFS。



• 來自於Ftp/Http的數據源：



• 有可能一些合作夥伴提供的數據，需要通過Ftp/Http等定時獲取，DataX也可以滿足該需求；



• 其他數據源：



• 比如一些手工錄入的數據，只需要提供一個介面或小程序，即可完成；



• 數據存儲與分析毋庸置疑，HDFS是大數據環境下數據倉庫/數據平台最完美的數據存儲解決方案。



• 離線數據分析與計算，也就是對實時性要求不高的部分，在我看來，Hive還是首當其沖的選擇，豐富的數據類型、內置函數；壓縮比非常高的ORC文件存儲格式；非常方便的SQL支持，使得Hive在基於結構化數據上的統計分析遠遠比MapRece要高效的多，一句SQL可以完成的需求，開發MR可能需要上百行代碼；


• 當然，使用Hadoop框架自然而然也提供了MapRece介面，如果真的很樂意開發Java，或者對SQL不熟，那麼也可以使用MapRece來做分析與計算；Spark是這兩年非常火的，經過實踐，它的性能的確比MapRece要好很多，而且和Hive、Yarn結合的越來越好，因此，必須支持使用Spark和SparkSQL來做分析和計算。因為已經有Hadoop Yarn，使用Spark其實是非常容易的，不用單獨部署Spark集群，關於Spark On Yarn的相關文章，可參考：《Spark On Yarn系列文章》


• 實時計算部分，後面單獨說。


• 數據共享這里的數據共享，其實指的是前面數據分析與計算後的結果存放的地方，其實就是關系型資料庫和NOSQL資料庫；



• 前面使用Hive、MR、Spark、SparkSQL分析和計算的結果，還是在HDFS上，但大多業務和應用不可能直接從HDFS上獲取數據，那麼就需要一個數據共享的地方，使得各業務和產品能方便的獲取數據；和數據採集層到HDFS剛好相反，這里需要一個從HDFS將數據同步至其他目標數據源的工具，同樣，DataX也可以滿足。


• 另外，一些實時計算的結果數據可能由實時計算模塊直接寫入數據共享。



• 數據應用

• 業務產品
  



• 業務產品所使用的數據，已經存在於數據共享層，他們直接從數據共享層訪問即可；



• 報表



• 同業務產品，報表所使用的數據，一般也是已經統計匯總好的，存放於數據共享層；



• 即席查詢



• 即席查詢的用戶有很多，有可能是數據開發人員、網站和產品運營人員、數據分析人員、甚至是部門老大，他們都有即席查詢數據的需求；


• 這種即席查詢通常是現有的報表和數據共享層的數據並不能滿足他們的需求，需要從數據存儲層直接查詢。


• 即席查詢一般是通過SQL完成，最大的難度在於響應速度上，使用Hive有點慢，目前我的解決方案是SparkSQL，它的響應速度較Hive快很多，而且能很好的與Hive兼容。


• 當然，你也可以使用Impala，如果不在乎平台中再多一個框架的話。



• OLAP



• 目前，很多的OLAP工具不能很好的支持從HDFS上直接獲取數據，都是通過將需要的數據同步到關系型資料庫中做OLAP，但如果數據量巨大的話，關系型資料庫顯然不行；


• 這時候，需要做相應的開發，從HDFS或者HBase中獲取數據，完成OLAP的功能；


• 比如：根據用戶在界面上選擇的不定的維度和指標，通過開發介面，從HBase中獲取數據來展示。



• 其它數據介面
  



• 這種介面有通用的，有定製的。比如：一個從Redis中獲取用戶屬性的介面是通用的，所有的業務都可以調用這個介面來獲取用戶屬性。



• 實時計算現在業務對數據倉庫實時性的需求越來越多，比如：實時的了解網站的整體流量；實時的獲取一個廣告的曝光和點擊；在海量數據下，依靠傳統資料庫和傳統實現方法基本完成不了，需要的是一種分布式的、高吞吐量的、延時低的、高可靠的實時計算框架；Storm在這塊是比較成熟了，但我選擇Spark Streaming，原因很簡單，不想多引入一個框架到平台中，另外，Spark Streaming比Storm延時性高那麼一點點，那對於我們的需要可以忽略。


• 我們目前使用Spark Streaming實現了實時的網站流量統計、實時的廣告效果統計兩塊功能。


• 做法也很簡單，由Flume在前端日誌伺服器上收集網站日誌和廣告日誌，實時的發送給Spark Streaming，由Spark Streaming完成統計，將數據存儲至Redis，業務通過訪問Redis實時獲取。


• 任務調度與監控在數據倉庫/數據平台中，有各種各樣非常多的程序和任務，比如：數據採集任務、數據同步任務、數據分析任務等；



• 這些任務除了定時調度，還存在非常復雜的任務依賴關系，比如：數據分析任務必須等相應的數據採集任務完成後才能開始；數據同步任務需要等數據分析任務完成後才能開始；這就需要一個非常完善的任務調度與監控系統，它作為數據倉庫/數據平台的中樞，負責調度和監控所有任務的分配與運行。


• 前面有寫過文章，《大數據平台中的任務調度與監控》,這里不再累贅。


• 總結在我看來架構並不是技術越多越新越好，而是在可以滿足需求的情況下，越簡單越穩定越好。目前在我們的數據平台中，開發更多的是關注業務，而不是技術，他們把業務和需求搞清楚了，基本上只需要做簡單的SQL開發，然後配置到調度系統就可以了，如果任務異常，會收到告警。這樣，可以使更多的資源專注於業務之上。

F. 如何做好軟體系統的架構設計

軟體架構設計的目的 對於外包業務類型的項目，軟體架構設計的目的與產品類型的項目有所不同，在這里主要討論外包類型項目的軟體架構設計目的。 1、為大規模開發提供基礎和規范，並提供可重用的資產，軟體系統的大規模開發，必須要有一定的基礎和遵循一定的規范，這既是軟體工程本身的要求，也是客戶的要求。架構設計的過程中可以將一些公共部分抽象提取出來，形成公共類和工具類，以達到重用的目的。 2、一定程度上縮短項目的周期，利用軟體架構提供的框架或重用組件，縮短項目開發的周期。 3、降低開發和維護的成本，大量的重用和抽象，可以提取出一些開發人員不用關心的公共部分，這樣便可以使開發人員僅僅關注於業務邏輯的實現，從而減少了很多工作量，提高了開發效率。 4、提高產品的質量，好的軟體架構設計是產品質量的保證，特別是對於客戶常常提出的非功能性需求的滿足。 軟體架構設計的原則 軟體架構設計必須遵循以下原則： 1、滿足功能性需求和非功能需求。這是一個軟體系統最基本的要求，也是架構設計時應該遵循的最基本的原則。 2、實用性原則，就像每一個軟體系統交付給用戶使用時必須實用，能解決用戶的問題一樣，架構設計也必須實用，否則就會「高來高去」或「過度設計」。 3、滿足復用的要求，最大程度的提高開發人員的工作效率。 軟體架構設計的幾種視圖 我們常常在討論架構設計該做些什麼的時候，或是在架構設計評審的會議上，會提出各種各樣的問題，例如開發人員該如何記錄Log，事務如何控制？怎樣才能提高我們的開發人員的工作效率，即在單位時間內更有品質的完成更多的功能？怎樣滿足客戶的非功能性需求？怎樣讓生產環境的平台管理人員更好的維護系統？ 上面這些問題，實際上是軟體系統的不同的干係人站在不同的角度上提出的問題，要回答上面這些問題，我們就得從不同的視角來看待軟體架構設計這項工作。 1、邏輯架構視角，從系統用戶的角度考慮問題，設計出來的軟體架構能夠滿足業務邏輯的需求，能夠處理現在越來越復雜的業務邏輯需求。 2、開發架構視角，從系統開發人員的角度來考慮問題，設計的架構要易於理解，易於開發，易於單元測試，最好做到讓開發人員可以用最少的代碼行數完成功能的開發。 3、運行架構視角，從系統運行時的質量需求考慮問題，特別關注於系統的非功能需求，客戶常常都會要求我們系統的功能畫面的最長響應時間不超過4秒，能滿足2000個用戶同時在線使用，基於角色的系統資源的安全控制等。 4、物理架構視角，關注系統安裝和部署在什麼樣的環境上，例如現在最流行的企業應用服務解決方案IBM Http Server ＋ WebSphere Application Server ＋ DB2，WebLogic + Oracle等。 5、數據架構視角，如今我們開發的各類系統，如MIS，ERP，SAP，基本上都是對各類數據的操作，把一堆不太好懂的數據展現成用戶容易看懂的數據，自動處理各類數據的運算等，所以數據的持久化是十分重要的一件事情。1、分析需求和理解業務模型（或領域建模），並選定關鍵Use case。 軟體的需求，可以分為從用戶視角和開發人員視角來看，從用戶的角度看，又可以分為功能性和非功能性需求，我們必須從不同的視角和級別去全面的認識需求並分析需求，理解業務模型。實踐表明，常常被我們忽視的非功能性需求常常會導致整個項目失敗。 理解業務需求最好的方式莫過於進行領域建模，領域建模與需求分析往往是交替穿叉進行的，領域建模主要有以下三個方面的作用： ◆探索復雜問題，弄清領域知識。Martin Fowler曾經說過，他採用面向對象方法最大的好處就是它有助於解決更為復雜的問題。領域建模本身作為輔助思維的工具，幫助我們將注意力始終保持在最為重要的業務概念及其關繫上，使我們能夠不斷深入地，系統的對需求進行分析和認識。領域建模往往是一個從模糊到清晰，從零散到系統的過程。 ◆決定功能范圍，影響可擴展性。任何模型都是對現實世界某種程序的抽象，這種抽象就會忽略某一些東西，例如忽略對象的屬性和對象間的關系，而這些忽略往往都是帶有一定的目的性的，這種忽略就決定了功能的范圍。模型揭示了各種功能背後的結構，如果說定義功能相當於「拍照片」的話，那麼領域建模就相當於「做透視」，更加關注問題領域的內在結構，相當於對問題領域進行了一定的抽象，良好的領域模型不僅能很好的支持現有的功能，而且還可以在一定程度上支持未來可能出現的新需求，體現良好的可擴展性。 ◆提供交流基礎，促進有效溝通。領域建模通常會使用UML圖作為呈現的方式，這樣為我們的溝通提供了方便。當然，有時候文字在描述某些特定領域的問題時可能更適合，可以靈活運用。 在我們公司的實際軟體開發流程中，往往領域建模缺少這一環節，這可能是在以後的工作中需要進一步提高之處。 雖然我們總是期望架構設計師能全面掌握需求，但由於時間和精力的限制，擺在我們面前的現實就是架構設計師沒有時間對所有需求進行深入分析，所以我們的策略就是「把好鋼用在刀刃上」，即把大部分時間和精力花在對決定架構最重要的關鍵需求上。在選擇關鍵需求時要注意：高優先順序的需求往往是從用戶的角度來看的，可能並不是真正的關鍵需求。在《RUP實踐者指南》一書中向我們講述了如何確定關鍵功能需求？A.作為應用程序的核心或實現了系統的主要介面的功能，B.必須被實現的功能，即如果這些功能不被實現，則開發出來的軟體就失去了價值，C.覆蓋了系統架構的一些方面，但沒有被其他重要的Use case覆蓋到的功能。 2、分別從各個視角來考慮軟體架構的方方面面。 軟體的架構設計必須考慮到各方面，根據前期工作確立的領域模型，關鍵需求，系統約束等進行設計，必須從系統用戶，開發人員，系統管理員，部署管理員，數據管理員等人員的角度去分析並解決問題。比如說，如果我們的運行架構採用Cluster方式時，就必須小心Cache和Session等的使用；如果我們的業務邏輯要求我們要操作多個資料庫時，就要考慮採用支持二階段事務提交的方式。 只有將這些方方面面的問題都考慮到了，這樣的架構設計才是完整的。至於每一個視圖中，我們應該設計到什麼細節這一問題，實際上與整個項目的過程定義有關。例如，如果我們有專門安排資料庫概要設計的活動，那我們在架構設計的過程中就可以只需要關注更高層次的資料庫特性及資料庫之間的關系，而每一張表的數據字典可以在後續的相關活動中進行設計，但如果沒有這樣的活動，那我們就要細化到每一張表的每一個欄位，以及表之間的關系。 3、解決技術面的重點問題和難題 在軟體架構設計的過程中，我們往往會需要攻克一些技術面的重點問題和難題，這完全是一項極其需要扎實的理論知識和豐富的實踐經驗支撐的工作。例如，我們如何提高整個系統的性能？如何能很好的導出極其復雜的「中國式報表」（一般比西方國家產出的報表要復雜很多，而且很多開源的BI類的框架並不能完全解決問題）？ 當遇到確實是很困難的問題，可以去網路一下或Google一下，也可以去請教公司的資深技術人員或專家，或者召開小范圍的技術專題討論會議，採用腦力激盪的方法試著找找答案，這樣才能提高工作的效率。 4、召開架構設計評審會議進行同行評審。 架構設計評審是極其重要的一環，我曾將其形容為「七種武器」中的離別鉤，就是因為在會議上，同行們可能會提很多問題或意見，而且很多意見很尖銳，所以一定要虛心接受，並做好記錄，正所謂「良葯苦口利於病，忠言逆耳利於行」。 在評審會議之前，我們要完成很多准備工作，最好是能准備一份簡明扼要的電子簡報，把最重要的問題列出來，這樣在進行評審會議時，就不會漫無目的，在會議前就將這些資料發給與會人員，請他們抽空先了解一下，在會議進行時，要學會控制會議的進度，提高會議的效率。 5、針對關鍵Use case在設計的架構上實現功能來驗證架構。 對於架構設計的驗證也是一項十分重要的工作，其驗證技術有很多種，在我們公司通常會採用Sample的形式，即XP中所說的迭代0，RUP中所說的切片。這樣做的好處是既可以從實際的產品角度出發來有效的驗證架構是否滿足要求，又可以比拋棄型原型驗證技術節省成本。 這個Sample絕不是我們在解決架構設計中的問題時拿來做實驗的一些代碼的拼湊，而是完整的實現某一關鍵Use case的符合架構設計和一系列規范的可交付的代碼及相關文檔。同時，這個Sample可以作為你在給大家講解或培訓架構時的教材，也可以作為開發人員使用此架構進行開發的藍本，甚至是只需要復制粘貼，加上簡單的修改即可。 6、交付給客戶Review。 這一環節，在很多公司可能並不存在，因為他們的軟體架構並不一定需要客戶Review，但像我們這種做服務的公司，最重要的就是客尊，落實到軟體架構設計這一活動，就是讓客戶理解並接受你的架構設計方案，同時，客戶也會起到幫你驗證架構的作用。通常，我們的架構得到客戶的認可後，便可進入大規模的開發。 在交付給客戶Review時，通常可能會以會議的形式進行Review，所以我們可以參照評審會議時好的做法來召開會議，在這里就不再冗述。軟體架構設計的常見誤區及解決辦法 1、架構設計的常常會「高來高去」。所謂高來高去，實際上就是我們的架構設計僅停留在模型階段，但也絕不是產生第一支樣常式式。 2、架構設計時常常會在某些方面過度設計（Over engineering）。為了一些根本不會發生的變化而進行一系列復雜的設計，這樣的設計就叫過度設計，往往會帶來資源的浪費並且會增加開發的工作量或難度。雖然我們必須考慮到系統的擴展性，可維護性等，但切忌過度設計。有時候或許你並不能判斷出哪些設計是過度設計，此時你可以請教你的PM，讓他站在整個項目的高度來幫你決策一下。 3、架構（Architecture）不是框架(Framework)，也不是簡單的將幾種框架或技術的組合，框架本身也是有架構的。框架一般是針對於某一方面或領域的重用性和可擴展性非常好的半成品，我們可以用一句較為經典的話來總結：框架是軟體，架構不是軟體，框架是一種特殊的軟體。我們在工作中通過將許多方面的可重用的工具類，公共類，基礎類等抽象出來，即可形成一些可重用的框架。 4、架構設計絕不是新技術展示平台，合適的技術才是對於項目有利的技術，必須考慮到開發人員的能力和維護人員的能力。作為一名架構設計師應該更多的考慮如何平衡業務需求，織織運作（主要指團隊中的協作）和技術三者的關系，而不僅僅是去關注那些技術細節。 5、架構設計的成功與否決定著系統品質的好壞，因為架構設計不好而導致交付的系統Bug過多，無法滿足客戶非功能性需求等問題，從而導致項目取消的案例時有發生。架構設計不是架構設計師一個人的事情，也不是幾天就能完成的一項工作，必須是架構設計師付出大量辛勤勞動後的成果，其成敗往往與組織、主管、項目經理的支持有著密切的關系。 關於架構設計的一點通用技巧 1、分層（Layer）規則。這里的層是指邏輯上的層次（Layer），並非指物理上的層次（Tier）。目前的絕大多數的企業級應用系統中都分為三層，即表現層，領域層和數據層。在對各層次進行劃分時，主要可以從以下幾個方面來考慮：A、每一層是一個相對獨立的部分，可以作為一個整體，無需對其它層了解；B、將層次間的依賴性降到最低，即降低耦合；C、可以從某種程度上替換掉某一層，而對其它層不會產生過多的影響；D，層次並不能封閉所有的東西，假如用戶界面上增加了一個欄位，那麼領域層就要增加一個數據域，數據層就要增加一個相應的欄位。同時，過多的分層可能會對性能造成一定的影響。 2、包（package）之間不要產生循環依賴。通常包的劃分會先按不同的邏輯層來劃分，在層的包下面再按功能來劃分。避免包間的循環依賴是一個比較通用的規則，這樣的規則一定有其存在的價值和道理，之所以這樣主要是出於以下原因：A、循環依賴會使分層失去意義；B、循環依賴會帶來許多潛在的風險，如可能會產生嵌套事務（nested transaction，JavaEE標准中並不支持這種事務）的現象，我就曾遇到過這樣的問題，在一個項目中，事務放在業務邏輯層統一控制，但由於開發人員忽視了架構中這樣的原則，在持久層調用了展現層的公用類，形成了迴圈的現象，導致了嵌套事務的發生。 3、設計模式的應用。在很多人的觀念里，提供設計模式就等同於GOF的設計模式，其實設計模式是個廣泛的概念，比如需求模式、領域模式、反模式等都屬於設計模式。模式其實是一門工具，是人們對於過去解決某一類問題的經驗總結，所以我們可以在設計活動中應用各種設計模式，但是在應用這些模式之前一定要先分析清楚問題，否則就可能出現「牛頭不對馬嘴」的現象。 成功的項目總有相似之處，失敗的項目卻各有各的失敗之處。好的軟體架構設計必定是成功項目的相似之處，我們有什麼理由不把軟體架構設計做好了？

G. 一個五年架構師為什麼基本年薪酬可以達到50萬

架構師，我想很多人都知道，其實該職位頭銜在最早的領域是沒有的，它是近些年來由互聯網的發展所引發的需求，因為現階段的數據量及高並發的活躍好動，引起了不少傳統的技術人員的力不從心，企業愈發關注到了系統架構的重要性，所以不同行業開始招募架構技術人員，架構師就誕生了。

架構設計的條件

以下三個條件不適合做架構設計

對架構不感興趣，但又迫於需求；

入IT行業，年限小於4年的；

主觀能動性弱，又安於現狀的；

架構設計的優勢

更好的梳理業務的結構體系；

更好的拓展、維護及性能優化；

更好的適應企業業務靈活的推進；

更好的適應大數據的沖洗和應對；

更好的穩定性、低成本及快速迭代；

架構設計時候需要注意的地方

架構設計需要注意的地方，不是怎麼把架構搭建起來，而是必須根據業務需求，嚴格分析，實現該需求需要什麼技術會更好及更長遠發展的考慮；

另外，構建好的架構雖然可以運行，但是性能需要跟起來，否則架構設計會適得其反，增加不必要的工作量，那麼下面就詳細介紹下架構設計的策略。

平台的需求

客戶需求

在線購物、在線支付或貨到付款；

購買商品後，客戶可以與客服溝通；

購買商品過程，物流的管理及跟蹤；

收取到商品後，商品、物流評價打分；

客戶的需求為最高，也代表了企業的核心需求，當然，企業需求還包括其它很多非功能性需求，具體請查看需求梳理部分。

平台的業務架構

根據業務的需求進行子系統模塊劃分，可以劃分為商品子系統、購物子系統、支付子系統、物流子系統、客服子系統、評論子系統；而非核心需求可拆分出客服子系統、評論子系統及介面子系統。另外，根據各個子系統的核心等級，可拆分出核心子系統和非核心子系統，前者包括商品子系統、購物子系統、支付子系統及物流子系統；後者，則包括評論子系統、客服子系統及介面子系統。需要注意的是一般大型電商平台的物流系統是單獨分離出來的系統（入庫、出庫、庫存管理、配送管理及貨品管理），而這里劃分為子系統的主要目的是為演示核心架構，本架構中物流子系統一般作為對接和管理獨立子系統的對接模塊哦。

1、業務拆分目的

為了解決各個模塊子系統間的耦合、維護及拓展性；

方便單獨部署子系統，避免集中部署導致一個出問題，全部不能用；

分配專門的團隊，負責具體的子系統，最大化工作效率安排；

應對大數據，高壓力時，保護核心子系統正常使用；

2、業務的架構圖

在上面的業務架構圖中，將核心和非核心業務進行拆分，同時每個系統都要獨立部署實現，做到大數據量壓下，各個系統獨立運作，提高可用性，必要時可以暫停掉非核心系統的資源開銷，保證核心業務正常為用戶服務。

平台的技術架構

在上面業務架構圖基礎上，我們需要一個技術架構的演變過程，一切只為滿足用戶的體驗和支撐為前提，所以技術架構的搭建不是一蹴而就的，而是隨著業務的不斷衍變，系統的架構會逐漸完善更新，以實現應對業務數據量的沖擊。

1、基本的架構設計

記得很早的時候，很多中小企業所採用的架構設計十分簡單，基本使用一台伺服器來滿足一切需求部署，比如：一台伺服器同時用作應用部署、資料庫存儲以及圖片存儲等，不料的是待用戶數據達到50萬以上，系統出現很多性能問題，盡管對資料庫和程序做個各種性能優化，結果仍無明顯改善，架構如下：

後來，IT程序猿發現圖片的讀寫嚴重影響了系統性能，並將圖片單獨存放在獨立伺服器中，並且在架構中引入了Cache中間件，比如：Memcache，這種做法是可取的，而且比原來性能提高了1-2個性能級別，架構設計如下：

2、初級的架構設計

前幾年，一般的電商網站的做法是選用三台伺服器，一台部署應用，一台部署資料庫，一台部署NFS文件系統，做到將各個規模龐大並耗用性能的部分剝離到不同伺服器設備，再配備必要的緩存中間件，基本可以滿足近1000萬的數據量，具體的架構圖如下：

但是，目前主流使用的網站架構已經不同，大多採用集群的方式來實現負載均衡和高可用性，架構可以是下面的樣子：

注意：

如果涉及到多台網站伺服器的話，就會存在Session如何同步的問題，一般也是最為常用的做法，就是使用Cache中間件來存儲和管理Session信息。

3、優化的架構設計

這里為解決高並發，高可用的大型電商網站的架構設計方案，主要採用了分布式、集群、負載均衡、反向代理、消息隊列及多級緩存技術。該架構設計方案，是現今比較流程的大型電商網站採用的架構模式，比如：淘寶、京東等，也許會有細微不同的地方，但大同小異哦！具體的架構圖方案如下：

平台架構的總結

這里主要總結的是優化架構，架構按層次結構羅列組織，共分為四層，層次分工明確，高拓展，低耦合，負載均衡、集群、分布式及緩存等技術的使用，架構如下：

好了，電商平台的架構設計就介紹到這里，本篇主要是介紹架構設計的思路及應用的核心技術，供在架構設計的同學參考借鑒哦！有想了解更多的可以關注我

H. 三層架構中業務邏輯層如何設計

一般三層架構中的業務邏輯層又劃分為幾塊：

• 公共基礎服務類 Utils 例如 時間相關

• 共有抽象業務類 是基礎業務的抽象 即所有業務都可能用到的

• 共有具體業務基礎類 是基礎業務的共有基礎類

• 各個業務的實現類 實現業務目標

I. 應用架構規劃

社會保障信息系統在應用架構上可以劃分為公共基礎平台、業務應用系統和宏觀決策支持三個層次，覆蓋省、市、縣三級。總體結構參見下圖（2-1）。

圖2-1 社會保障信息系統應用架構

2.4.3.1 公共基礎平台

公共基礎平台是系統各組成部分的公共系統，為整個系統提供技術支撐。公共基礎平台支持系統內各子系統間的網路互聯、數據共享和交換，提供安全認證和安全管理、身份識別和對外公共介面等功能。主要由五大中心構成，它們分別為：

（1）網路中心。是系統內統一的網路匯接點和網路管理機構，分為省、市、區縣三級。它通過提供統一的網路介面來實現各業務部門之間、地區之間、上下級之間的網路連接。

（2）數據中心。主要有三種作用：①提供一個統一的數據交換和共享平台，使系統中的數據一致化和標准化，實現不同部門之間數據的交換和共享；②提供一個數據的「倉庫」，為各業務以及宏觀決策和公共服務提供數據支持；③建立容災備份系統，統一為各部門提供異地容災備份服務。

（3）公共服務中心。是各業務部門統一對外提供公共服務的窗口，它為社會保障對象辦理社會保障業務提供一個統一的公共服務平台。對內整合政府的政務資源，對外整合社會服務資源，通過多種服務方式和手段，使社會保障業務走出辦事大廳，延伸到社會保障對象的身邊。

（4）社會保障卡管理中心。實現對社會保障卡的管理，確保在社會保障對象范圍內社會保障卡「一人一卡，一卡通用」。

（5）身份認證（CA）中心。通過授權和認證機制，保證社會保障信息系統中數據傳輸和交易的安全，為社會保障業務的網上申報、待遇網上支付等提供安全保障。

公共基礎平台是社會保障信息系統的基礎，它為業務應用系統和宏觀決策系統提供安全、可靠、高效的運行環境。

網路中心是整個系統中的「交通通道」，是其他子系統建設的基礎。社會保障卡是社會保障對象享受社會保障服務的媒介和憑證。數據中心是系統中數據交換、共享的「樞紐」和共享數據資源的「倉庫」。它一方面橫向連接了各社會保障業務部門和社會保障服務部門，實現部門之間的數據交換和共享；另一方面縱向連接各級數據中心，實現縱向和地區之間的數據交換和共享。除此之外，它還具有集中管理交換和共享數據的功能，並提供給各級宏觀決策部門所需的決策支持數據。數據中心是社會保障卡管理中心、公共服務中心建設的基礎，要優先建設，它是整個社會保障信息系統建設的重中之重。

2.4.3.2 業務應用系統

業務應用系統在公共基礎平台中運行，支撐社會保障業務的辦理。可以分為核心業務應用系統和相關業務應用系統兩大類，這些業務應用系統負責處理具體的社會保障業務。

（1）核心業務應用系統。核心業務應用系統主要實現勞動保障、民政、社會保險等基本業務的處理，使社會保障業務達到快捷高效地運作。它的建設內容包括勞動保障業務應用系統、民政業務應用系統和社會保險業務應用系統。

（2）相關業務應用系統。按照社會保障信息系統的統一規劃和設計，建設相應的社會保障信息系統相關業務應用系統，以標準的介面把社會保障相關業務有關數據整合到社會保障信息系統數據中心之中。

2.4.3.3 宏觀決策系統

宏觀決策系統可以通過對業務數據的分析，藉助方法庫和模型庫，對社會保障業務進行監督和管理，及時發現問題，並通過宏觀決策系統和統計應用子系統，為不同層次的領導科學的決策提供支持服務。

J. 簡述分層架構的設計中要遵循哪些原則

1、最關鍵的，UI層只能作為一個外殼，不能包含任何業務邏輯(BizLogic)的處理過程；

2、設計時應該從BLL出發，而不是UI出發. BLL層在API上應該實現所有BizLogic，以面向對象的方式；

3、不管數據層是一個簡單的SqlHelper也好，還是帶有Mapping過的Classes也好，應該在一定的抽象程度上做到系統無關；

4、不管使用COM+(Enterprise Service），還是Remoting，還是WebService之類的遠程對象技術，不管部署的時候是不是真的分別部署到不同的伺服器上，最起碼在設計的時候要做這樣的考慮，更遠的，還得考慮多台伺服器通過負載均衡作集群。

(10)業務架構設計擴展閱讀

各層的作用：

1、數據訪問層：主要是對非原始數據的操作層，而不是指原始數據，也就是說，是對資料庫的操作，而不是數據，具體為業務邏輯層或表示層提供數據服務。

2、業務邏輯層：主要是針對具體的問題的操作，也可以理解成對數據層的操作，對數據業務邏輯處理，如果說數據層是積木，那邏輯層就是對這些積木的搭建。

3、界面層：主要表示WEB方式，也可以表示成WINFORM方式，WEB方式也可以表現成：aspx，如果邏輯層相當強大和完善，無論表現層如何定義和更改，邏輯層都能完善地提供服務。