dubbo 轉

 

http://blog.csdn.net/zhiguozhu/article/details/50517513

背景

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

• 單一應用架構
• • 當網站流量很小時，只需一個應用，將全部功能都部署在一塊兒，以減小部署節點和成本
  • 此時，用於簡化增刪改查工做量的 數據訪問框架(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高性能之道