本文作為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只是一個停止維護的閹割版。