RPC框架Dubbo分析

1，背景

隨着互聯網的發展，網站應用的規模不斷擴大，常規的垂直應用架構已沒法應對，分佈式服務架構以及流動計算架構勢在必行，亟需一個治理系統確保架構有條不紊的演進

• 單一應用架構

• 當網站流量很小時，只需一個應用，將全部功能都部署在一塊兒，以減小部署節點和成本
• 此時，用於簡化增刪改查工做量的 數據訪問框架(ORM) 是關鍵

• 垂直應用架構

• 當訪問量逐漸增大，單一應用增長機器帶來的加速度愈來愈小，將應用拆成互不相干的幾個應用，以提高效率
• 此時，用於加速前端頁面開發的 Web框架(MVC) 是關鍵

• 分佈式服務架構

• 當垂直應用愈來愈多，應用之間交互不可避免，將核心業務抽取出來，做爲獨立的服務，逐漸造成穩定的服務中心，使前端應用能更快速的響應多變的市場需求
• 此時，用於提升業務複用及整合的 分佈式服務框架(RPC) 是關鍵
• 分佈式服務RPC框架

• 按業務線拆分

• 部署分離

• 每次發佈只部署部分服務器
• 每一個節點可根據不一樣需求伸縮擴展
• 每一個應用之間更新，部署，運行不影響

• 團隊分離
• 數據分離

• 中止RPC濫用，垂直業務內優先經過本地jar調用，跨業務才採用RPC調用
• 正確的識別業務邏輯的歸屬，讓各個模塊最大化內聚，從性能，可用性和維護性上減小耦合

• 流動計算架構

• 當服務愈來愈多，容量的評估，小服務資源的浪費等問題逐漸顯現，此時需增長一個調度中心基於訪問壓力實時管理集羣容量，提升集羣利用率
• 此時，用於提升機器利用率的資源調度和治理中心(SOA)是關鍵

2，需求

在大規模服務化以前，應用可能只是經過RMI或Hessian等工具，簡單的暴露和引用遠程服務，經過配置服務的URL地址進行調用，經過F5等硬件進行負載均衡

• 當服務愈來愈多時，服務URL配置管理變得很是困難，F5硬件負載均衡器的單點壓力也愈來愈大

• 此時須要一個服務註冊中心，動態的註冊和發現服務，使服務的位置透明
• 並經過在消費方獲取服務提供方地址列表，實現軟負載均衡和Failover，下降對F5硬件負載均衡器的依賴，也能減小部分紅本

• 當進一步發展，服務間依賴關係變得錯蹤複雜，甚至分不清哪一個應用要在哪一個應用以前啓動，架構師都不能完整的描述應用的架構關係

• 這時，須要自動畫出應用間的依賴關係圖，以幫助架構師理清理關係

• 接着，服務的調用量愈來愈大，服務的容量問題就暴露出來，這個服務須要多少機器支撐？何時該加機器？

• 爲了解決這些問題，第一步，要將服務如今天天的調用量，響應時間，都統計出來，做爲容量規劃的參考指標
• 其次，要能夠動態調整權重，在線上，將某臺機器的權重一直加大，並在加大的過程當中記錄響應時間的變化，直到響應時間到達閥值，記錄此時的訪問量，再以此訪問量乘以機器數反推總容量

3，Dubbo架構

• Dubbo分層

• 層次結構

• Business

• Service

• RPC

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

• Remoting

• Exchange
• Transport
• Serialize

• 層說明

• config（配置層 ）

• 對外配置接口
• 以ServiceConfig, ReferenceConfig爲中心，能夠直接new配置類，也能夠經過spring解析配置生成配置類

• proxy（服務代理層）

• 服務接口透明代理，生成服務的客戶端Stub和服務器端Skeleton
• 以ServiceProxy爲中心，擴展接口爲ProxyFactory
• 選擇

• Javassist ProxyFactory
• Jdk ProxyFactory

• registry（ 註冊中心層）

• 封裝服務地址的註冊與發現
• 以服務URL爲中心，擴展接口爲RegistryFactory, Registry, RegistryService
• 選擇

