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