1，背景 隨著互聯(lián)網(wǎng)的發(fā)展，網(wǎng)站應(yīng)用的規(guī)模不斷擴(kuò)大，常規(guī)的垂直應(yīng)用架構(gòu)已無法應(yīng)對，分布式服務(wù)架構(gòu)以及流動計(jì)算架構(gòu)勢在必行，亟需一個治理系統(tǒng)確保架構(gòu)有條不紊的演進(jìn)

• 單一應(yīng)用架構(gòu)

• 當(dāng)網(wǎng)站流量很小時，只需一個應(yīng)用，將所有功能都部署在一起，以減少部署節(jié)點(diǎn)和成本
• 此時，用于簡化增刪改查工作量的?數(shù)據(jù)訪問框架(ORM)?是關(guān)鍵

• 垂直應(yīng)用架構(gòu)

• 當(dāng)訪問量逐漸增大，單一應(yīng)用增加機(jī)器帶來的加速度越來越小，將應(yīng)用拆成互不相干的幾個應(yīng)用，以提升效率
• 此時，用于加速前端頁面開發(fā)的?Web框架(MVC)?是關(guān)鍵

• 分布式服務(wù)架構(gòu)

• 當(dāng)垂直應(yīng)用越來越多，應(yīng)用之間交互不可避免，將核心業(yè)務(wù)抽取出來，作為獨(dú)立的服務(wù)，逐漸形成穩(wěn)定的服務(wù)中心，使前端應(yīng)用能更快速的響應(yīng)多變的市場需求
• 此時，用于提高業(yè)務(wù)復(fù)用及整合的?分布式服務(wù)框架(RPC)?是關(guān)鍵
• 分布式服務(wù)RPC框架

• 按業(yè)務(wù)線拆分

• 部署分離

• 每次發(fā)布只部署部分服務(wù)器
• 每個節(jié)點(diǎn)可根據(jù)不同需求伸縮擴(kuò)展
• 每個應(yīng)用之間更新，部署，運(yùn)行不影響

• • 團(tuán)隊(duì)分離
  • 數(shù)據(jù)分離

• • 停止RPC濫用，垂直業(yè)務(wù)內(nèi)優(yōu)先通過本地jar調(diào)用，跨業(yè)務(wù)才采用RPC調(diào)用
  • 正確的識別業(yè)務(wù)邏輯的歸屬，讓各個模塊最大化內(nèi)聚，從性能，可用性和維護(hù)性上減少耦合

• 流動計(jì)算架構(gòu)

• 當(dāng)服務(wù)越來越多，容量的評估，小服務(wù)資源的浪費(fèi)等問題逐漸顯現(xiàn)，此時需增加一個調(diào)度中心基于訪問壓力實(shí)時管理集群容量，提高集群利用率
• 此時，用于提高機(jī)器利用率的資源調(diào)度和治理中心(SOA)是關(guān)鍵

2，需求 在大規(guī)模服務(wù)化之前，應(yīng)用可能只是通過RMI或Hessian等工具，簡單的暴露和引用遠(yuǎn)程服務(wù)，通過配置服務(wù)的URL地址進(jìn)行調(diào)用，通過F5等硬件進(jìn)行負(fù)載均衡

• 當(dāng)服務(wù)越來越多時，服務(wù)URL配置管理變得非常困難，F5硬件負(fù)載均衡器的單點(diǎn)壓力也越來越大

• 此時需要一個服務(wù)注冊中心，動態(tài)的注冊和發(fā)現(xiàn)服務(wù)，使服務(wù)的位置透明
• 并通過在消費(fèi)方獲取服務(wù)提供方地址列表，實(shí)現(xiàn)軟負(fù)載均衡和Failover，降低對F5硬件負(fù)載均衡器的依賴，也能減少部分成本

• 當(dāng)進(jìn)一步發(fā)展，服務(wù)間依賴關(guān)系變得錯蹤復(fù)雜，甚至分不清哪個應(yīng)用要在哪個應(yīng)用之前啟動，架構(gòu)師都不能完整的描述應(yīng)用的架構(gòu)關(guān)系

• 這時，需要自動畫出應(yīng)用間的依賴關(guān)系圖，以幫助架構(gòu)師理清理關(guān)系

• 接著，服務(wù)的調(diào)用量越來越大，服務(wù)的容量問題就暴露出來，這個服務(wù)需要多少機(jī)器支撐？什么時候該加機(jī)器？

• 為了解決這些問題，第一步，要將服務(wù)現(xiàn)在每天的調(diào)用量，響應(yīng)時間，都統(tǒng)計(jì)出來，作為容量規(guī)劃的參考指標(biāo)
• 其次，要可以動態(tài)調(diào)整權(quán)重，在線上，將某臺機(jī)器的權(quán)重一直加大，并在加大的過程中記錄響應(yīng)時間的變化，直到響應(yīng)時間到達(dá)閥值，記錄此時的訪問量，再以此訪問量乘以機(jī)器數(shù)反推總?cè)萘?/li>

