【面向服務體系架構】

 

 

 

 

 

什麼是SOA

SOA：面向服務架構（Service Oriented Architecture）

關注點在業務，而不是在對象的變化上

必然性：編程技術的發展

• 開始，基於過程式編程，使用大量函數
• 面向對象編程出現，一切皆爲對象
• 面向組件編程出現，對可重用的對象組合成一個組件
• 面向服務，

也能夠當作是一個愈來愈抽象化的發展

 

功能浪費：多個系統中，各個系統有很多部分是相同或者相似的；SOA能夠經過共用服務，減小這部分的開發

效率低下：由於重複作輪子，因此效率低下

架構複雜：由於各個系統架構都不一樣，增長複雜度

集成困難：不一樣系統是獨立的，要集成的時候很困難

設計複雜：設計的對象不止是一個系統，而是對一對系統的統籌考慮

缺少標準：業界缺乏SOA的規範

自上而下設計（全局推進）：要領導說話，決定，才能這麼作

服務治理：不少服務開發出來，如何管理這些服務

提供了以上這些一些規範和原則

有你們都承認的契約，才能共同合做

服務本身管理本身，不該該和其餘功能耦合

本身能控制本身的運行環境

 

 

 

 

二、Protobuf，一個關於數據序列化，數據傳輸、存儲的一個工具，爲了在SOA中更高效地處理數據；不完整的RPC組件

三、Thrift，一個RPC組件

 

四、Dubbo

Protobuf和Thrift面向跨語言，對Java支持沒有那麼好

DubboRPC框架

出現背景：

RPC，是客戶端能夠動態請求不一樣服務器的服務

SOA，是對服務的管理和治理

RPC，上面2個組件能夠實現；而爲了實現SOA，阿里巴巴開發出了Dubbo

簡介和基礎實例：

 

實現第三層和第四層開發需求

服務註冊器，面向服務提供者，服務消費者

其中有一個包是api，這裏是十分穩定的包，須要給消費者和提供者引用。

而後在消費者和提供者中經過xml配置便可配置好這個關係。

 Dubbo提供了3種協議

 

Dubbo使用3種傳輸方式，推薦Netty

Dubbo提供4種序列化方式

Dubbo提供2種動態代理方式，優先第一種，使用字節碼

Dubbo支持3種容器

 

 

Dubbo基本功能上

經過XML便可構建Dubbo架構，

 

通常建議經過XML集中管理

 

通常在設計上避免這種狀況，例如分開2個接口

 

 

dubbo提供4種註冊中心的實現

 

 

 

 

 dubbo基本功能下

另一種配置方式：在類路徑下添加一個dubbo.properties便可

 

一、服務器角度控制，只有10個請求

二、客戶端角度控制，支持多少活躍客戶端

三、負載均衡，優先級

有3種緩存策略，能夠選用

 

直接經過GenericService，加上方法名，參數發送，暴露

客戶端消費：

通常不會經過API來作

 

 

服務治理：

 

 

Dubbo基本原理

其它暫略

 

 

架構設計原則（上）

總結上面的工具，如何設計這個框架

 分包：如下是主流的方法論

分包中最重要的2塊

內聚：

爲了實現支持插件化，Dubbo從上往下發展，都進行了嘗試

 微內核，Dubbo使用的架構風格

Dubbo的插件，配置都是使用微內核的SPI來實現

 

 架構設計原則（下）

略：

•  2二、 Zookeeper簡介
• 26'30" 2三、 Zookeeper應用
• 35'50" 2四、 服務器推送技術
• 34'38" 2五、 面向服務體系架構總結