halo~我是bay_Tong桐小白
本文內容是桐小白個人對所學知識進行的總結和分享，知識點會不定期進行編輯更新和完善，了解最近更新內容可參看更新日志，歡迎各位大神留言、指點

【更新日志】

最近更新：

• 暫無編輯記錄，持續更新中……

軟體體系結構基本概念

軟體體系結構

目前還沒有一個公認的關于軟體體系結構的定義

Bass、Clements和Kazman給出了如下定義：“一個程式或計算機系統的軟體體系結構是指系統的一個或者多個結構，結構中包括軟體的構件、構件的外部可見屬性以及它們之間的相互關系，外部可見屬性則是指軟體構件提供的服務、性能、使用特性、錯誤處理、共享資源使用等，”
【這一定義強調在任一體系結構表述中“軟體構件”的角色】

構件：是面向軟體體系架構的可復用軟體模塊，構件是可復用的軟體組成成份，可被用來構造其他軟體，它可以是被封裝的物件類、類樹、一些功能模塊、軟體框架、軟體構架（或體系結構）、檔案、分析件、設計模式等

Dewayne Perry和A1exander Wo1f曾這樣定義：軟體體系結構是具有一定形式的結構化元素，即構件的集合，包括處理構件、資料構件和連接構件，

• 處理構件負責對資料進行加工
• 資料構件是被加工的資訊
• 連接構件把體系結構的不同部分組合連接起來

【這一定義注重區分處理構件、資料構件和連接構件】

在體系結構設計的環境中，軟體構件可以簡單到程式模塊或者面向物件的類，也可以擴充到包含資料庫和能夠完成客戶與服務器網路配置的中間件

體系結構設計是一系列決策和基本原理的集合，這些決策的目標在于開發高效的軟體體系結構，在體系結構設計中所強調的基本原理是系統的可理解性、可維護性和可擴展性

體系結構的模式、風格、框架

模式： 軟體設計模式是從軟體設計程序中總結出來的，是針對特定問題的解決方案

建筑師C.Alexander對模式給出的經典定義是：每個模式都描述了一個在我們的環境中不斷出現的問題及該問題解決方案的核心

在軟體系統中可以將模式劃分為以下三類：

• 體系結構模式：表達了軟體系統的基本結構組織形式或者結構方案，包干了一組預定義的子系統，規定了這些子系統的責任，同時還提供了用于組織組織和管理這些子系統的規則和向導，典型的體系結構模式如計算機網路結構模型——開放式系統互聯參考模型（OSI參考模型）
• 設計模式：為軟體系統的子系統、構件或者構件之間的關系提供一個精煉之后的解決方案，描述了在特定環境下，用于解決通用軟體設計問題的構件以及這些構件相互通信時的各種結構，有代表性的設計模式是Erich Gamma及其同事提出的23種設計模式
• 慣用法：是與編程語言相關的低級模式，描述如何實作構件的某些功能，或者利用編程語言的特性來實作構件內部要素之間的通信功能

風格： 同一個問題可以有不同的解決問題的方案或模式，但我們根據經驗，通常會強烈傾向于采用特定的模式，這就是風格，包括：

• 一組構件（比如資料庫、計算模塊）完成系統需要的某種功能
• 一組連接件，它們能使構件間實作通信、合作和協調
• 約束，定義構件如何集成為一個系統
• 語意模型，它能使設計者通過分析系統構成成分的性質來理解系統的整體性質

體系結構風格定義了一個系統家族，即一個體系結構定義一個詞匯表（包含一些構件和連接件型別）和一組約束，這組約束指出系統是如何將這些構件和連接件組合起來，體系結構風格反映了領域中眾多系統所共有的結構和語意特性，并指導如何將各個模塊和子系統有效地組成一個完整的系統

框架 ：隨著應用的發展和完善，某些帶有整體性的應用模式被逐漸固定下來，形成特定的框架，包括基本構成元素和關系，框架是特定應用領域問題的體系結構模式，框架定義了基本構成單元和關系后，開發者就可以集中精力解決業務邏輯問題

在組織形式上，框架是一個待實體化的完整系統，定義了軟體系統的元素和關系，創建了基本的模塊，定義了涉及功能更改和擴充的插件位置，典型的框架例子有MFC框架和Struts框架