3，Dubbo架構(gòu)

• Dubbo分層

• 層次結(jié)構(gòu)

• Business

• Service

• • RPC

• Config
• Proxy
• Registry
• Cluster
• Monitor
• Protocol

• • Remoting

• Exchange
• Transport
• Serialize

• • 層說明

• config（配置層 ）

• 對外配置接口
• 以ServiceConfig,?ReferenceConfig為中心，可以直接new配置類，也可以通過spring解析配置生成配置類

• • proxy（服務(wù)代理層）

• 服務(wù)接口透明代理，生成服務(wù)的客戶端Stub和服務(wù)器端Skeleton
• 以ServiceProxy為中心，擴(kuò)展接口為ProxyFactory
• 選擇

• Javassist?ProxyFactory
• Jdk?ProxyFactory

• • registry（ 注冊中心層）

• 封裝服務(wù)地址的注冊與發(fā)現(xiàn)
• 以服務(wù)URL為中心，擴(kuò)展接口為RegistryFactory,?Registry,?RegistryService
• 選擇

• Zookeeper

• 支持基于網(wǎng)絡(luò)的集群方式，有廣泛周邊開源產(chǎn)品，建議使用dubbo-2.3.3以上版本（推薦使用）
• 依賴于Zookeeper的穩(wěn)定性

• • Redis

• 支持基于客戶端雙寫的集群方式，性能高
• 要求服務(wù)器時間同步，用于檢查心跳過期臟數(shù)據(jù)

• • Multicast

• 去中心化，不需要安裝注冊中心
• 依賴于網(wǎng)絡(luò)拓普和路由，跨機(jī)房有風(fēng)險(xiǎn)

• • Simple

• Dogfooding，注冊中心本身也是一個標(biāo)準(zhǔn)的RPC服務(wù)
• 沒有集群支持，可能單點(diǎn)故障

• • cluster（ 路由層）

• 封裝多個提供者的路由及負(fù)載均衡，并橋接注冊中心
• 以Invoker為中心，擴(kuò)展接口為Cluster,?Directory,?Router,?LoadBalance
• Cluster選擇

• Failover

• 失敗自動切換，當(dāng)出現(xiàn)失敗，重試其它服務(wù)器，通常用于讀操作（推薦使用）
• 重試會帶來更長延遲

• • Failfast

• 快速失敗，只發(fā)起一次調(diào)用，失敗立即報(bào)錯,通常用于非冪等性的寫操作
• 如果有機(jī)器正在重啟，可能會出現(xiàn)調(diào)用失敗

• • Failsafe

• 失敗安全，出現(xiàn)異常時，直接忽略，通常用于寫入審計(jì)日志等操作
• 調(diào)用信息丟失

• • Failback

• 失敗自動恢復(fù)，后臺記錄失敗請求，定時重發(fā)，通常用于消息通知操作
• 不可靠，重啟丟失

• • Forking

• 并行調(diào)用多個服務(wù)器，只要一個成功即返回，通常用于實(shí)時性要求較高的讀操作
• 需要浪費(fèi)更多服務(wù)資源

• • Broadcast

• 廣播調(diào)用所有提供者，逐個調(diào)用，任意一臺報(bào)錯則報(bào)錯，通常用于更新提供方本地狀態(tài)
• 速度慢，任意一臺報(bào)錯則報(bào)錯

• • Router選擇

• Random

• 隨機(jī)，按權(quán)重設(shè)置隨機(jī)概率（推薦使用）
• 在一個截面上碰撞的概率高，重試時，可能出現(xiàn)瞬間壓力不均

• • RoundRobin

• 輪循，按公約后的權(quán)重設(shè)置輪循比率
• 存在慢的機(jī)器累積請求問題，極端情況可能產(chǎn)生雪崩

• • LeastActive

• 最少活躍調(diào)用數(shù)，相同活躍數(shù)的隨機(jī)，活躍數(shù)指調(diào)用前后計(jì)數(shù)差，使慢的機(jī)器收到更少請求
• 不支持權(quán)重，在容量規(guī)劃時，不能通過權(quán)重把壓力導(dǎo)向一臺機(jī)器壓測容量

• • ConsistentHash

• 一致性Hash，相同參數(shù)的請求總是發(fā)到同一提供者，當(dāng)某一臺提供者掛時，原本發(fā)往該提供者的請求，基于虛擬節(jié)點(diǎn)，平攤到其它提供者，不會引起劇烈變動
• 壓力分?jǐn)偛痪?/li>

• • 路由規(guī)則

• 條件路由

• 基于條件表達(dá)式的路由規(guī)則，功能簡單易用
• 有些復(fù)雜多分支條件情況，規(guī)則很難描述

• • 腳本路由

• 基于腳本引擎的路由規(guī)則，功能強(qiáng)大
• 沒有運(yùn)行沙箱，腳本能力過于強(qiáng)大，可能成為后門

• • 容器

• Spring

• 自動加載META-INF/spring目錄下的所有Spring配置

• • Jetty