• Zookeeper

• 支持基於網絡的集羣方式，有普遍周邊開源產品，建議使用dubbo-2.3.3以上版本（推薦使用）
• 依賴於Zookeeper的穩定性

• Redis

• 支持基於客戶端雙寫的集羣方式，性能高
• 要求服務器時間同步，用於檢查心跳過時髒數據

• Multicast

• 去中心化，不須要安裝註冊中心
• 依賴於網絡拓普和路由，跨機房有風險

• Simple

• Dogfooding，註冊中心自己也是一個標準的RPC服務
• 沒有集羣支持，可能單點故障

• cluster（ 路由層）

• 封裝多個提供者的路由及負載均衡，並橋接註冊中心
• 以Invoker爲中心，擴展接口爲Cluster, Directory, Router, LoadBalance
• Cluster選擇

• Failover

• 失敗自動切換，當出現失敗，重試其它服務器，一般用於讀操做（推薦使用）
• 重試會帶來更長延遲

• Failfast

• 快速失敗，只發起一次調用，失敗當即報錯,一般用於非冪等性的寫操做
• 若是有機器正在重啓，可能會出現調用失敗

• Failsafe

• 失敗安全，出現異常時，直接忽略，一般用於寫入審計日誌等操做
• 調用信息丟失

• Failback

• 失敗自動恢復，後臺記錄失敗請求，定時重發，一般用於消息通知操做
• 不可靠，重啓丟失

• Forking

• 並行調用多個服務器，只要一個成功即返回，一般用於實時性要求較高的讀操做
• 須要浪費更多服務資源

• Broadcast

• 廣播調用全部提供者，逐個調用，任意一臺報錯則報錯，一般用於更新提供方本地狀態
• 速度慢，任意一臺報錯則報錯

• Router選擇

• Random

• 隨機，按權重設置隨機機率（推薦使用）
• 在一個截面上碰撞的機率高，重試時，可能出現瞬間壓力不均

• RoundRobin

• 輪循，按公約後的權重設置輪循比率
• 存在慢的機器累積請求問題，極端狀況可能產生雪崩

• LeastActive

• 最少活躍調用數，相同活躍數的隨機，活躍數指調用先後計數差，使慢的機器收到更少請求
• 不支持權重，在容量規劃時，不能經過權重把壓力導向一臺機器壓測容量

• ConsistentHash

• 一致性Hash，相同參數的請求老是發到同一提供者，當某一臺提供者掛時，本來發往該提供者的請求，基於虛擬節點，平攤到其它提供者，不會引發劇烈變更
• 壓力分攤不均

• 路由規則

• 條件路由

• 基於條件表達式的路由規則，功能簡單易用
• 有些複雜多分支條件狀況，規則很難描述

• 腳本路由

• 基於腳本引擎的路由規則，功能強大
• 沒有運行沙箱，腳本能力過於強大，可能成爲後門

• 容器

• Spring

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

• Jetty

• 啓動一個內嵌Jetty，用於彙報狀態
• 大量訪問頁面時，會影響服務器的線程和內存

• Log4j

• 自動配置log4j的配置，在多進程啓動時，自動給日誌文件按進程分目錄
• 用戶不能控制log4j的配置，不靈活

• monitor（ 監控層）

• RPC調用次數和調用時間監控
• 以Statistics爲中心，擴展接口爲MonitorFactory, Monitor, MonitorService

• protocol（ 遠程調用層）

• 封裝RPC調用
• 以Invocation, Result爲中心，擴展接口爲Protocol, Invoker, Exporter
• 選擇

• Dubbo協議

• 採用NIO複用單一長鏈接，並使用線程池併發處理請求，減小握手和加大併發效率，性能較好（推薦使用）
• 適合於小數據量大併發的服務調用，以及服務消費者機器數遠大於服務提供者機器數的狀況
• Dubbo缺省協議不適合傳送大數據量的服務，好比傳文件，傳視頻等，除非請求量很低
• Dubbo協議缺省每服務每提供者每消費者使用單一長鏈接，若是數據量較大，可使用多個鏈接
• 爲防止被大量鏈接撐掛，可在服務提供方限制大接收鏈接數，以實現服務提供方自我保護
• 在大文件傳輸時，單一鏈接會成爲瓶頸
• 總結