體系結構的重要作用

• 體系結構的表示有助于風險承擔者（專案共利益者）進行交流
• 體系結構突出了早期設計決策，對隨后的所有軟體工程作業都具有深遠的影響，對最終軟體的質量和整個系統的成功都具有重要作用
• 軟體體系結構是可傳遞和可復用的模型，體系結構的風格和模式可以在需求相似的其他系統中進行復用，體系結構級的復用粒度比代碼級的復用粒度更大，由此帶來的益處也就更大

通用模型

【通用模型可以應用于許多不同型別的系統，此部分選擇有代表性的結構進行總結，體系結構的模式選擇設計模式做闡述，風格選擇典型的三種體系結構風格做闡述，框架選擇MVC、J2EE、PCMEF與PCBMER框架做闡述】

設計模式概述（更新中……）

典型的體系結構風格

資料流風格

當輸入資料經過一系列的計算和操作構件的變換形成輸出資料時，可以應用這種體系結構

管道/過濾器、批處理序列都屬于資料流風格

管道/過濾器結構

管道/過濾器結構擁有一組被稱為過濾器的構件，這些構件通過管道連接，管道將資料從一個構件傳送到下一個構件，每個過濾器獨立于其上游和下游的構件而作業，過濾器的設計要針對某種形式的資料輸入，并且產生某種特定形式的資料輸出，過濾器不需要了解與之相鄰的過濾器的作業

管道/過濾器風格優點：

• 使得軟構件具有良好的隱蔽性和高內聚、低耦合的特點
• 允許設計者將整個系統的輸入/輸出行為看成是多個過濾器的行為的簡單合成
• 支持軟體復用，只要提供適合在兩個過濾器之間傳送的資料，任何兩個過濾器都可被連接起來
• 系統維護和增強系統性能簡單，新的過濾器可以添加到現有系統中來；舊的可以被改進的過濾器替換掉
• 允許對一些如吞吐量、死鎖等屬性進行分析
• 支持并行執行，每個過濾器是作為一個單獨的任務完成，因此可與其他任務并行執行

管道/過濾器風格缺點：

• 通常導致行程成為批處理的結構，這是因為雖然過濾器可增量式地處理資料，但它們是獨立的，所以設計者必須將每個過濾器看成一個完整的從輸入到輸出的轉換
• 不適合處理互動的應用，當需要增量地顯示改變時，這個問題尤為嚴重
• 因為在資料傳輸上沒有通用的標準，每個過濾器都增加了決議和合成資料的作業，這樣就導致了系統性能下降，并增加了撰寫過濾器的復雜性

批處理序列結構

如果資料流退化成為單線的變換，則成為批處理序列，這種結構接收一批資料，然后應用一系列連續的構件（過濾器）變換它

呼叫/回傳風格

該體系結構風格便于設計出易于修改和擴展的程式結構，此類結構存在3種子風格

主程式/子程式體系結構

這種傳統的程式結構將功能分解為一個控制層次，其中“主”程式呼叫一組程式構件，這些程式構件又去呼叫別的程式構件，如下圖所示，這種結構總體上為樹狀結構，可以在底層存在公共模塊

當主程式/子程式體系結構的構件分布在網路上的多個計算機上時，則稱主程式對子程式的呼叫為遠程程序呼叫，這種系統的目標是要通過將運算分布到多臺計算機上來充分利用多臺處理器，最終達到提高系統性能的目的

主程式/子程式體系結構的優點：

• 可以使用自頂向下，逐步分解的方法得到體系結構圖，典型的拓撲結構為樹狀結構，基于定義-使用關系對子程式進行分解，使用程序呼叫作為程式之間的互動機制
• 采用程式設計語言支持的單執行緒控制

主要缺點：

• 子程式的正確性難于判斷，需要運用層次推理來判斷子程式的正確性，因為子程式的正確性取決于它呼叫的子程式的正確性
• 子系統的結構不清晰，通常可以將多個子程式合成為模塊

面向物件風格

系統的構件封裝了資料和必須應用到該資料上的操作，構件間通過訊息傳遞進行通信與合作，與主程式/子程式的體系結構相比，面向物件風格中的物件互動會復雜一些

面向物件風格與網路應用的需求在分布性、自治性、協作性、演化性等方面具有內在的一致性