• 啟動一個內(nèi)嵌Jetty，用于匯報(bào)狀態(tài)
• 大量訪問頁面時，會影響服務(wù)器的線程和內(nèi)存

• • Log4j

• 自動配置log4j的配置，在多進(jìn)程啟動時，自動給日志文件按進(jìn)程分目錄
• 用戶不能控制log4j的配置，不靈活

• • monitor（ 監(jiān)控層）

• RPC調(diào)用次數(shù)和調(diào)用時間監(jiān)控
• 以Statistics為中心，擴(kuò)展接口為MonitorFactory,?Monitor,?MonitorService

• • protocol（ 遠(yuǎn)程調(diào)用層）

• 封裝RPC調(diào)用
• 以Invocation,?Result為中心，擴(kuò)展接口為Protocol,?Invoker,?Exporter
• 選擇

• Dubbo協(xié)議

• 采用NIO復(fù)用單一長連接，并使用線程池并發(fā)處理請求，減少握手和加大并發(fā)效率，性能較好（推薦使用）
• 適合于小數(shù)據(jù)量大并發(fā)的服務(wù)調(diào)用，以及服務(wù)消費(fèi)者機(jī)器數(shù)遠(yuǎn)大于服務(wù)提供者機(jī)器數(shù)的情況
• Dubbo缺省協(xié)議不適合傳送大數(shù)據(jù)量的服務(wù)，比如傳文件，傳視頻等，除非請求量很低
• Dubbo協(xié)議缺省每服務(wù)每提供者每消費(fèi)者使用單一長連接，如果數(shù)據(jù)量較大，可以使用多個連接
• 為防止被大量連接撐掛，可在服務(wù)提供方限制大接收連接數(shù)，以實(shí)現(xiàn)服務(wù)提供方自我保護(hù)
• 在大文件傳輸時，單一連接會成為瓶頸
• 總結(jié)

• 連接個數(shù)：單連接
• 連接方式：長連接
• 傳輸協(xié)議：TCP
• 傳輸方式：NIO異步傳輸
• 序列化：Hessian二進(jìn)制序列化
• 適用范圍：傳入傳出參數(shù)數(shù)據(jù)包較小（建議小于100K），消費(fèi)者比提供者個數(shù)多，單一消費(fèi)者無法壓滿提供者，盡量不要用dubbo協(xié)議傳輸大文件或超大字符串。
• 適用場景：常規(guī)遠(yuǎn)程服務(wù)方法調(diào)用

• • Rmi協(xié)議

• 可與原生RMI互操作，基于TCP協(xié)議
• 偶爾會連接失敗，需重建Stub

• • Hessian協(xié)議

• 可與原生Hessian互操作，基于HTTP協(xié)議
• 需hessian.jar支持，http短連接的開銷大
• Hessian協(xié)議用于集成Hessian的服務(wù)，Hessian底層采用Http通訊，采用Servlet暴露服務(wù)，Dubbo缺省內(nèi)嵌Jetty作為服務(wù)器實(shí)現(xiàn)
• 可以和原生Hessian服務(wù)互操作

• 提供者用Dubbo的Hessian協(xié)議暴露服務(wù)，消費(fèi)者直接用標(biāo)準(zhǔn)Hessian接口調(diào)用
• 或者提供方用標(biāo)準(zhǔn)Hessian暴露服務(wù)，消費(fèi)方用Dubbo的Hessian協(xié)議調(diào)用
• 基于Hessian的遠(yuǎn)程調(diào)用協(xié)議

• • 總結(jié)

• 連接個數(shù)：多連接
• 連接方式：短連接
• 傳輸協(xié)議：HTTP
• 傳輸方式：同步傳輸
• 序列化：Hessian二進(jìn)制序列化
• 適用范圍：傳入傳出參數(shù)數(shù)據(jù)包較大，提供者比消費(fèi)者個數(shù)多，提供者壓力較大，可傳文件
• 適用場景：頁面?zhèn)鬏?#xff0c;文件傳輸，或與原生hessian服務(wù)互操作

• • 約束

• 參數(shù)及返回值需實(shí)現(xiàn)Serializable接口
• 參數(shù)及返回值不能自定義實(shí)現(xiàn)List, Map, Number, Date, Calendar等接口，只能用JDK自帶的實(shí)現(xiàn)，因?yàn)閔essian會做特殊處理，自定義實(shí)現(xiàn)類中的屬性值都會丟失

• • exchange（ 信息交換層）

• 封裝請求響應(yīng)模式，同步轉(zhuǎn)異步
• 以Request, Response為中心，擴(kuò)展接口為Exchanger,?ExchangeChannel,?ExchangeClient,?ExchangeServer

• • transport（ 網(wǎng)絡(luò)傳輸層）

• 抽象mina和netty為統(tǒng)一接口
• 以Message為中心，擴(kuò)展接口為Channel,?Transporter,?Client,?Server,?Codec
• 選擇

• Netty

• 性能較好（推薦使用）
• 一次請求派發(fā)兩種事件，需屏蔽無用事件