• 鏈接個數：單鏈接
• 鏈接方式：長鏈接
• 傳輸協議：TCP
• 傳輸方式：NIO異步傳輸
• 序列化：Hessian二進制序列化
• 適用範圍：傳入傳出參數數據包較小（建議小於100K），消費者比提供者個數多，單一消費者沒法壓滿提供者，儘可能不要用dubbo協議傳輸大文件或超大字符串。
• 適用場景：常規遠程服務方法調用

• Rmi協議

• 可與原生RMI互操做，基於TCP協議
• 偶爾會鏈接失敗，需重建Stub

• Hessian協議

• 可與原生Hessian互操做，基於HTTP協議
• 需hessian.jar支持，http短鏈接的開銷大
• Hessian協議用於集成Hessian的服務，Hessian底層採用Http通信，採用Servlet暴露服務，Dubbo缺省內嵌Jetty做爲服務器實現
• 能夠和原生Hessian服務互操做

• 提供者用Dubbo的Hessian協議暴露服務，消費者直接用標準Hessian接口調用
• 或者提供方用標準Hessian暴露服務，消費方用Dubbo的Hessian協議調用
• 基於Hessian的遠程調用協議

• 總結

• 鏈接個數：多鏈接
• 鏈接方式：短鏈接
• 傳輸協議：HTTP
• 傳輸方式：同步傳輸
• 序列化：Hessian二進制序列化
• 適用範圍：傳入傳出參數數據包較大，提供者比消費者個數多，提供者壓力較大，可傳文件
• 適用場景：頁面傳輸，文件傳輸，或與原生hessian服務互操做

• 約束

• 參數及返回值需實現Serializable接口
• 參數及返回值不能自定義實現List, Map, Number, Date, Calendar等接口，只能用JDK自帶的實現，由於hessian會作特殊處理，自定義實現類中的屬性值都會丟失

• exchange（ 信息交換層）

• 封裝請求響應模式，同步轉異步
• 以Request, Response爲中心，擴展接口爲Exchanger, ExchangeChannel, ExchangeClient, ExchangeServer

• transport（ 網絡傳輸層）

• 抽象mina和netty爲統一接口
• 以Message爲中心，擴展接口爲Channel, Transporter, Client, Server, Codec
• 選擇

• Netty

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

• Mina

• 老牌NIO框架，穩定
• 待發送消息隊列派發不及時，大壓力下，會出現FullGC

• Grizzly

• Sun的NIO框架，應用於GlassFish服務器中
• 線程池不可擴展，Filter不能攔截下一Filter

• serialize（ 數據序列化層）

• 可複用的一些工具
• 擴展接口爲Serialization, ObjectInput, ObjectOutput, ThreadPool
• 選擇

• Hessian

• 性能較好，多語言支持（推薦使用）
• Hessian的各版本兼容性很差，可能和應用使用的Hessian衝突，Dubbo內嵌了hessian3.2.1的源碼

• Dubbo

• 經過不傳送POJO的類元信息，在大量POJO傳輸時，性能較好
• 當參數對象增長字段時，需外部文件聲明

• Json

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

• Java

• Java原生支持
• 性能較差

• 關係說明