面向物件風格的優點:

• 因為物件對其他物件隱藏它的表示，所以可以改變一個物件的表示，而不影響其他物件
• 設計者可將一些資料存取操作的問題分解成一些互動的代理程式的集合

面向物件風格的缺點：

• 為了使一個物件和另一個物件通過程序呼叫等進行互動，必須知道物件的標識，只要一個物件的標識改變了，就必須修改所有其他明確呼叫它的物件
• 必須修改所有顯式呼叫它的其他物件，并消除由此帶來的一些副作用，例如，如果A使用了物件B，C也使用了物件B，那么，C對B的使用所造成的對A的影響可能是料想不到的

雜項：

• OMG：物件管理組，于1989年由一些廠商創建，其目的是建立網路中分布式物件（組件）的標準結構，OMG組織是一個國際性的非盈利組織，其職責是為應用開發提供一個公共框架，制訂工業指南和物件管理規范，加快物件技術的發展
• OMA：物件管理體系結構，由OMG于1990年提出，定義了軟體系統參考模型，包括物件模型和參考模型兩部分 OMA物件模型定義如何描述異質環境環境中的分布式物件 OMA參考模型描述物件之間的互動
• CORBA：公共物件請求代理體系結構，以物件管理體系結構（OMA）為基礎，是由OMG組織制訂的一種標準的面向物件應用程式體系規范，或者說CORBA體系結構是物件管理組（OMG）為解決分布式處理環境(DCE)中，硬體和軟體系統的互連而提出的一種解決方案

層次結構風格

整個系統被組織成一個層次結構，每一層為上層提供服務，并作為下一層的客戶

從外層到內層，每層的操作逐漸接近機器的指令集

• 在最外層，構建完成界面層的操作；
• 在最內層，構件完成與作業系統的連接；
• 中間層提供各種實用程式和應用軟體功能

這種風格支持基于抽象程度遞增的設計，允許將復雜問題分解成一個增量步驟序列的實作，由于每一層最多只影響兩層，同時只要給相鄰層提供相同的介面，允許每層用不同的方法實作，同樣為軟體復用提供了強大的支持

層次結構具有以下優點:

• 支持基于抽象程度遞增的系統設計，使設計者可以把一個復雜系統按遞增的步驟進行分解
• 支持功能增強，因為每一層至多和相鄰的上下層互動，因此，功能的改變最多影響相鄰的內外層
• 支持復用，只要提供的服務介面定義不變，同一層的不同實作可以交換使用，這樣，就可以定義一組標準的介面，從而允許各種不同的實作方法

層次結構缺點如下:

• 并不是每個系統都可以很容易地劃分為分層的模式，甚至即使一個系統的邏輯結構是層次化的，出于對系統性能的考慮，系統設計師不得不把一些低級或高級的功能綜合起來
• 很難找到一個合適的、正確的層次抽象方法

倉庫風格

資料庫系統、超文本系統和黑板系統都屬于倉庫風格，在這種風格中，資料倉庫（如檔案或資料庫）位于這種體系結構的中心，其他構件會經常訪問該資料倉庫，并對倉庫中的資料進行增加、修改或洗掉操作

客戶軟體訪問中心倉庫，某下情況下倉庫是被動的，也就是說，客戶軟體獨立于資料的任何變化或其他客戶軟體的動作而訪問資料，此方式相當于傳統型資料庫系統

該方式的一個變種是將中心存盤庫變換成“黑板”，黑板構件負責協調資訊在客戶間的傳遞，當用戶感興趣的資料發生變化時，它將通知客戶軟體

黑板系統的組成：

• 知識源：知識源中包含獨立的、與應用程式相關的知識，知識源之間不直接進行通信，它們之間的互動只通過黑板來完成
• 黑板資料結構：黑板資料是按照與應用程式相關的層次組織的、解決問題的資料，知識源通過不斷地改變黑板資料來解決問題
• 控制：控制完全由黑板的狀態驅動，黑板狀態的改變決定使用的特定知識

黑板系統的傳統應用是信號處理領域（如語音和模式識別），另一應用是松耦合代理資料共享存取

黑板系統的優點：

• 對可更改性和可維護性的支持
• 可復用的知識源
• 支持容錯性和健壯性

黑板系統的不足：