• • Mina

• 老牌NIO框架，穩(wěn)定
• 待發(fā)送消息隊(duì)列派發(fā)不及時，大壓力下，會出現(xiàn)FullGC

• • Grizzly

• Sun的NIO框架，應(yīng)用于GlassFish服務(wù)器中
• 線程池不可擴(kuò)展，Filter不能攔截下一Filter

• • serialize（ 數(shù)據(jù)序列化層）

• 可復(fù)用的一些工具
• 擴(kuò)展接口為Serialization,?ObjectInput,?ObjectOutput,?ThreadPool
• 選擇

• Hessian

• 性能較好，多語言支持（推薦使用）
• Hessian的各版本兼容性不好，可能和應(yīng)用使用的Hessian沖突，Dubbo內(nèi)嵌了hessian3.2.1的源碼

• • Dubbo

• 通過不傳送POJO的類元信息，在大量POJO傳輸時，性能較好
• 當(dāng)參數(shù)對象增加字段時，需外部文件聲明

• • Json

• 純文本，可跨語言解析，缺省采用FastJson解析
• 性能較差

• • Java

• Java原生支持
• 性能較差

• • 關(guān)系說明

• 在RPC中，Protocol是核心層，也就是只要有Protocol + Invoker + Exporter就可以完成非透明的RPC調(diào)用，然后在Invoker的主過程上Filter攔截點(diǎn)。
• 圖中的Consumer和Provider是抽象概念，只是想讓看圖者更直觀的了解哪些類分屬于客戶端與服務(wù)器端，不用Client和Server的原因是Dubbo在很多場景下都使用Provider, Consumer, Registry, Monitor劃分邏輯拓普節(jié)點(diǎn)，保持統(tǒng)一概念。
• 而Cluster是外圍概念，所以Cluster的目的是將多個Invoker偽裝成一個Invoker，這樣其它人只要關(guān)注Protocol層Invoker即可，加上Cluster或者去掉Cluster對其它層都不會造成影響，因?yàn)橹挥幸粋€提供者時，是不需要Cluster的。
• Proxy層封裝了所有接口的透明化代理，而在其它層都以Invoker為中心，只有到了暴露給用戶使用時，才用Proxy將Invoker轉(zhuǎn)成接口，或?qū)⒔涌趯?shí)現(xiàn)轉(zhuǎn)成Invoker，也就是去掉Proxy層RPC是可以Run的，只是不那么透明，不那么看起來像調(diào)本地服務(wù)一樣調(diào)遠(yuǎn)程服務(wù)。
• 而Remoting實(shí)現(xiàn)是Dubbo協(xié)議的實(shí)現(xiàn)，如果你選擇RMI協(xié)議，整個Remoting都不會用上，Remoting內(nèi)部再劃為Transport傳輸層和Exchange信息交換層，Transport層只負(fù)責(zé)單向消息傳輸，是對Mina,Netty,Grizzly的抽象，它也可以擴(kuò)展UDP傳輸，而Exchange層是在傳輸層之上封裝了Request-Response語義。
• Registry和Monitor實(shí)際上不算一層，而是一個獨(dú)立的節(jié)點(diǎn)，只是為了全局概覽，用層的方式畫在一起

• Dubbo模塊分包

• 模塊

• dubbo-common 公共邏輯模塊，包括Util類和通用模型。
• dubbo-remoting 遠(yuǎn)程通訊模塊，相當(dāng)于Dubbo協(xié)議的實(shí)現(xiàn)，如果RPC用RMI協(xié)議則不需要使用此包。
• dubbo-rpc 遠(yuǎn)程調(diào)用模塊，抽象各種協(xié)議，以及動態(tài)代理，只包含一對一的調(diào)用，不關(guān)心集群的管理。
• dubbo-cluster 集群模塊，將多個服務(wù)提供方偽裝為一個提供方，包括：負(fù)載均衡,?容錯，路由等，集群的地址列表可以是靜態(tài)配置的，也可以是由注冊中心下發(fā)。
• dubbo-registry 注冊中心模塊，基于注冊中心下發(fā)地址的集群方式，以及對各種注冊中心的抽象。
• dubbo-monitor 監(jiān)控模塊，統(tǒng)計(jì)服務(wù)調(diào)用次數(shù)，調(diào)用時間的，調(diào)用鏈跟蹤的服務(wù)。
• dubbo-config 配置模塊，是Dubbo對外的API，用戶通過Config使用Dubbo，隱藏Dubbo所有細(xì)節(jié)。
• dubbo-container 容器模塊，是一個Standlone的容器，以簡單的Main加載Spring啟動，因?yàn)榉?wù)通常不需要Tomcat/JBoss等Web容器的特性，沒必要用Web容器去加載服務(wù)

• • 與分層的不同點(diǎn)在于