• 在RPC中，Protocol是核心層，也就是隻要有Protocol + Invoker + Exporter就能夠完成非透明的RPC調用，而後在Invoker的主過程上Filter攔截點。
• 圖中的Consumer和Provider是抽象概念，只是想讓看圖者更直觀的瞭解哪些類分屬於客戶端與服務器端，不用Client和Server的緣由是Dubbo在不少場景下都使用Provider, Consumer, Registry, Monitor劃分邏輯拓普節點，保持統一律念。
• 而Cluster是外圍概念，因此Cluster的目的是將多個Invoker假裝成一個Invoker，這樣其它人只要關注Protocol層Invoker便可，加上Cluster或者去掉Cluster對其它層都不會形成影響，由於只有一個提供者時，是不須要Cluster的。
• Proxy層封裝了全部接口的透明化代理，而在其它層都以Invoker爲中心，只有到了暴露給用戶使用時，才用Proxy將Invoker轉成接口，或將接口實現轉成Invoker，也就是去掉Proxy層RPC是能夠Run的，只是不那麼透明，不那麼看起來像調本地服務同樣調遠程服務。
• 而Remoting實現是Dubbo協議的實現，若是你選擇RMI協議，整個Remoting都不會用上，Remoting內部再劃爲Transport傳輸層和Exchange信息交換層，Transport層只負責單向消息傳輸，是對Mina,Netty,Grizzly的抽象，它也能夠擴展UDP傳輸，而Exchange層是在傳輸層之上封裝了Request-Response語義。
• Registry和Monitor實際上不算一層，而是一個獨立的節點，只是爲了全局概覽，用層的方式畫在一塊兒

• Dubbo模塊分包

• 模塊

• dubbo-common 公共邏輯模塊，包括Util類和通用模型。
• dubbo-remoting 遠程通信模塊，至關於Dubbo協議的實現，若是RPC用RMI協議則不須要使用此包。
• dubbo-rpc 遠程調用模塊，抽象各類協議，以及動態代理，只包含一對一的調用，不關心集羣的管理。
• dubbo-cluster 集羣模塊，將多個服務提供方假裝爲一個提供方，包括：負載均衡, 容錯，路由等，集羣的地址列表能夠是靜態配置的，也能夠是由註冊中心下發。
• dubbo-registry 註冊中心模塊，基於註冊中心下發地址的集羣方式，以及對各類註冊中心的抽象。
• dubbo-monitor 監控模塊，統計服務調用次數，調用時間的，調用鏈跟蹤的服務。
• dubbo-config 配置模塊，是Dubbo對外的API，用戶經過Config使用Dubbo，隱藏Dubbo全部細節。
• dubbo-container 容器模塊，是一個Standlone的容器，以簡單的Main加載Spring啓動，由於服務一般不須要Tomcat/JBoss等Web容器的特性，不必用Web容器去加載服務

• 與分層的不一樣點在於

• container爲服務容器，用於部署運行服務，沒有在層中畫出。
• protocol層和proxy層都放在rpc模塊中，這兩層是rpc的核心，在不須要集羣時(只有一個提供者)，能夠只使用這兩層完成rpc調用。
• transport層和exchange層都放在remoting模塊中，爲rpc調用的通信基礎。
• serialize層放在common模塊中，以便更大程度複用

• 模型

• Protocol是服務域，它是Invoker暴露和引用的主功能入口，它負責Invoker的生命週期管理
• Invoker是實體域，它是Dubbo的核心模型，其它模型都向它靠擾，或轉換成它，它表明一個可執行體，可向它發起invoke調用，它有多是一個本地的實現，也多是一個遠程的實現，也可能一個集羣實現
• Invocation是會話域，它持有調用過程當中的變量，好比方法名，參數等

• 基本原則

• 採用Microkernel + Plugin模式，Microkernel只負責組將Plugin，Dubbo自身的功能也是經過擴展點實現的，也就是Dubbo的全部功能點均可被用戶自定義擴展所替換
• 採用URL做爲配置信息的統一格式，全部擴展點都經過傳遞URL攜帶配置信息

• 擴展點加載

• Dubbo的擴展點加載從JDK標準的SPI(Service Provider Interface)擴展點發現機制增強而來
• 在擴展類的jar包內，放置擴展點配置文件：META-INF/dubbo/接口全限定名，內容爲：配置名=擴展實現類全限定名，多個實現類用換行符分隔
• 注意：這裏的配置文件是放在你本身的jar包內，不是dubbo自己的jar包內，Dubbo會全ClassPath掃描全部jar包內同名的這個文件，而後進行合併

• Provider暴露服務的過程

• 具體服務到Invoker的轉換

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

• JavassistProxyFactory
• JdkProxyFactory