• 測驗困難，黑板系統的計算沒有依據確定的演算法，其結果常常不可再現，此外，錯誤假設也是求解程序的組成部分
• 不能保證有好的求解方案，黑板系統往往只能正確解決所給任務的某一百分比
• 難以建立好的控制策略，控制策略不能以一種直接方式設計，而需要一種實驗的方法
• 低效，黑板系統在拒絕錯誤假設中要承受多余的計算開銷
• 昂貴的開發作業，絕大多數黑板系統要花幾年時間來進化
• 缺少對并行機制的支持 ，黑板體系結構不能避免采用了知識源潛在并行機制的控制策略，但它不提供它們的并行執行，對黑板上中心資料的并發訪問也必須是同步的

體系結構框架

模型-視圖-控制器（MVC）

MVC框架即模型-視圖-控制器（model-view-controller）框架，它強調將用戶輸入、資料模型和資料表示的方式分開設計，一個互動式應用系統由模型（model）、視圖（view）和控制器（controller）3個部件組成，分別對應于內部資料、資料表示和輸入/輸出控制部分

• 模型物件（Model）：模型物件獨立于外在顯示內容和形式，代表應用領域中的業務物體和業務規則，是整個模型的核心，模型物件的變化通過事件處理通知視圖和控制器物件
• 視圖物件（View）：視圖物件代表GUI物件，并且以用戶需要的格式表示模型狀態，是互動系統與外界的介面，視圖物件可以包含子視圖，子視圖用于顯示模型的不同部分，通常，每個視圖物件對應一個控制器物件
• 控制器物件（Controller）：控制器物件代表滑鼠和鍵盤事件，它處理用戶的輸入行為并給模型發送業務事件，再將業務事件決議為模型應執行的動作；同時，模型的更新與修改也將通過控制器來通知視圖，從而保持各個視圖與模型的一致性，

模型是核心資料和功能，視圖只關心顯示資料，控制只關心用戶輸入，這種結構由于將資料和業務規則從表示層分開，因此可以最大化地重用代碼

J2EE體系結構框架（更新中……）

PCMEF與PCBMER框架（更新中……）

特定領域的軟體體系結構

除通用模型外，對于特別的應用還需要特別的體系結構模型，雖然這些系統實體的細節會有所不同，但共同的體系結構在開發新系統時是能夠復用的，這些體系結構模型稱為領域相關的體系結構

類屬模型

概念： 類屬模型是從許多實際系統中抽象出來的一般模型，它封裝了這些系統的主要特征

簡單說可以理解為，類屬模型將各種已經完成好的一般模型（也就是具有某一種小功能的組件）組合在一起，利用其它不同的結構進行聯系和組織，完成具有某一特定領域的系統功能的實作，是一種綜合性質的體系結構

典型用例： 類屬模型的一個最著名的例子是編譯器模型，由這個模型已開發出了數以千計的編譯器，編譯器一般包括以下模塊：

• 詞法分析器：將輸入的語言符號轉換成相應的內部形式
• 符號表：由詞法分析器建立，保留程式中出現的名字及其型別資訊
• 語法分析器：檢查正被編譯的語言語法，它使用該語言定義的文法來建立一棵語法樹
• 語法樹：是正被編譯的程式在機器內部的結構表示
• 語意分析器：使用來自語法樹和符號表的資訊檢查這個輸入程式的語意正確性
• 代碼生成器：遍歷語法樹并生成機器代碼

構成編譯器的組件可以依照不同的體系結構模型來組織，編譯器能使用組合模型來實作，如總體上可采用資料流風格，并將符號表作為容器來共享資料

這個模型現在仍然被廣泛使用，程式編譯時沒有用戶互動的影響，但當編譯器要與其它語言處理工具（如結構化的編輯系統、互動式除錯器、高質量列印機等）集成時效率會很低，這種情形下一般系統組件可以使用基于容器（倉庫）模型來組織

參考模型

概念： 參考模型源于對應用領域的研究，它描述了一個理想化的包含了系統應具有的所有特征的軟體體系結構，它是更抽象且是描述一大類系統的模型，并且也是對設計者有關某類系統的一般結構的指導

典型用例： 典型的例子由國際化標準組織（ISO）與1978年提出的計算機網路結構模型——開放式系統互連參考模型（OSI）參考模型，它描述了開放系統互連的標準，如果系統遵從這個標準，就可以與其它遵從該標準的系統互連