• container為服務(wù)容器，用于部署運(yùn)行服務(wù)，沒有在層中畫出。
• protocol層和proxy層都放在rpc模塊中，這兩層是rpc的核心，在不需要集群時(只有一個提供者)，可以只使用這兩層完成rpc調(diào)用。
• transport層和exchange層都放在remoting模塊中，為rpc調(diào)用的通訊基礎(chǔ)。
• serialize層放在common模塊中，以便更大程度復(fù)用

• 模型

• Protocol是服務(wù)域，它是Invoker暴露和引用的主功能入口，它負(fù)責(zé)Invoker的生命周期管理
• Invoker是實(shí)體域，它是Dubbo的核心模型，其它模型都向它靠擾，或轉(zhuǎn)換成它，它代表一個可執(zhí)行體，可向它發(fā)起invoke調(diào)用，它有可能是一個本地的實(shí)現(xiàn)，也可能是一個遠(yuǎn)程的實(shí)現(xiàn)，也可能一個集群實(shí)現(xiàn)
• Invocation是會話域，它持有調(diào)用過程中的變量，比如方法名，參數(shù)等

• 基本原則

• 采用Microkernel + Plugin模式，Microkernel只負(fù)責(zé)組將Plugin，Dubbo自身的功能也是通過擴(kuò)展點(diǎn)實(shí)現(xiàn)的，也就是Dubbo的所有功能點(diǎn)都可被用戶自定義擴(kuò)展所替換
• 采用URL作為配置信息的統(tǒng)一格式，所有擴(kuò)展點(diǎn)都通過傳遞URL攜帶配置信息

• 擴(kuò)展點(diǎn)加載

• Dubbo的擴(kuò)展點(diǎn)加載從JDK標(biāo)準(zhǔn)的SPI(Service Provider Interface)擴(kuò)展點(diǎn)發(fā)現(xiàn)機(jī)制加強(qiáng)而來
• 在擴(kuò)展類的jar包內(nèi)，放置擴(kuò)展點(diǎn)配置文件：META-INF/dubbo/接口全限定名，內(nèi)容為：配置名=擴(kuò)展實(shí)現(xiàn)類全限定名，多個實(shí)現(xiàn)類用換行符分隔
• 注意：這里的配置文件是放在你自己的jar包內(nèi)，不是dubbo本身的jar包內(nèi)，Dubbo會全ClassPath掃描所有jar包內(nèi)同名的這個文件，然后進(jìn)行合并

• Provider暴露服務(wù)的過程

• 具體服務(wù)到Invoker的轉(zhuǎn)換

• ServiceConfig：ref對外提供服務(wù)實(shí)際類
• ProxyFactory：getInvoker()

• JavassistProxyFactory
• JdkProxyFactory

• • Invoker轉(zhuǎn)換為Exporter

• Invoker：AbstractProxyInvoker的實(shí)例
• Protocal：export()

• DubboProtocol

• Dubbo協(xié)議的Invoker轉(zhuǎn)為Exporter發(fā)生在DubboProtocol類的export方法，它主要是打開socket偵聽服務(wù)，并接收客戶端發(fā)來的各種請求，通訊細(xì)節(jié)由Dubbo自己實(shí)現(xiàn)

• • HessianProtocol
  • InjvmProtocol

• 它通過Spring或Dubbo或JDK來實(shí)現(xiàn)RMI服務(wù)，通訊細(xì)節(jié)這一塊由JDK底層來實(shí)現(xiàn)，這就省了不少工作量

• • RmiProtocol
  • WebServiceProtocol

• • Export

• Consumer消費(fèi)服務(wù)的過程

• 把遠(yuǎn)端服務(wù)轉(zhuǎn)為Invoker

• ReferenceConfig
• Protocol：refer()

• DubboProtocol
• HessianProtocol
• InjvmProtocol
• RmiProtocol
• WebServiceProtocol

• • 把Invoker轉(zhuǎn)為客戶端需要的接口

• Invoker

• DubboInvoker
• HessianInvoker
• InjvmInvoker
• RmiInvoker
• WebServiceInvoker

• • ProxyFactory：getProxy()

• JavassistProxyFactory
• JdkProxyFactory

• • ref
  • 過程：首先ReferenceConfig類的init方法調(diào)用Protocol的refer方法生成Invoker實(shí)例(如上圖中的紅色部分)，這是服務(wù)消費(fèi)的關(guān)鍵。接下來把Invoker轉(zhuǎn)換為客戶端需要的接口

• 無處不在的Invoker

• 由于Invoker是Dubbo領(lǐng)域模型中非常重要的一個概念，很多設(shè)計(jì)思路都是向它靠攏
• 服務(wù)消費(fèi)者Invoker

• 用戶代碼通過這個proxy調(diào)用其對應(yīng)的Invoker(DubboInvoker、 HessianRpcInvoker、 InjvmInvoker、 RmiInvoker、 WebServiceInvoker中的任何一個)，而該Invoker實(shí)現(xiàn)了真正的遠(yuǎn)程服務(wù)調(diào)用

• • 服務(wù)提供者Invoker