• Invoker轉換爲Exporter

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

• DubboProtocol

• Dubbo協議的Invoker轉爲Exporter發生在DubboProtocol類的export方法，它主要是打開socket偵聽服務，並接收客戶端發來的各類請求，通信細節由Dubbo本身實現

• HessianProtocol
• InjvmProtocol

• 它經過Spring或Dubbo或JDK來實現RMI服務，通信細節這一塊由JDK底層來實現，這就省了很多工做量

• RmiProtocol
• WebServiceProtocol

• Export

• Consumer消費服務的過程

• 把遠端服務轉爲Invoker

• ReferenceConfig
• Protocol：refer()

• DubboProtocol
• HessianProtocol
• InjvmProtocol
• RmiProtocol
• WebServiceProtocol

• 把Invoker轉爲客戶端須要的接口

• Invoker

• DubboInvoker
• HessianInvoker
• InjvmInvoker
• RmiInvoker
• WebServiceInvoker

• ProxyFactory：getProxy()

• JavassistProxyFactory
• JdkProxyFactory

• ref
• 過程：首先ReferenceConfig類的init方法調用Protocol的refer方法生成Invoker實例(如上圖中的紅色部分)，這是服務消費的關鍵。接下來把Invoker轉換爲客戶端須要的接口

• 無處不在的Invoker

• 因爲Invoker是Dubbo領域模型中很是重要的一個概念，不少設計思路都是向它靠攏
• 服務消費者Invoker

• 用戶代碼經過這個proxy調用其對應的Invoker(DubboInvoker、 HessianRpcInvoker、 InjvmInvoker、 RmiInvoker、 WebServiceInvoker中的任何一個)，而該Invoker實現了真正的遠程服務調用

• 服務提供者Invoker

• 被封裝成爲一個AbstractProxyInvoker實例，並新生成一個Exporter實例。這樣當網絡通信層收到一個請求後，會找到對應的Exporter實例，並調用它所對應的AbstractProxyInvoker實例，從而真正調用了服務提供者的代碼

• 線程模型

• 過程

• Proxy
• Client

• Transporter

• Header -> Codec
• Body -> Serialization

• Server
• Dispatcher
• ThreadPool
• Implementation

• Dispatcher

• all 全部消息都派發到線程池，包括請求，響應，鏈接事件，斷開事件，心跳等
• direct 全部消息都不派發到線程池，所有在IO線程上直接執行
• message 只有請求響應消息派發到線程池，其它鏈接斷開事件，心跳等消息，直接在IO線程上執行
• execution 只請求消息派發到線程池，不含響應，響應和其它鏈接斷開事件，心跳等消息，直接在IO線程上執行
• connection 在IO線程上，將鏈接斷開事件放入隊列，有序逐個執行，其它消息派發到線程池

• ThreadPool

• fixed 固定大小線程池，啓動時創建線程，不關閉，一直持有。(缺省)
• cached 緩存線程池，空閒一分鐘自動刪除，須要時重建
• limited 可伸縮線程池，但池中的線程數只會增加不會收縮。(爲避免收縮時忽然來了大流量引發的性能問題)

4，加強功能

• 併發控制
• 鏈接控制： 鏈接數控制
• 分組聚合： 分組聚合返回值，用於菜單聚合等服務
• 泛化引用： 泛化調用，無需業務接口類進行遠程調用，用於測試平臺，開放網關橋接等
• 異步調用
• 延遲暴露： 延遲暴露服務，用於等待應用加載warmup數據，或等待spring加載完成
• 延遲鏈接： 延遲創建鏈接，調用時創建
• 隱私傳參： 附加參數

5，Dubbo擴展

• 方法

• 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設計原則

• 模塊分包原則

• 複用度

• 包中的類應該有一樣的重用可能性
• 緊密協做的類應該放在一個包
• 對於變化因子，包中的類應全改或全不改
• 變化應在包內終止，而不傳播到其它包
• 發佈的粒度和複用度相同

• 穩定度

• 被依賴的包應該老是比依賴者更穩定
• 不要讓一個穩定的包依賴於不穩定包
• 單向依賴，無環依賴

