分散式架構
在分散式架構中，元件分佈在不同的平臺上，多個元件可以透過通訊網路相互協作以實現特定的目標。
在這種架構中，資訊處理不侷限於單一機器，而是分佈在多臺獨立計算機上。
分散式系統可以用客戶端-伺服器架構來演示，該架構構成了多層架構的基礎；替代方案包括諸如CORBA之類的代理架構和麵向服務的架構 (SOA)。
有多種技術框架支援分散式架構，包括.NET、J2EE、CORBA、.NET Web服務、AXIS Java Web服務和Globus Grid服務。
中介軟體是一種基礎設施，它適當地支援分散式應用程式的開發和執行。它在應用程式和網路之間提供緩衝。
它位於系統中間，管理或支援分散式系統的不同元件。例如事務處理監控器、資料轉換器和通訊控制器等。
中介軟體作為分散式系統基礎設施
分散式架構的基礎是其透明性、可靠性和可用性。
下表列出了分散式系統中不同形式的透明性：
| 序號 | 透明性及描述 |
|---|---|
| 1 | 訪問透明性 隱藏資源的訪問方式以及資料平臺的差異。 |
| 2 | 位置透明性 隱藏資源的物理位置。 |
| 3 | 技術透明性 向用戶隱藏不同的技術，例如程式語言和作業系統。 |
| 4 | 遷移/重新定位透明性 隱藏正在使用的可能移動到其他位置的資源。 |
| 5 | 複製透明性 隱藏可能在多個位置複製的資源。 |
| 6 | 併發透明性 隱藏可能與其他使用者共享的資源。 |
| 7 | 故障透明性 向用戶隱藏資源的故障和恢復。 |
| 8 | 永續性透明性 隱藏資源（軟體）是駐留在記憶體中還是磁碟中。 |
優點
資源共享 - 共享硬體和軟體資源。
開放性 - 靈活使用不同廠商的硬體和軟體。
併發性 - 併發處理以提高效能。
可擴充套件性 - 透過新增新資源來增加吞吐量。
容錯性 - 發生故障後能夠繼續執行的能力。
缺點
複雜性 - 比集中式系統更復雜。
安全性 - 更容易受到外部攻擊。
可管理性 - 系統管理需要更多努力。
不可預測性 - 響應時間取決於系統組織和網路負載，不可預測。
集中式系統與分散式系統
| 標準 | 集中式系統 | 分散式系統 |
|---|---|---|
| 經濟性 | 低 | 高 |
| 可用性 | 低 | 高 |
| 複雜性 | 低 | 高 |
| 一致性 | 簡單 | 高 |
| 可擴充套件性 | 差 | 好 |
| 技術透明性 | 同構 | 異構 |
| 安全性 | 高 | 低 |
客戶端-伺服器架構
客戶端-伺服器架構是最常見的分散式系統架構，它將系統分解為兩個主要的子系統或邏輯程序：
客戶端 - 這是第一個向第二個程序（即伺服器）發出請求的程序。
伺服器 - 這是第二個程序，它接收請求，執行請求並向客戶端傳送回覆。
在這種架構中，應用程式被建模為由伺服器提供的一組服務和使用這些服務的一組客戶端。伺服器不需要了解客戶端，但客戶端必須知道伺服器的身份，並且處理器到程序的對映不一定是1:1。
基於客戶端的功能，客戶端-伺服器架構可以分為兩種模型：
瘦客戶端模型
在瘦客戶端模型中，所有應用程式處理和資料管理都由伺服器執行。客戶端僅負責執行演示軟體。
當將遺留系統遷移到客戶端伺服器架構時使用，其中遺留系統本身充當伺服器，並在客戶端實現圖形介面。
一個主要缺點是它會給伺服器和網路帶來沉重的處理負載。
厚/胖客戶端模型
在厚客戶端模型中，伺服器只負責資料管理。客戶端上的軟體實現應用程式邏輯和與系統使用者的互動。
最適合新的C/S系統，其中客戶端系統的功能是預先知道的。
比瘦客戶端模型更復雜，尤其是在管理方面。必須在所有客戶端上安裝新版本的應用程式。
優點
職責分離，例如使用者介面演示和業務邏輯處理。
伺服器元件的可重用性和併發潛力。
簡化了分散式應用程式的設計和開發。
它使將現有應用程式遷移或整合到分散式環境中變得容易。
當大量客戶端訪問高效能伺服器時，它也能有效利用資源。
缺點
缺乏處理需求變化的異構基礎設施。
安全問題。
伺服器可用性和可靠性有限。
可測試性和可擴充套件性有限。
胖客戶端同時包含表示層和業務邏輯。
多層架構（n層架構）
多層架構是一種客戶端-伺服器架構，其中表示、應用程式處理和資料管理等功能在物理上是分開的。透過將應用程式分成多層，開發人員可以選擇更改或新增特定層，而不是重新設計整個應用程式。它提供了一個模型，開發人員可以使用該模型建立靈活且可重用的應用程式。
多層架構最常用的情況是三層架構。三層架構通常由表示層、應用程式層和資料儲存層組成，並且可以在單獨的處理器上執行。
表示層
表示層是應用程式的頂層，使用者可以直接訪問，例如網頁或作業系統GUI（圖形使用者介面）。該層的首要功能是將任務和結果轉換成使用者可以理解的內容。它與其他層通訊，以便將結果放置到瀏覽器/客戶端層和網路中的所有其他層。
應用層（業務邏輯層、邏輯層或中間層）
應用層協調應用程式、處理命令、做出邏輯決策、評估和執行計算。它透過執行詳細的處理來控制應用程式的功能。它還移動和處理兩層之間的的資料。
資料層
在此層中，資訊儲存在資料庫或檔案系統中並從中檢索。然後將資訊傳遞迴進行處理，然後傳遞迴使用者。它包括資料永續性機制（資料庫伺服器、檔案共享等）併為應用程式層提供API（應用程式程式設計介面），提供管理儲存資料的方法。
優點
比瘦客戶端方法效能更好，比厚客戶端方法更容易管理。
增強可重用性和可擴充套件性 - 隨著需求增加，可以新增額外的伺服器。
提供多執行緒支援並減少網路流量。
提供可維護性和靈活性。
缺點
由於缺乏測試工具，可測試性不令人滿意。
伺服器可靠性和可用性更為關鍵。
代理架構風格
代理架構風格是一種在分散式計算中使用的中介軟體架構，用於協調和啟用已註冊伺服器和客戶端之間的通訊。在此，物件通訊透過稱為物件請求代理（軟體匯流排）的中介軟體系統進行。
客戶端和伺服器不會直接相互互動。客戶端和伺服器與其代理具有直接連線，該代理與中介代理通訊。
伺服器透過向代理註冊和釋出其介面來提供服務，客戶端可以透過查詢靜態地或動態地向代理請求服務。
CORBA（公共物件請求代理體系結構）是代理架構的一個很好的實現示例。
代理架構風格的元件
透過以下標題討論代理架構風格的元件：
代理
代理負責協調通訊，例如轉發和排程結果和異常。它可以是面向呼叫的服務、面向文件或訊息的代理，客戶端向其傳送訊息。
它負責代理服務請求，查詢合適的伺服器，傳輸請求並將響應傳送回客戶端。
它保留伺服器的註冊資訊，包括其功能和服務以及位置資訊。
它為客戶端提供請求API，為伺服器提供響應API，註冊或登出伺服器元件，傳輸訊息和查詢伺服器。
存根
存根在靜態編譯時生成，然後部署到客戶端，用作客戶端的代理。客戶端代理充當客戶端和代理之間的中介，並在它們和客戶端之間提供額外的透明性；遠端物件看起來像本地物件。
代理隱藏協議級別的IPC（程序間通訊），並執行引數值的編組和從伺服器取消編組的結果。
骨架
骨架由服務介面編譯生成，然後部署到伺服器端，用作伺服器的代理。伺服器端代理封裝低階特定於系統的網路功能，並提供高階API來協調伺服器和代理之間的關係。
它接收請求，解包請求，解組方法引數，呼叫合適的服務，並在將結果傳送回客戶端之前編組結果。
橋接器（橋）
橋接器可以基於不同的通訊協議連線兩個不同的網路。它協調不同的代理，包括DCOM、.NET遠端和Java CORBA代理。
橋接器是可選元件，當兩個代理互操作時，它隱藏實現細節，並以一種格式接收請求和引數，並將它們轉換為另一種格式。
CORBA中的代理實現
CORBA是物件請求代理（ORB）的國際標準——一種中介軟體，用於管理由OMG（物件管理組）定義的分散式物件之間的通訊。
面向服務的架構 (SOA)
服務是業務功能的一個元件，它定義明確、獨立、自包含、已釋出且可透過標準程式設計介面使用。服務之間的連線透過常見的通用面向訊息的協議（例如SOAP Web服務協議）進行，該協議可以在服務之間鬆散地傳遞請求和響應。
面向服務的架構是一種客戶端/伺服器設計，它支援業務驅動的IT方法，其中應用程式由軟體服務和軟體服務使用者（也稱為客戶端或服務請求者）組成。
SOA 的特點
面向服務的架構提供以下特性：
分散式部署 - 將企業資料和業務邏輯作為鬆散耦合的、可發現的、結構化的、基於標準的、粗粒度的、無狀態的功能單元（稱為服務）公開。
可組合性 - 從以所需粒度透過定義明確、已釋出且符合標準的介面公開的現有服務中組裝新的流程。
互操作性 - 無論底層協議或實現技術如何，都能跨網路共享功能和重用共享服務。
可重用性 - 選擇服務提供商並訪問公開為服務的現有資源。
SOA 操作
下圖說明了SOA是如何工作的：
優點
服務導向的鬆散耦合為企業提供了極大的靈活性，可以利用所有可用的服務資源，而無需考慮平臺和技術限制。
由於無狀態服務特性，每個服務元件都獨立於其他服務。
只要公開的介面不變，服務的實現就不會影響服務的應用。
客戶端或任何服務都可以訪問其他服務，而不管其平臺、技術、供應商或語言實現如何。
資產和服務的可重用性，因為服務的客戶端只需要知道其公共介面，服務組合。
基於SOA的業務應用程式開發在時間和成本方面效率更高。
增強可擴充套件性並提供系統之間的標準連線。
高效有效地使用“業務服務”。
整合變得更容易，並且內在互操作性得到改善。
為開發人員抽象複雜性，並將業務流程更貼近終端使用者。