• 被封裝成為一個AbstractProxyInvoker實(shí)例，并新生成一個Exporter實(shí)例。這樣當(dāng)網(wǎng)絡(luò)通訊層收到一個請求后，會找到對應(yīng)的Exporter實(shí)例，并調(diào)用它所對應(yīng)的AbstractProxyInvoker實(shí)例，從而真正調(diào)用了服務(wù)提供者的代碼

• 線程模型

• 過程

• Proxy
• Client

• Transporter

• Header ->?Codec
• Body ->?Serialization

• • Server
  • Dispatcher
  • ThreadPool
  • Implementation

• • Dispatcher

• all?所有消息都派發(fā)到線程池，包括請求，響應(yīng)，連接事件，斷開事件，心跳等
• direct?所有消息都不派發(fā)到線程池，全部在IO線程上直接執(zhí)行
• message?只有請求響應(yīng)消息派發(fā)到線程池，其它連接斷開事件，心跳等消息，直接在IO線程上執(zhí)行
• execution?只請求消息派發(fā)到線程池，不含響應(yīng)，響應(yīng)和其它連接斷開事件，心跳等消息，直接在IO線程上執(zhí)行
• connection?在IO線程上，將連接斷開事件放入隊(duì)列，有序逐個執(zhí)行，其它消息派發(fā)到線程池

• • ThreadPool

• fixed?固定大小線程池，啟動時建立線程，不關(guān)閉，一直持有。(缺省)
• cached?緩存線程池，空閑一分鐘自動刪除，需要時重建
• limited?可伸縮線程池，但池中的線程數(shù)只會增長不會收縮。(為避免收縮時突然來了大流量引起的性能問題)

4，增強(qiáng)功能

• 并發(fā)控制
• 連接控制： 連接數(shù)控制
• 分組聚合： 分組聚合返回值，用于菜單聚合等服務(wù)
• 泛化引用： 泛化調(diào)用，無需業(yè)務(wù)接口類進(jìn)行遠(yuǎn)程調(diào)用，用于測試平臺，開放網(wǎng)關(guān)橋接等
• 異步調(diào)用
• 延遲暴露： 延遲暴露服務(wù)，用于等待應(yīng)用加載warmup數(shù)據(jù)，或等待spring加載完成
• 延遲連接： 延遲建立連接，調(diào)用時建立
• 隱私傳參： 附加參數(shù)

5，Dubbo擴(kuò)展

• 方法

• OSGI

• Equinox
• Eclipse, HSF
• META-INF/MANIFEST.MF

• • IoC

• Spring
• META-INF/spring/beans.xml

• • SPI

• java.util.ServiceProvider
• JDBC, MessageDigest, ScriptEngine
• META-INF/services/com.xx.Xxx

• Dubbo SPI

• Microkernel & SPI
• Protocol & ProxyFactory & Filter
• Cluster & Directory & Router & LoadBalance
• Transporter & Serialization & ThreadPool
• TelnetHandler & StatusChecker

6，Dubbo設(shè)計(jì)原則

• 模塊分包原則

• 復(fù)用度

• 包中的類應(yīng)該有同樣的重用可能性
• 緊密協(xié)作的類應(yīng)該放在一個包
• 對于變化因子，包中的類應(yīng)全改或全不改
• 變化應(yīng)在包內(nèi)終止，而不傳播到其它包
• 發(fā)布的粒度和復(fù)用度相同

• • 穩(wěn)定度

• 被依賴的包應(yīng)該總是比依賴者更穩(wěn)定
• 不要讓一個穩(wěn)定的包依賴于不穩(wěn)定包
• 單向依賴，無環(huán)依賴

• • 抽象度

• 越穩(wěn)定的包應(yīng)該越抽象
• 穩(wěn)定的包不抽象將導(dǎo)致擴(kuò)展性極差
• 抽象的包不穩(wěn)定將導(dǎo)致其依賴包跟隨變化

• 框架擴(kuò)展原則

• 微核 +插件體系

• OSGI
• IoC
• SPI

• • 平等對待第三方?

• Dogfooding

• 框架自己的功能也要擴(kuò)展點(diǎn)實(shí)現(xiàn)
• 甚至微核的加載方式也可以擴(kuò)展

• • Autowire

• 裝配邏輯由擴(kuò)展點(diǎn)之間互助完成
• 杜絕硬編碼的橋接和中間代碼

• • Cascading

• 層疊擴(kuò)展粒度，逐級細(xì)分
• 由大的擴(kuò)展點(diǎn)加載小的擴(kuò)展點(diǎn)

• • Law of Demeter

• 只與觸手可及的擴(kuò)展點(diǎn)交互，間接轉(zhuǎn)發(fā)
• 保持行為單一，輸入輸出明確

• • 外置生命周期

• API傳入?yún)?shù)，SPI擴(kuò)展點(diǎn)實(shí)例
• 盡量引用外部對象的實(shí)例，而不類元

• 正確：userInstance.xxx()
• 錯誤：Class.forName(userClass).newInstance().xxx()

• • 盡量使用IoC注入，減少靜態(tài)工廠方法調(diào)用