• 抽象度

• 越穩定的包應該越抽象
• 穩定的包不抽象將致使擴展性極差
• 抽象的包不穩定將致使其依賴包跟隨變化

• 框架擴展原則

• 微核 +插件體系

• OSGI
• IoC
• SPI

• 平等對待第三方 

• Dogfooding

• 框架本身的功能也要擴展點實現
• 甚至微核的加載方式也能夠擴展

• Autowire

• 裝配邏輯由擴展點之間互助完成
• 杜絕硬編碼的橋接和中間代碼

• Cascading

• 層疊擴展粒度，逐級細分
• 由大的擴展點加載小的擴展點

• Law of Demeter

• 只與觸手可及的擴展點交互，間接轉發
• 保持行爲單一，輸入輸出明確

• 外置生命週期

• API傳入參數，SPI擴展點實例
• 儘可能引用外部對象的實例，而不類元

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

• 儘可能使用IoC注入，減小靜態工廠方法調用

• 正確：setXxx(xxx)
• 錯誤：XxxFactory.getXxx(); applicationContext.getBean(「xxx」)

• 最少化概念模型
• 一致性數據模型

• Dubbo統一URL模型

• 全部配置信息都轉換成URL的參數
• 全部的元信息傳輸都採用URL
• 全部接口均可以獲取到URL

• 領域劃分原則

• 服務域

• 指產品主要功能入口，同時負責實體域和會話域的生命週期管理。
• Velocity的Engine
• Spring的BeanFactory

• 實體域

• 表示你要操做的對象模型，無論什麼產品，總有一個核心概念，你們都繞圍它轉。
• Velocity的Template
• Spring的Bean

• 會話域

• 表示每次操做瞬時狀態，操做前建立，操做後銷燬。
• Velocity的Context
• Spring的Invocation

• 領域模型劃分優點

• 結構清晰，可直接套用
• 充血模型，實體域帶行爲
• 可變與不可變狀態分離，可變狀態集中
• 全部領域線程安全，不須要加鎖

• 領域模型線程安全性

• 服務域

• 一般服務域是無狀態，或者只有啓動時初始化不變狀態，因此天生線程安全，只需單一實例運行

• 實體域

• 一般設計爲不變類，全部屬性只讀，或整個類引用替換，因此是線程安全的

• 會話域

• 保持全部可變狀態，且會話域只在線程棧內使用，即每次調用都在線程棧內建立實例，調用完即銷燬，沒有競爭，因此線程安全

• 接口分離原則

• API & SPI

• 聲明式API（Dubbo API）：描述須要什麼

• ServiceConfig
• ReferenceConfig
• RpcContext

• 過程式SPI（Dubbo SPI）：描述怎麼實現

• Protocol
• Transporter
• LoadBalance

• API可配置，必定可編程

• 配置用於簡化常規使用
• 編程接口用於框架集成

• API區分命令與查詢

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

• 組件協做原則

• 管道 v.s. 派發

• 管道

• 組合行爲
• 主功能以截面實現
• 好比：Servlet

• 派發

• 策略行爲
• 主功能以事件實現
• 好比： Swing

• 分佈 v.s. 共享

• 分佈

• 在行爲交互爲主的系統是適用
• 狀態經過行爲傳遞

• 共享

• 在以管理狀態爲主的系統中適用
• 狀態經過倉庫共享

• 主過程攔截

• Web框架的請求響應流
• ORM框架的SQL執行
• Service框架的調用過程
• 反例：IBatis2在SQL執行過程當中沒有設攔截點，致使添加安全或日誌攔截，執行前修改分頁SQL等，不得不hack源代碼

• 事件派發

• 過程

• 執行先後
• 觸發附帶非關鍵行爲

• 狀態

• 值的變化
• 觸發狀態觀察者行爲

• 關鍵路徑

• 關鍵路徑

• 採用攔截鏈分離職責
• 保持截面功能單一，不易出問題

• 非關鍵路徑

• 採用後置事件派發
• 確保派發失敗，不影響主過程運行

