分布式係統設計
分布式通信協議
- 基於TCP/IP的通信
- 基於對象的通信協議(RPC,CORBA, RMI)
- 基於Http+xml的通信協議(WebService)
- 基於Http的通信協議(Restful)
基於對象的分布式設計
基於Stub/Skeleton的架構分布式對象協議:
- RPC - Remote Procedure Call
- CORBA - Common Object Request Broker Architecture
- DCE - Distributed Computing Environment
- RMI - Remote Method Invocation
- .NET Remoting - .NET Remoting
- DCOM - Distributed Component Object Model

Reference:
基於web的分布式設計
Web Service
Web service是一個平台獨立的,鬆耦合的,自包含的、基於可編程的web的應用程序,可使用開放的XML標準來描述、發布、發現、協調和配置這些應用程序,用於開發分布式的互操作的應用程序。
- UDDI (Universal Description Discovery Integration)
UDDI 提供以標準方式發布,發現Web Service。 - WSDL(Web Services Description Language)
是一個用來描述Web服務和 說明如何與Web服務通信的XML語言,通過WSDL,可描述Web服務的三個基本屬性。
1. 服務做些什麼 - 服務所提供的操作(方法)
2. 如何訪問服務 - 和服務交互的數據格式以及必要協議
3. 服務位於何處 - 協議相關的地址,如URL - SOAP (Simple Object Access Protocol)
SOAP是分布式的環境中交換信息的簡單的協議,是一個基於XML的協議。
REST
REST stands for Representational State Transfer.
(It is sometimes spelled "ReST".) It relies on a stateless, client-server, cacheable communications protocol
REST設計概念和準則:
1.網絡上的所有事物都被抽象為資源(resource);
2.每個資源對應一個唯一的資源標識(resource identifier)---URL;
3.通過通用的連接器接口(generic connector interface)對資源進行操作 --- HTTP;
4.對資源的各種操作不會改變資源標識;
5.所有的操作都是無狀態的(stateless);
Resouce所指的並不是數據,而是數據+特定的表現形式(representation),這也是為什麼REST的全名是Representational
State Transfer的原因。舉個例子來說,“本月賣得最好的10本書”和“你最喜歡的10本書”在數據上可能有重疊(有一本書即賣得好,你又喜歡),甚至完全相同。但是它們的representation不同,因此是不同的resource。
A real example:
獲取XML的response:https://search.twitter.com/search.atom?q=elkstein&count=5
獲取JSON的response: https://search.twitter.com/search.json?q=elkstein&count=5
優點:
- 開發容易,是輕量級的SOA
- 提高係統的可伸縮性(Scalability),因為無狀態(stateless),服務器的變化對客戶端是透明的。
缺點:
- 與SOAP比較,沒有類型安全的XML based Request/Response
基於消息的分布式設計
優點:
- 通過異步調用,解耦軟件組件,增加係統的可用性和可伸縮性(scalability)
- 將可以再後台處理的邏輯從業務邏輯中剝離,增加係統的響應時間
- 對係統請求進行緩衝,從而可以減輕係統麵對峰值的壓力,因而起到消峰的作用,降低基礎設施的投入成本。
- 是SOA的有力補充,對於不能獨立完成請求的service,可以通過消息異步調用其他組件協同工作。
- 通過消息實現回調(callback)架構
缺點:
- 實現比同步調用複雜
Reference:
https://www.infoq.com/cn/articles/message-based-distributed-architecture
https://www.infoq.com/cn/articles/ebay-scalability-best-practices
https://www.infoq.com/presentations/shoup-ebay-architectural-principles
異構分布式係統的互操作設計
麵向服務的體係結構 SOA (Service-Oriented Architecture)
SOA 是一個組件模型,它將應用程序的不同功能單元(稱為服務)通過這些服務之間定義良好的接口和契約聯係起來。接口是采用中立的方式進行定義的,它應該獨立於
實現服務的硬件平台、操作係統和編程語言。這使得構建在各種這樣的係統中的服務可以一種統一和通用的方式進行交互。
SOA的作用
在一個企業內部,可能存在不同的應用係統,而這些應用係統由於開發時間不同,采用的開發工具不同,一個業務請求很難有效地調用所有的應用係統。這些已有的應用係統是孤立的,也就是我們常說的“信息孤島”, SOA可以實現企業資源共享,打破“信息孤島”。
基於SOA體係結構的軟件開發:https://articles.e-works.net.cn/SOA/Article97034.htm
SOA的主要實現方式 - Web服務(Web Service,REST)
基於麵向對象和基於構件的軟件開發方法同樣遵循複用的概念,但於SOA的複用不同之處是,這種複用是“代碼複用”,而SOA是“功能複用”,隨著係統複雜的提高,不同的功能模塊可能需要用不同的語言編寫,或是運行在不同的係統平台上,此時,“代碼複用”將無能為力。這並不是說麵向對象和基於構建,跟SOA是相衝突的,二者隻能選其一。事實恰恰相反,麵向對象和SOA往往是有機的融合,一個功能模塊,通過SOA來向外部暴露自己所能提供的服務,同時實現這個功能模塊又往往會采用麵向對象和基於構件的軟件開發方法。
SOA設計原則
SOA架構中,繼承了來自對象和組件設計的各種原則,如封裝,自我包含等。那些保證服務的靈活性、鬆耦合和重用能力的設計原則,對SOA架構來說同樣的非常重要
- 無狀態(stateless)。可以提高服務器的可伸縮性。
- 單一功能,避免功能冗餘
- 明確定義的接口。使用者依賴服務規約調用服務,所以服務定義必須長時間穩定,一旦公布,不能隨意更改;服務定義應盡可能明確,減少使用者的不適當使用。
- 自包含和模塊化。服務封裝了那些在業務上穩定、重複出現的活動和組件。實現服務的功能實體是完全獨立自主的,獨立進行部署,版本控製,自我管理和恢複。
- 粗粒度。服務數量不應該太大
- 服務之間的鬆耦合性。服務使用者看到的是服務的接口,其位置,實現技術和當前狀態等對使用者是不可見的。
- 重用能力。服務應該可以被重用
- 互操作性,兼容和策略聲明。
從耦合度看軟件技術的發展
耦合度是模塊之間的聯係程度,模塊間聯係越緊密,耦合度越強,模塊獨立性越差;聯係越少,耦合度越低。簡而言之就是我對你知道的越少,我對你的依賴越少,從而耦合度越低。
若對耦合進行分類,數據耦合的耦合度最低即一個模塊對另一個模塊的訪問時通過簡單的數值參數,內容耦合的耦合度最高。
鬆耦合具有更大的靈活性(Flexibility) ,可擴展性(Extensibility)和複用性(Re-usability),因為調用者和被調用者之間的耦合度低,所以交互雙方均能比較獨立的變化,而對彼此造成的影響很小或不造成影響,不至於動一發而動全身。
在麵向過程的編程中,主程序是通過調用子程序的方法來完成協作的,這種“過程”依賴無疑是耦合度非常高的,因為子過程的任何變化都會引起主程序的變化,而且更換子過程也是一件非常麻煩的事情。轉向麵向對象的編程技術後,利用對象的封裝特性,把數據和不需要被應用的方法通過私有化定義隱藏在類中,從一定程度上減輕了調用者和被調用者之間的耦合度,並且因為對象具有繼承和多態性,利用依賴倒轉技術(麵向接口編程)使得在運行時使用不同語義的方法成為了可能,極大地增加了靈活性和可擴展性。
但是對對象的使用,並不是憑空產生的,首先需要創建一個對象,最原始的方式就是我需要使用一個對象就 new ObjectA(),這是耦合度最高的一種方式,因為對象調用者不僅要知道被調用對象的方法,還要知道被調用對象的創建方式。有沒有一種方式,能將對象創建從對象使用中解耦出來呢?有的,工廠方法,讓工廠去創建對象,調用者無需自己去創建對象了,而是委托工廠去創建,這種解耦的好處是,如果需要替換對象,隻需要更改工廠,而所有引用該對象的代碼都可以保持不變。工廠方法雖然比直接new一個對象好,但是ObjectA作為一個標記,還是要出現在工廠裏,這樣工廠和ObjectA還是緊耦合的,那麼有沒有一種方式讓ObjectA不要出現呢?
有,依賴注入(Dependency Injection),就是在程序中不需要顯示的標明所要依賴對象的名字,而是通過配置文件,以一種注入的方式將所依賴的類提供給類的調用者。
至此,在麵向對象中解耦已經達到一個比較滿意的程度,再進一步的解耦也不會帶來多大的收益,但是對象隻能是在一台JVM中,不能滿足分布式環境的需求,OMG提出了分布式對象請求代理架構(CORBA),在這個遠程調用中,服務的描述(IDL)需要和編程語言進行綁定,例如如果基於JAVA的CORBA實現,這需要一個Java IDL bridge,這也是緊耦合的一種表現。
那麼,能不能使用一種更中立的方式來定義我們分布式應用中的接口呢?是的,Web service使用WSDL來定義自己的服務,而WSDL是用XML語言的,XML是平台獨立、編程語言獨立的文本格式,也就是說一個WS客戶端對WS服務器的依賴僅僅是一份XML文檔而已,並且客戶端和服務器端之間的通信也是采用普遍存在和廣泛支持的HTTP,因此Web Service 是一種耦合度很低的RPC,對WSDL文檔依賴也是一種耦合度的表現。
REST是一種輕量級的基於Web的分布式架構風格,其將HTTP作為一種特殊的應用協議(在WS中,HTTP僅僅是傳輸協議,消息載體是SOAP),利用現有的Web平台和HTTP特性,可以構建出更簡單、可伸縮性更好的Web服務,其客戶端對服務器端的依賴僅僅是一個資源標識(URI ),而內容表述可以是XML、JSON、TXT甚至是圖片、視頻等任意格式,因此REST是比WS耦合度更低的,再次強調,耦合度越低,可擴展性越好,看看今天無比強大和豐富的Web,足以證明REST這種鬆耦合性能夠滿足幾乎所有的應用需求。
最後更新:2017-04-02 15:15:02
上一篇:
MYSQL數據庫備份與恢複
下一篇:
C++設計CTString類
解密亞洲誠信如何做到HTTPS的最佳安全實踐
asp.net關於WEB端用戶重複提交問題。禁用服務器控件按鈕問題。
《Microsoft.NET企業級應用架構設計(第2版)》——1.2 誰是架構師
ASP.NET Core中如影隨形的”依賴注入”[下]: 曆數依賴注入的N種玩法
Android中如何在應用A中啟動或安裝應用B
《迷人的8051單片機》----第2章 神秘的半導體 2.1 二極管
《星際爭霸2》人工智能研究環境 SC2LE 初體驗
學習ASP.NET Core,怎能不了解請求處理管道[1]: 中間件究竟是個什麼東西?
每秒百萬查詢:MySQL與PG在苛刻負載下的和平之戰
jQuery Mobile頁麵跳轉切換的幾種方式