PS： 以上兩種不同型別的模型之間并不存在嚴格的區別，也可以將類屬模型視為參考模型，

兩者區別之一是類屬模型可以直接在設計中復用，而參考模型一般是用于領域概念間的交流和對可能的體系結構做出比較；另外，類屬模型通常是經過“自下而上”地對已有系統的抽象，而參考模型是“由上到下”地產生的

分布式系統結構

集中式計算與分布式計算

• 集中式計算技術：廣泛使用的是大型機/小型機計算模型，這種計算模型幾乎完全依賴于一臺大型的中心計算機（稱為宿主機）的處理能力，通過和它相連的非智能終端（用戶設備，往往僅僅作為一臺輸入輸出設備使用）來實作宿主機上的應用程式，在多用戶環境中宿主機應用程式既負責與用戶的互動，又負責對資料的管理，隨著用戶的增加，對宿主機能力的要求不斷提高
• 分布式系統結構：20c80s之后集中式結構主要被以PC為主的微機網路所取代，網路上所有計算機都有處理能力，每個新加入的用戶都對網路處理能力的提高有貢獻，可以使用網上多臺計算機來完成一個共同的處理任務，如果某一臺計算機脫離了網路（發生故障或關機）對網上的其他用戶不會有大的影響

分布式計算模型的優點

• 資源共享，分布式系統允許硬體、軟體等資源共享使用
• 經濟性，分布式計算性價比要高于集中式結構
• 性能與可擴展性，分布式應用程式能利用網路上可獲得的資源，通過使用聯合起來的多個網路結點的計算能力獲得性能方面的提升
• 固有分布性，有些應用程式是固有分布式的，如遵循客戶機/服務器模型的資料庫應用程式
• 健壯性，大多數情況下網路上的一臺機器或多處理器系統中的一個CPU的崩潰不會影響到系統的其余部分

多處理器體系結構

概念： 是分布式系統的一個最簡單的模型，系統由許多行程組成，這些行程可以在不同的處理器上并行運行，可以極大地提高系統的性能

適用場合： 由于大型實時系統對回應時間要求較高，這種模型在大型實時系統中比較常見，大型實時系統需要實時采集資訊，并利用采集到的資訊進行決策，然后發送信號給執行機構，

客戶機/服務器體系結構

概念： 客戶機/服務器（client/server，C/S）體系結構是基于資源不對等，且為實作共享而提出來的，定義了作業站如何與服務器相連，以將資料和應用分布到多個處理機上

主要組成部分：

• 服務器：負責給其他子系統提供服務（如資料庫服務器提供資料存盤和管理服務，檔案服務器提供檔案管理服務，列印服務器提供列印服務等）
• 客戶機：向服務器請求服務，客戶機通常都是獨立的子系統，在某段時間內，可能有多個客戶機程式在并發運行
• 網路：連接客戶機和服務器，通常客戶機程式和服務器程式放在不同的機器上運行

在C/S體系結構中，客戶機可以通過遠程呼叫來獲取服務器提供的服務，因此，客戶機必須知道可用的服務器的名字及它們所提供的服務，而服務器不需要知道客戶機的身份，也不需要知道有多少臺服務器在運行

邏輯結構的三層劃分： 在邏輯上，通常將應用系統劃分為三層，即資料管理層、應用邏輯層、表示層

• 資料管理層：關注資料存盤及管理操作，通常選擇成熟的關系資料庫管理系統來承擔這項任務
• 應用邏輯層：關注與業務相關的處理邏輯
• 表示層：關注用戶界面及與用戶的互動

兩層C/S體系結構

傳統的C/S體系結構為二層的C/S體系結構，在這種體系結構中，一個應用系統被劃分為客戶機和服務器兩部分

二層C/S體系結構可以有兩種形態：

• 瘦客戶機模型，即資料管理部分和應用邏輯部分都在服務器上執行，客戶機只負責表示部分
• 胖客戶機模型，服務器只負責對資料的管理，客戶機實作應用邏輯和與系統用戶的互動

胖客戶機模型能夠利用客戶機的處理能力，比瘦客戶機模型在分布處理上更有效，胖客戶機的資料處理流程如下：

