今天有幸與資深專案架構師a博士一起進行架構交流，a博士根據自己多年專案的經驗總結，為我在傳輸層、資料層架構領域授業解惑，現把自己所學總結與大家分享。
一、傳輸層架構
傳輸層架構需要考慮的核心問題是單點失效與可擴充套件。
檢驗乙個網路是否無單點失效的最簡單方法就是把整個網路的拓撲圖畫出來，然後刪除網路中任意一條鏈路或裝置，如果網路資料能正常流通，則該網路符合無單點故障要求。無單點失效網路需要對通訊鏈路、通訊裝置做主備冗餘，乙個節點或鏈路發生故障，網路會切到備份裝置或鏈路中。在實際應用中，考慮到成本，在接入層、匯聚層可根據業務的重要性選擇是否做冗餘設計，但核心層裝置與鏈路必須做雙星冗餘。
傳輸層核心裝置牽一髮而動全身，網路設計需考慮未來未知的業務增加帶來的網路擴容不影響核心層網路框架。網路可擴充套件性主要體現在網路容量可擴充套件方面，實際設計中，考慮可擴充套件的最簡單的方法是假設增加一倍伺服器（根據機房物理空間計算最大裝置容量），網路核心層裝置是否可以方便擴容，網路管道是否可以負載一倍乃至幾倍的業務流量。可擴容設計對管道和交換裝置要求比較高，我的專案中兩地管道都是光纖通道，故可擴容的瓶頸在光纖兩端的交換裝置，所以專案中核心層交換裝置採用可堆疊裝置，背板頻寬10gbit或者更高。網路有較強的可擴容性保證在未來的十年或二十年內，即使機房業務擴容，網路層核心架構也不用變，只需在交換機上加塊交換板卡或在匯聚層加臺匯聚交換機。
二、資料層架構
傳統的業務網路中，個部門都有自己獨立業務資料庫，雖然現在的資料庫集群技術，分布式技術支援物理離散資料庫集群的資料互動分析，但隨著大資料探勘技術的發展，資料計算量的提高，資料庫之間的資料互動速度會成為資料探勘的瓶頸，故資料庫設計應朝向所有機房所有業務「乙個資料庫」的方向發展，甚至是所有機房所有業務「一張表」的方向發展。「乙個資料庫」是目前oltp與olap系統統一的趨勢，「一張表」可以用資料立方體技術實現。
以前都是自己閉門造車，研究通訊網和資料探勘，與達者交流的機會實屬不易，十分珍惜，做總結與大家分享。
傳輸層與網路層的區別
傳輸層位於網路層之上，傳輸層協議為不同 主機上執行的應用程序提供 邏輯通訊，而 網路層協議 為不同主機提供邏輯通訊。網路層負責ip資料報的產生以及ip資料報在邏輯網路上的路由 網路層只是根據網路位址將源結點發出的資料報傳送到目的結點 點到點 其主要任務是 通過路由選擇演算法，為報文或分組通過通訊子網...
三層架構 資料訪問層 業務邏輯層 表示層
三層架構 資料訪問層 業務邏輯層 表示層方便團隊開發，復用 不屬於三層，但跟三層息息相關 實體類 跟資料庫表對應的類 資料訪問層 連線資料庫，執行sql語句 cn.edu.xcu.sims.dao basedao 增刪改的封裝 public int executeupdate string sql,...
二層架構與三層架構記述
二層架構的缺點 如果功能不需要經常變化或修改,則是乙個比較好而且快的實現方式.但是在使用者介面,都是通過sqldatasource控制項來連線資料來源的,並將sql語句直接寫入到各個頁面的html 中 因此帶來的問題是 sql語句與html 的混合程式設計,不利於各類開發人員的分工合作,如頁面設計人...