• 正確：setXxx(xxx)
• 錯誤：XxxFactory.getXxx();?applicationContext.getBean(“xxx”)

• • 最少化概念模型
  • 一致性數(shù)據(jù)模型

• Dubbo統(tǒng)一URL模型

• 所有配置信息都轉(zhuǎn)換成URL的參數(shù)
• 所有的元信息傳輸都采用URL
• 所有接口都可以獲取到URL

• 領(lǐng)域劃分原則

• 服務(wù)域

• 指產(chǎn)品主要功能入口，同時負(fù)責(zé)實(shí)體域和會話域的生命周期管理。
• Velocity的Engine
• Spring的BeanFactory

• • 實(shí)體域

• 表示你要操作的對象模型，不管什么產(chǎn)品，總有一個核心概念，大家都繞圍它轉(zhuǎn)。
• Velocity的Template
• Spring的Bean

• • 會話域

• 表示每次操作瞬時狀態(tài)，操作前創(chuàng)建，操作后銷毀。
• Velocity的Context
• Spring的Invocation

• • 領(lǐng)域模型劃分優(yōu)勢

• 結(jié)構(gòu)清晰，可直接套用
• 充血模型，實(shí)體域帶行為
• 可變與不可變狀態(tài)分離，可變狀態(tài)集中
• 所有領(lǐng)域線程安全，不需要加鎖

• • 領(lǐng)域模型線程安全性

• 服務(wù)域

• 通常服務(wù)域是無狀態(tài)，或者只有啟動時初始化不變狀態(tài)，所以天生線程安全，只需單一實(shí)例運(yùn)行

• • 實(shí)體域

• 通常設(shè)計(jì)為不變類，所有屬性只讀，或整個類引用替換，所以是線程安全的

• • 會話域

• 保持所有可變狀態(tài)，且會話域只在線程棧內(nèi)使用，即每次調(diào)用都在線程棧內(nèi)創(chuàng)建實(shí)例，調(diào)用完即銷毀，沒有競爭，所以線程安全

• 接口分離原則

• API & SPI

• 聲明式API（Dubbo API）：描述需要什么

• ServiceConfig
• ReferenceConfig
• RpcContext

• • 過程式SPI（Dubbo SPI）：描述怎么實(shí)現(xiàn)

• Protocol
• Transporter
• LoadBalance

• • API可配置，一定可編程

• 配置用于簡化常規(guī)使用
• 編程接口用于框架集成

• • API區(qū)分命令與查詢

• 命令：無返回值表示命令，有副作用
• 查詢：有返回值表示查詢，保持冪等，無副作用

• 組件協(xié)作原則

• 管道 v.s. 派發(fā)

• 管道

• 組合行為
• 主功能以截面實(shí)現(xiàn)
• 比如：Servlet

• • 派發(fā)

• 策略行為
• 主功能以事件實(shí)現(xiàn)
• 比如：?Swing

• • 分布 v.s. 共享

• 分布

• 在行為交互為主的系統(tǒng)是適用
• 狀態(tài)通過行為傳遞

• • 共享

• 在以管理狀態(tài)為主的系統(tǒng)中適用
• 狀態(tài)通過倉庫共享

• • 主過程攔截

• Web框架的請求響應(yīng)流
• ORM框架的SQL執(zhí)行
• Service框架的調(diào)用過程
• 反例：IBatis2在SQL執(zhí)行過程中沒有設(shè)攔截點(diǎn)，導(dǎo)致添加安全或日志攔截，執(zhí)行前修改分頁SQL等，不得不hack源代碼

• • 事件派發(fā)

• 過程

• 執(zhí)行前后
• 觸發(fā)附帶非關(guān)鍵行為

• • 狀態(tài)

• 值的變化
• 觸發(fā)狀態(tài)觀察者行為

• • 關(guān)鍵路徑

• 關(guān)鍵路徑

• 采用攔截鏈分離職責(zé)
• 保持截面功能單一，不易出問題

• • 非關(guān)鍵路徑

• 采用后置事件派發(fā)
• 確保派發(fā)失敗，不影響主過程運(yùn)行

• • 協(xié)作防御

• 可靠性分離

• 可靠操作
• 不可靠操作 (盡量縮小)

• • 狀態(tài)分離

• 無狀態(tài)
• 有狀態(tài) (盡量縮小)
• 不可變類 (盡量final)

• • 狀態(tài)驗(yàn)證

• 盡早失敗
• 前置斷言 + 后置斷言 + 不變式

• • 異常防御，但不忽略異常

• 異常信息給出解決方案
• 日志信息包含環(huán)境信息

• • 降低修改時的誤解性，不埋雷

• 避免基于異常類型的分支流程
• 保持null和empty語義一致

• 功能演進(jìn)原則

• 開閉原則

• 對擴(kuò)展開放
• 對修改關(guān)閉
• 軟件質(zhì)量的下降，來源于修改
• 替換整個實(shí)現(xiàn)類，而不是修改其中的某行

• • 增量式 v.s.擴(kuò)充式