隨著企業規模的日益擴大，軟體復雜程度的不斷提高，胖客戶機模型逐漸暴露出缺點：

• 開發成本較高，C/S體系結構對客戶端軟硬體配置要求較高，增加了整個系統的成本
• 用戶界面風格不一，使用繁雜，不利于推廣使用
• 軟體移植困難，采用不同工具或平臺開發的軟體，一般互不兼容，很難移植到其他平臺上運行
• 軟體維護和升級困難，由于應用程式安裝在客戶端，若軟體需要維護則每臺客戶機上的軟體均需要更新或升級

三層C/S體系結構

為了避免選擇瘦客戶機模型產生的伸縮性和性能的問題以及選擇胖客戶機模型產生的系統管理上的問題，產生了三層C/S體系結構，三層C/S體系結構中增加了一個應用服務器，可以將整個應用邏輯駐留在應用服務器上，只有表示層存在于客戶機上

三層C/S體系結構在系統上與邏輯結構上相似，被劃分為表示層、應用邏輯層、資料層三個部分

• 表示層：是應用程式的用戶界面部分，擔負著用戶與應用程式之間的對話功能，它用于檢查用戶從鍵盤等輸入的資料，顯示應用程式輸出的資料，一般采用圖形用戶界面（GUI）
• 應用邏輯層：應用邏輯層為應用系統的主體部分，包含具體的業務處理邏輯，通常在功能層中包含有確認用戶對應用和資料庫存取權限的功能以及記錄系統處理日志的功能
• 資料層：資料層主要包括資料的存盤及對資料的存取操作，一般選擇關系型資料庫管理系統（RDBMS）

三層C/S體系結構資料處理流程如下：

三層C/S結構具有的優點：

• 允許合理地劃分三層結構的功能，使之在邏輯上保持相對獨立性，能提高系統和軟體的可維護性和可擴展性
• 允許更靈活有效地選用相應的平臺和軟體系統，使之在處理負荷能力上與處理特性上分別適應于結構清晰的三層；并且這些平臺和各個組成部分可以具有良好的可升級性和開放性
• 應用的各層可以并行開發，可以選擇各自最適合的開發語言
• 利用功能層有效地隔離開表示層與資料層，未授權的用戶難以繞過功能層而利用資料庫或黑客手段去非法地訪問資料層，為嚴格的安全管理奠定了堅實的基礎

【PS：需注意的是三層C/S結構各層間的通信效率若不高，即使分配給各層的硬體能力很強，整體性能可能也會達不到要求，此外設計時必須慎重考慮三層間的通信方法、通信頻度、資料量，這和提高各層的獨立性一樣是三層C/S結構的關鍵問題】

瀏覽器/服務器（B/S）體系結構

瀏覽器/服務器（B/S）風格是三層應用結構的一種實作方式

• 瀏覽器：也可以說是客戶端，只有簡單的輸入輸出功能，處理極少部分的事務邏輯，由于客戶不需要安裝客戶端，只要有瀏覽器就能上網瀏覽，所以它面向的是大范圍的用戶，所以界面設計得比較簡單，通用
• WEB服務器：扮演著資訊傳送的角色，當用戶想要訪問資料庫時，就會首先向WEB服務器發送請求，WEB服務器統一請求后會向資料庫服務器發送訪問資料庫的請求，這個請求是以SQL陳述句實作的
• 資料庫服務器：當資料庫服務器收到了WEB服務器的請求后，會對SQL陳述句進行處理，并將回傳的結果發送給WEB服務器，接下來，WEB服務器將收到的資料結果轉換為HTML文本形式發送給瀏覽器，也就是我們打開瀏覽器看到的界面

B/S體系結構主要利用WWW瀏覽器技術，結合瀏覽器的多種腳本語言，用通用瀏覽器實作了原來需要復雜的專用軟體才能實作的強大功能，并節約了開發成本，從某種程度上說B/S結構是一種全新的軟體體系結構

B/S體系結構作業原理：

B/S體系結構具有的優點：

• 基于B/S體系結構的軟體，系統安裝、修改和維護全在服務器端解決，用戶在使用系統時，僅僅需要一個瀏覽器就可運行全部的模塊，真正達到了“零客戶端”的功能，很容易在運行時自動升級
• B/S體系結構還提供了異種機、異種網、異種應用服務的聯機、聯網和統一服務的最現實的開放性基礎

