dubbo源碼分析一：總體分析

本文做爲dubbo源碼分析的第一章，先從整體上來分析一下dubbo的代碼架構、功能及優缺點，注意，本文只分析說明開源版本提供的代碼及功能。

1.dubbo的代碼架構： 

    spring適配層：常規的spring適配方法，內容包括使用dubbo.xsd文件來定義dubbo相關的元素及屬性；DubboNamespaceHandler用來向spring容器註冊dubbo的元素解析器；DubboBeanDefinitionParser用來解析具體的dubbo元素。

    應用協議層：關於thrift，dubbo並無實現原生態的thrift協議，而是進行了相應的改造，而且thrift的版本是0.8的版本，不建議在生產中使用thrift協議；關於http協議，dubbo使用了spring框架的httpinvoker相關的類及協議，客戶端能夠脫離dubbo獨立調用服務端；關於webservice協議，支持soap協議，客戶端能夠脫離dubbo獨立調用服務端。

    註冊中心：在實際的測試過程當中，多播方式的註冊中心不能有效地識別服務端、客戶端已經掉線停服的狀況，不建議在生產環境中使用。

 

2.dubbo在服務治理方面提供的功能

    負載均衡：dubbo是在服務端配置的負載均衡狀況，經過註冊中心將信息傳遞給消費者，消費者使用第一個服務器的負載均衡配置，負載均衡配置能夠經過監控中心進行統一的更改。

    路由：經過本人對於源碼的解讀及相關的測試，dubbo應該是不支持跨數據中心的路由。

    限流：經過在consumer上添加限流過濾器來實現，沒有在服務端作限流。

 

3.dubbo的優缺點

優勢：

    a.支持多種應用協議，而且協議方便擴展，例如：若是以前採用了protocolbuffer協議+netty的方式，能夠在dubbo的源碼上增長適配處理便可

    b.支持多種底層tcp容器

    c.支持http、webservice這樣的跨語言協議，對於其它語言的客戶端能夠在不訪問註冊中心的狀況下，直接經過跨語言的協議來調用dubbo服務，固然這也失去了服務治理的意義

    d.支持多種註冊中心，生產環境下，註冊中心能夠選擇redis和zookeeper兩種中的一種

    e.支持多種cluster的調用方式

    f.經過服務端和監控中心來控制負載均衡的方式

缺點：

    a.缺乏其它語言的支持，對於多語言的應用場景，服務治理比較困難

    b.缺乏跨數據中心的流量切換功能

    c.不能支持thrift的原生協議

    d.開源版本的服務治理功能還有待增強

    e.對於tcp長鏈接，沒有采用鏈接池來處理

 

4.總結

    我聽到不少的程序員說，咱們要上服務治理，可是各位在選擇服務治理框架的過程當中，仍是要切實的注意如下幾點：

    a.務必對於現有的服務改動最小，畢竟老闆僱傭咱們來工做，不是讓咱們玩各類技術的，最小的投入最大的收穫纔是咱們想要看到的結果，固然系統已經肯定重構不在此範疇

    b.dubbo不能解決由於代碼設計和實現的bug，反而有可能由於引入了咱們不熟悉的框架，使得各類異常狀況出現，解決生產問題，仍是要靠內功

    c.對於多語言的狀況下，dubbo和motan等服務治理框架並不合適，雖然說dubbo能夠支持一些標準化的協議(http、webservice等)，可是對於非java語言的consumer並不在服務治理的管理範圍內，也就失去了服務治理的意義

    d.若是選擇了dubbo，務必作好深刻理解代碼的準備，必定有一些狀況是須要咱們經過改動源碼來實現的，畢竟開源的dubbo只是一箇中止維護的閹割版。