軟體架構-企業級dubbo應用（上）

上次說了dubbo的曆史，介紹，了解了cosumber ，proivder，registry 他們之間的調用管理。提供的源碼是cosumber 和 proivder 在一個項目裡面，在實際的企業開發中他們兩者之間都是在不同的項目下的。這次主要說說分布式開發和聯調，其實這個坑很大，比技術的坑要大，要深！每次檢視生産和消費者 直接這樣口頭或者文檔的形式是不是很low，其實可以搭建dubbo控制台，對于注冊中心上次使用了小廣播的形式，對于實際生産環境應該選擇哪種注冊中心這裡也會說到。

源碼：https://github.com/limingios/netFuture/tree/master/源碼/『網際網路架構』軟體架構-掌握dubbo正常應用（下）（41）/dubbo-study

（一）分布式項目開發與聯調

• 接口暴露與引用

  在一個RPC場景中 ，調用方是通過接口來調用服務端，傳入參數并獲得傳回結果。這樣服務端的接口和模型必須暴露給調用方項目。服務端如何暴露呢？用戶端如何引用呢？

1.接口資訊

2.模型資訊

3.異常

暴露接口的通常做法是 接口與實作分離，服務端将 接口、模型、異常 等統一放置于一個子產品，實作置于另一個子產品。調用方通過Maven進行引用。

記得當初剛開始使用RPC架構的dubbo的時候，服務端打一個jar包，通過qq的方式扔給用戶端的項目，然後他在放到maven的倉庫中。每次更新需要重複的進行qq的jar包發送，堅持了1個禮拜，太費勁了，開發的工程中，互相的扯皮，說jar包郵問題，他說沒問題隻能反編譯看jar包。直接拷貝發送jar包的方式也是可以的，一個兩個項目還是可以的，如果項目達到一定的量，你來回這樣發送就有點SB了，老鐵。

• 自動化建構與協作

  當項目越來越多，服務依賴關系越發複雜的時候，為了提高協作效率，必須采用自動化工具 完成 接口從編寫到建構成JAR包，最後到引用的整個過程。

流程描述：

1.服務提供者項目發人員編寫Client 接口

2.push 至遠端倉庫

3.jenkins 建構指定版本

4.jenkins Deploye 至私服倉庫 nexus

5.服務消費者項目開發人員基于maven 從私服務倉庫下載下傳

• 接口平滑更新

  在項目疊代過程當中， 經常會有多個項目依懶同一個接口，項目B、C都依懶了項目A當中的接口1，此時項目B業務需要，需要接口1多增加一個參數，更新完成後。項目B能正确建構上線，項目C卻不行。

之前的項目就存在過這個問題，如果接口變了，依賴的所有項目都要發生改變，當時項目為了解決這個問題。

解決辦法與原則

為什麼有緊急版本，為什麼要加班，很多時候就是這些細節沒控制好。

1.接口要做到向下相容：接口參數盡量以對象形式進行封裝。Model屬性隻增不删，如果需要廢棄，可以添加@Deprecated 辨別。

2.接口參數盡量不要用Map格式，Map不容易讓人讀懂，解析的時候也麻煩，有點互相傷害的意思，生産者也要傷害，消費者也要傷害，大小寫等等吧，主要map可讀性太差了。

3.如果出現了不可相容的變更，則必須通知調用方整改，并制定上線計劃。

4.千萬不要嘗試版本号這種方式，項目B更新成了新版本，項目C還是老版本，有的項目在新版本上，有的在老版本上，很容易混亂。

• 開發聯調

  在項目開發過程當中，一個開發或測試環境的注冊中心很有可能會同時承載着多個服務，如果兩組服務正在聯調，如何保證調用的是目标服務呢？

1.基于臨時分組聯調

group 分組在reference 和server 當中采用相同的臨時組 ,通過group 進行設定，設定配置檔案properties中配置個 名稱=value 然後 service的group={value}

2.直連提供者：

<dubbo:reference url="dubbo://127.0.0.1:20880" id="demoService"
timeout="2000"
interface="com.tuling.teach.service.DemoService" check="false"/>           

<dubbo:registry address="multicast://224.5.6.7:1234" register="false"/>