• Dubbo增量式擴(kuò)展

• Remoting

• Transport：

• 單向消息發(fā)送，抽象Mina/Netty

• • Exchange：

• 封裝Request-Respose語義
• 調(diào)用兩次單向消息發(fā)送完成

• • RPC

• Portocol：

• 協(xié)議實(shí)現(xiàn)，不透明，點(diǎn)對點(diǎn)

• • Cluster：

• 將集群中多個提供者偽裝成一個

• • Proxy：

• 透明化接口，橋接動態(tài)代理

• • 在高階附加功能

• 盡可能少的依賴低階契約，用最少的抽象概念實(shí)現(xiàn)功能
• 當(dāng)?shù)碗A切換實(shí)現(xiàn)時，高階功能可以繼續(xù)復(fù)用

7，Dubbo編碼約定

• 異常和日志：

• 盡可能攜帶完整的上下文信息，比如出錯原因，出錯的機(jī)器地址，調(diào)用對方的地址，連的注冊中心地址，使用Dubbo的版本等。
• 盡量將直接原因?qū)懺谧钋懊?#xff0c;所有上下文信息，在原因后用鍵值對顯示。
• 拋出異常的地方不用打印日志，由最終處理異常者決定打印日志的級別，吃掉異常必需打印日志。
• 打印ERROR日志表示需要報(bào)警，打印WARN日志表示可以自動恢復(fù)，打印INFO表示正常信息或完全不影響運(yùn)行。
• 建議應(yīng)用方在監(jiān)控中心配置ERROR日志實(shí)時報(bào)警，WARN日志每周匯總發(fā)送通知。
• RpcException是Dubbo對外的唯一異常類型，所有內(nèi)部異常，如果要拋出給用戶，必須轉(zhuǎn)為RpcException。
• RpcException不能有子類型，所有類型信息用ErrorCode標(biāo)識，以便保持兼容。

• 配置和URL：

• 配置對象屬性首字母小寫，多個單詞用駝峰命名(Java約定)。
• 配置屬性全部用小寫，多個單詞用"-"號分隔(Spring約定)。
• URL參數(shù)全部用小寫，多個單詞用"."號分隔(Dubbo約定)。
• 盡可能用URL傳參，不要自定義Map或其它上下文格式，配置信息也轉(zhuǎn)成URL格式使用。
• 盡量減少URL嵌套，保持URL的簡潔性。

• 單元和集成測試：

• 單元測試統(tǒng)一用JUnit和EasyMock，集成測試用TestNG，數(shù)據(jù)庫測試用DBUnit。
• 保持單元測試用例的運(yùn)行速度，不要將性能和大的集成用例放在單元測試中。
• 保持單元測試的每個用例都用try...finally或tearDown釋放資源。
• 減少while循環(huán)等待結(jié)果的測試用例，對定時器和網(wǎng)絡(luò)的測試，用以將定時器中的邏輯抽為方法測試。
• 對于容錯行為的測試，比如failsafe的測試，統(tǒng)一用LogUtil斷言日志輸出。

• 擴(kuò)展點(diǎn)基類與AOP：

• AOP類都命名為XxxWrapper，基類都命名為AbstractXxx。
• 擴(kuò)展點(diǎn)之間的組合將關(guān)系由AOP完成，ExtensionLoader只負(fù)載加載擴(kuò)展點(diǎn)，包括AOP擴(kuò)展。
• 盡量采用IoC注入擴(kuò)展點(diǎn)之間的依賴，不要直接依賴ExtensionLoader的工廠方法。
• 盡量采用AOP實(shí)現(xiàn)擴(kuò)展點(diǎn)的通用行為，而不要用基類，比如負(fù)載均衡之前的isAvailable檢查，它是獨(dú)立于負(fù)載均衡之外的，不需要檢查的是URL參數(shù)關(guān)閉。
• 對多種相似類型的抽象，用基類實(shí)現(xiàn)，比如RMI,Hessian等第三方協(xié)議都已生成了接口代理，只需將將接口代理轉(zhuǎn)成Invoker即可完成橋接，它們可以用公共基類實(shí)現(xiàn)此邏輯。
• 基類也是SPI的一部分，每個擴(kuò)展點(diǎn)都應(yīng)該有方便使用的基類支持。

• 模塊與分包：

• 基于復(fù)用度分包，總是一起使用的放在同一包下，將接口和基類分成獨(dú)立模塊，大的實(shí)現(xiàn)也使用獨(dú)立模塊。
• 所有接口都放在模塊的根包下，基類放在support子包下，不同實(shí)現(xiàn)用放在以擴(kuò)展點(diǎn)名字命名的子包下。
• 盡量保持子包依賴父包，而不要反向。

8，Dubbo高性能之道

• 參考文章“【總結(jié)】Netty（RPC高性能之道）原理剖析 ”

轉(zhuǎn)載于:https://www.cnblogs.com/yangqiong1989/p/6882470.html

總結(jié)

以上是生活随笔為你收集整理的RPC框架Dubbo分析的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。