• 協做防護

• 可靠性分離

• 可靠操做
• 不可靠操做 (儘可能縮小)

• 狀態分離

• 無狀態
• 有狀態 (儘可能縮小)
• 不可變類 (儘可能final)

• 狀態驗證

• 儘早失敗
• 前置斷言 + 後置斷言 + 不變式

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

• 異常信息給出解決方案
• 日誌信息包含環境信息

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

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

• 功能演進原則

• 開閉原則

• 對擴展開放
• 對修改關閉
• 軟件質量的降低，來源於修改
• 替換整個實現類，而不是修改其中的某行

• 增量式 v.s.擴充式

• Dubbo增量式擴展

• Remoting

• Transport：

• 單向消息發送，抽象Mina/Netty

• Exchange：

• 封裝Request-Respose語義
• 調用兩次單向消息發送完成

• RPC

• Portocol：

• 協議實現，不透明，點對點

• Cluster：

• 將集羣中多個提供者假裝成一個

• Proxy：

• 透明化接口，橋接動態代理

• 在高階附加功能

• 儘量少的依賴低階契約，用最少的抽象概念實現功能
• 當低階切換實現時，高階功能能夠繼續複用

7，Dubbo編碼約定

• 異常和日誌：

• 儘量攜帶完整的上下文信息，好比出錯緣由，出錯的機器地址，調用對方的地址，連的註冊中心地址，使用Dubbo的版本等。
• 儘可能將直接緣由寫在最前面，全部上下文信息，在緣由後用鍵值對顯示。
• 拋出異常的地方不用打印日誌，由最終處理異常者決定打印日誌的級別，吃掉異常必需打印日誌。
• 打印ERROR日誌表示須要報警，打印WARN日誌表示能夠自動恢復，打印INFO表示正常信息或徹底不影響運行。
• 建議應用方在監控中心配置ERROR日誌實時報警，WARN日誌每週彙總發送通知。
• RpcException是Dubbo對外的惟一異常類型，全部內部異常，若是要拋出給用戶，必須轉爲RpcException。
• RpcException不能有子類型，全部類型信息用ErrorCode標識，以便保持兼容。

• 配置和URL：

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

• 單元和集成測試：

• 單元測試統一用JUnit和EasyMock，集成測試用TestNG，數據庫測試用DBUnit。
• 保持單元測試用例的運行速度，不要將性能和大的集成用例放在單元測試中。
• 保持單元測試的每一個用例都用try...finally或tearDown釋放資源。
• 減小while循環等待結果的測試用例，對定時器和網絡的測試，用以將定時器中的邏輯抽爲方法測試。
• 對於容錯行爲的測試，好比failsafe的測試，統一用LogUtil斷言日誌輸出。

• 擴展點基類與AOP：

• AOP類都命名爲XxxWrapper，基類都命名爲AbstractXxx。
• 擴展點之間的組合將關係由AOP完成，ExtensionLoader只負載加載擴展點，包括AOP擴展。
• 儘可能採用IoC注入擴展點之間的依賴，不要直接依賴ExtensionLoader的工廠方法。
• 儘可能採用AOP實現擴展點的通用行爲，而不要用基類，好比負載均衡以前的isAvailable檢查，它是獨立於負載均衡以外的，不須要檢查的是URL參數關閉。
• 對多種類似類型的抽象，用基類實現，好比RMI,Hessian等第三方協議都已生成了接口代理，只需將將接口代理轉成Invoker便可完成橋接，它們能夠用公共基類實現此邏輯。
• 基類也是SPI的一部分，每一個擴展點都應該有方便使用的基類支持。

• 模塊與分包：

• 基於複用度分包，老是一塊兒使用的放在同一包下，將接口和基類分紅獨立模塊，大的實現也使用獨立模塊。
• 全部接口都放在模塊的根包下，基類放在support子包下，不一樣實現用放在以擴展點名字命名的子包下。
• 儘可能保持子包依賴父包，而不要反向。

8，Dubbo高性能之道

• 參考文章「【總結】Netty（RPC高性能之道）原理剖析 」