B/S體系結構與C/S體系結構關系與區別：

B/S架構是從C/S架構改進而來，可以說是三層C/S架構，由此可見兩者關系不一般，B/S從C/S中脫離而出，后來隨著WEB技術的飛速發展以及人們對網路的依賴程度加深，B/S一舉成為當今最流行的網路架構，兩種架構都在各自崗位上虎虎生威，它們各有千秋，都是非常重要的網路架構，在回應速度，用戶界面，資料安全等方面，C/S強于B/S，但是在業務擴展和適用www條件下，B/S明顯勝過C/S，可以這么說，B/S的強項就是C/S的弱項，反之亦然，它們各有優缺點，相互無法取代，

C/S結構與B/S結構兩種模式各自擁有其特色優勢，在不同的系統環境與操作平臺下，選擇較為接近或交叉進行混合模式的使用，可以保證資料的敏感性、安全性和穩定發展，還可以加強對資料庫的修改與新增記錄的操作，對客戶端程式進行保護，提高資源資料的互動性能，實作系統維護成本較低、維護方式較簡便、布局更合理、網路資料使用效率較高的目的，采用C/S與B/S混合模式才是最佳方案

分布式物件體系結構

在B/S模型中客戶機和服務器的地位是不同的，客戶機必須要知道服務器的存在及其所提供的服務，而服務器則不需要知道客戶機的存在，設計者必須決定服務在哪里提供，要規劃系統的伸縮性，當有較多客戶機增加到系統中時需要考慮如何將服務器上的負載分布開來，分布式系統設計旨在去掉客戶機與服務器之間的差別，

分布式環境下，構件是一些靈活的軟體模塊，它們可以位置透明、語言獨立和平臺獨立地互相發送訊息，實作請求服務，構件之間并不存在客戶機與服務器的界限，接受服務者扮演客戶機的角色，提供服務者就是服務器

分布式物件的實質是在分布式異構環境下建立應用系統框架和物件構件，它將應用服務分割成具有完整邏輯含義的獨立子模塊（稱為構件），各個子模塊可放在同一臺服務器或分布在多臺服務器上運行，模塊之間通過中間件互相通信

PS：傳統通信方式與中間件通信方式

• 傳統通信方式：通過一種集中管理式的固定的服務介面，或進行能力有限的遠程程序呼叫，這種方式不僅開銷大，也難于開發，要進行成功的軟體系統集成也存在很多障礙
• 中間件通信方式：如硬體總線允許不同的卡插于其上以支持硬體設備之間的通信一樣，通常將這個中間件稱為軟體總線或物件請求代理，它的作用是在物件之間提供一個無縫介面

分布式物件技術的應用目的是為了降低主服務器的負荷、共享網路資源、平衡網路中計算機業務處理的分配，提高計算機系統協同處理的能力，從而使應用的實作更為靈活

當前主流的分布式物件技術規范有：OMG的CORBA、Microsoft的.NET、Sun公司的J2EE等，它們均支持服務端構件的開發，都有各自的特點

代理

代理可以用于構建帶有隔離組件的分布式軟體系統，該軟體通過遠程服務呼叫進行互動，代理者負責協調通信，諸如轉發請求以及傳遞結果和例外等

1991年OMG基于面向物件技術給出了以物件請求代理（ORB）為中心的分布式應用體系結構（CORBA）

其中ORB是一個關鍵的通信機制，它以實作互操性為主要目標，處理物件之間的訊息分布，在ORB之上有4個物件介面：

• 物件服務：定義加入ORB的系統級服務，如安全性、命名和事務處理，它們是與應用領域無關的
• 公共設施：水平級的服務，定義應用程式級服務
• 領域介面：面向特定的領域
• 應用介面：面向指定的現實世界應用，是指供應商或用戶借助于ORB、公共物件服務及公共設施而開發的特定產品

CORBA有很廣泛的應用，它易于集成各廠商的不同計算機，從大型機一直到微型內嵌式系統的終端桌面，是針對大中型企業應用的優秀的中間件，最重要的是，它使服務器真正能夠實作高速度、高穩定性處理大量用戶的訪問

持續更新中……
我是桐小白，一個摸爬滾打的計算機小白