如何參與一個(gè)頂級(jí)開(kāi)源項(xiàng)目以及Dubbo調(diào)用過(guò)程中的異步轉(zhuǎn)同步是什么

如何參與一個(gè)頂級(jí)開(kāi)源項(xiàng)目以及Dubbo調(diào)用過(guò)程中的異步轉(zhuǎn)同步是什么，針對(duì)這個(gè)問(wèn)題，這篇文章詳細(xì)介紹了相對(duì)應(yīng)的分析和解答，希望可以幫助更多想解決這個(gè)問(wèn)題的小伙伴找到更簡(jiǎn)單易行的方法。

參與開(kāi)源

現(xiàn)在具體來(lái)聊聊參與開(kāi)源的事；

日常幾乎所有的開(kāi)發(fā)者都會(huì)享受到開(kāi)源項(xiàng)目所帶來(lái)的便利甚至是收益，受限于環(huán)境早在十幾年前甚至幾年前開(kāi)源活動(dòng)一直都是有國(guó)外開(kāi)發(fā)者主導(dǎo)。

但這幾年國(guó)內(nèi)互聯(lián)網(wǎng)公司逐漸國(guó)際化擴(kuò)大影響力也很大程度的提高了我們的開(kāi)發(fā)水平，以 BAT 為首出現(xiàn)了許多優(yōu)秀的開(kāi)源項(xiàng)目。

現(xiàn)在甚至參與開(kāi)源項(xiàng)目還能另辟蹊徑的拿到大廠 offer，所以其實(shí)不少朋友都想?yún)⑴c其中，可能這事給人的第一感覺(jué)就不太容易，所以現(xiàn)在還卡在第一步。

具體步驟

以下是以我個(gè)人經(jīng)驗(yàn)總結(jié)的幾大步驟：

• 發(fā)現(xiàn)問(wèn)題或自薦 feature 。

• fork 源碼。

• 本地開(kāi)發(fā)、自測(cè)。

• 發(fā)起 pull request 。

• 等待社區(qū) Code Review 。

• 跟進(jìn)社區(qū)意見(jiàn)調(diào)整代碼。

• 審核通過(guò)，合并進(jìn) master 分支，完成本次貢獻(xiàn)。

下面我會(huì)結(jié)合最近一次參與 Dubbo 的流程來(lái)具體聊聊。

發(fā)現(xiàn)問(wèn)題或自薦 feature

首先第一步自然要搞清楚自己本次貢獻(xiàn)的內(nèi)容是什么？通常都是解決某個(gè)問(wèn)題或者是提交一個(gè)新的 feature ；前者相對(duì)起來(lái)更加容易一些。

當(dāng)然這個(gè)問(wèn)題可以是自己使用過(guò)程中發(fā)現(xiàn)的，也可以是 Issues 列表中待解決的問(wèn)題。

以本次為例，就是我在使用過(guò)程中所發(fā)現(xiàn)的問(wèn)題，也提交了相關(guān) Issue 并寫(xiě)了一篇文章記錄并解決了該問(wèn)題：What？一個(gè) Dubbo 服務(wù)啟動(dòng)要兩個(gè)小時(shí)！

值得注意的是在提交 Issue 之前最好是先在 Issue 列表中通過(guò)關(guān)鍵字檢索下是否已經(jīng)有相關(guān)問(wèn)題，避免重復(fù)。

同時(shí)提交之后也許社區(qū)會(huì)進(jìn)行跟進(jìn)，被打上 invalid 標(biāo)簽認(rèn)為不是問(wèn)題，或者是使用姿勢(shì)不對(duì)也是有可能的。

fork 源碼，本地開(kāi)發(fā)

當(dāng)確定這是一個(gè)待修復(fù)的問(wèn)題時(shí)就可以著手開(kāi)發(fā)了。

首先第一步自然是將源碼拷貝一份到自己倉(cāng)庫(kù)中。

接著只需要 clone 自己倉(cāng)庫(kù)中的源碼到本地進(jìn)行開(kāi)發(fā)。

先回顧下我遇到的這個(gè)問(wèn)題。

簡(jiǎn)單來(lái)說(shuō)就是啟動(dòng) Dubbo 服務(wù)非常緩慢，經(jīng)過(guò)定位是 main 線程阻塞在了獲取本機(jī) ip 處。

所以當(dāng)時(shí)我提出的方案是：在獲取本機(jī) ip 時(shí)加上超時(shí)時(shí)間，一旦超時(shí)便拋出異?；蛘呤窃俅沃卦?，但起碼得有日志方便用戶定位問(wèn)題。

問(wèn)題是主線程會(huì)一直阻塞在此處 InetAddress.getLocalHost().getHostAddress()，但又需要知道它阻塞了多久才好判斷是否超時(shí)。

所以只能再額外開(kāi)啟一個(gè)線程，定時(shí)去檢測(cè) main 線程是否已經(jīng)完成任務(wù)了，以下便是我第一次 pr 的內(nèi)容。

這次的重點(diǎn)不是討論這里具體的技術(shù)細(xì)節(jié)，所以簡(jiǎn)單說(shuō)下步驟：

• 額為聲明了大小為 1 的線程池。

• 再聲明了一個(gè) volatile 標(biāo)志用于判斷主線程是否有完成任務(wù)。

• 聲明了一個(gè) condition 用于新線程做等待。

• 最后只需要運(yùn)行這個(gè)線程用于判斷這個(gè)標(biāo)志即可。

如何自測(cè)

開(kāi)發(fā)完成后下一步就是自測(cè)，由于這類項(xiàng)目是作為一個(gè)基礎(chǔ)包依賴于其他的項(xiàng)目才能運(yùn)行的，所以通常我們還得新建一個(gè)項(xiàng)目來(lái)配合做全流程測(cè)試（單測(cè)除外）。

這里我覺(jué)得還是有幾個(gè)小技巧值得注意。

第一個(gè)是版本號(hào)；因?yàn)樵诒镜販y(cè)試，所以需要使用 mvn clean install 將包安裝到本地才能在其他項(xiàng)目中依賴進(jìn)去進(jìn)行測(cè)試。

但由于我們從官方拉出來(lái)的代碼版本都已經(jīng)發(fā)布到了 maven 中央倉(cāng)庫(kù)中（不管是 release 還是 snapshot），所以我們本地倉(cāng)庫(kù)中肯定已經(jīng)存在這幾個(gè)版本的 jar 包。

一旦我們執(zhí)行 mvn clean install 將自己修改的代碼安裝到本地時(shí)，大概率是會(huì)出問(wèn)題的（也可能是我姿勢(shì)不對(duì)），這樣就會(huì)導(dǎo)致新建的項(xiàng)目中依賴不了自己新增的代碼。

所以我通常的做法是修改版本號(hào)，這個(gè)版本號(hào)是從來(lái)沒(méi)有被官方發(fā)布到中央倉(cāng)庫(kù)中的，可以確保自己新增的代碼會(huì)以一個(gè)全新版本安裝到本地，這樣我們?cè)僖蕾囘@個(gè)版本進(jìn)行測(cè)試即可。

不過(guò)再提交時(shí)得注意不要把這個(gè)版本號(hào)提交上去了。

發(fā)起 pull request

自測(cè)完成后便可發(fā)起 pull request 了，不要大意，這里還得有一個(gè)地方需要注意，那就是代碼換行符的問(wèn)題。

一旦換行符與源倉(cāng)庫(kù)的不一致時(shí)，git 會(huì)認(rèn)為這次修改是刪除后重來(lái)的，這樣會(huì)給 code review 帶來(lái)巨大的麻煩。

就像這樣，明明我改動(dòng)的行數(shù)并不多，但 git 確認(rèn)為你是推翻了重來(lái)，導(dǎo)致審核起來(lái)根本不知道你改了哪些地方。

最簡(jiǎn)單的方法就是設(shè)置自己 git 的全局配置，可以參考這里。

# 提交時(shí)轉(zhuǎn)換為L(zhǎng)F，檢出時(shí)轉(zhuǎn)換為CRLF
git config --global core.autocrlf true

# 提交時(shí)轉(zhuǎn)換為L(zhǎng)F，檢出時(shí)不轉(zhuǎn)換
git config --global core.autocrlf input

# 提交檢出均不轉(zhuǎn)換
git config --global core.autocrlf false

確認(rèn)沒(méi)問(wèn)題后便可點(diǎn)擊這里發(fā)起 pull request，后面按照引導(dǎo)執(zhí)行即可。

當(dāng)然各個(gè)項(xiàng)目之間還會(huì)有自己定制的貢獻(xiàn)流程，最好就是查看官方的貢獻(xiàn)指南。

http://dubbo.apache.org/en-us/docs/developers/contributor-guide/new-contributor-guide_dev.html

Code Review

pr 發(fā)起后便可等待社區(qū)審核了。

在這過(guò)程中要充分和社區(qū)進(jìn)行交流，有可能你的方案和社區(qū)的想法并不一致。

比如像我這次：

最終通過(guò)溝通加上自己后面的思考覺(jué)得還是社區(qū)的方案更加輕便合理一些，達(dá)成一致之后社區(qū)便將這次 pr 合并進(jìn) master 中。

其實(shí)整個(gè)過(guò)程我覺(jué)得最有意義的便是 code review 的過(guò)程，所有人都可以參與其中頭腦風(fēng)暴，其中也不乏技術(shù)大牛，不知不覺(jué)便能學(xué)到不少東西。

類似案例

雖然我之前的方案沒(méi)有被采納，但類似的用法（一個(gè)線程監(jiān)控其他線程）還是不少，正好在 Dubbo 中也有用到。

便是其中核心的服務(wù)調(diào)用，默認(rèn)情況下對(duì)使用者來(lái)說(shuō)這看起來(lái)是一個(gè)同步調(diào)用，也就是說(shuō)消費(fèi)方會(huì)等待 RPC 執(zhí)行完畢后才會(huì)執(zhí)行后續(xù)邏輯。

但其實(shí)在底層這就是一個(gè) TCP 網(wǎng)絡(luò)包的發(fā)送過(guò)程，本身就是異步的。

只是 Dubbo 在你不知道的情況下做了異步轉(zhuǎn)同步，這樣看起來(lái)就像是一個(gè)同步方法。

如圖中的紅框部分，Dubbo 自身調(diào)用了 get() 方法用于同步獲取服務(wù)提供者的返回結(jié)果。

邏輯其實(shí)也挺簡(jiǎn)單，和我上文的方案類似，只是這里的 isDone() 函數(shù)返回的是是否已經(jīng)拿到了服務(wù)提供者的返回值而已。

總結(jié)了參與開(kāi)源的具體步驟，其實(shí)也挺簡(jiǎn)單；就如官方所說(shuō)哪怕是提個(gè) Issue，修改一個(gè)錯(cuò)別字都算是參與，所以不要想的太難。

最后還簡(jiǎn)單分析了 Dubbo 調(diào)用過(guò)程中的異步轉(zhuǎn)同步的過(guò)程，掌握這些操作對(duì)自己平時(shí)開(kāi)發(fā)也是很有幫助的。

關(guān)于如何參與一個(gè)頂級(jí)開(kāi)源項(xiàng)目以及Dubbo調(diào)用過(guò)程中的異步轉(zhuǎn)同步是什么問(wèn)題的解答就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，如果你還有很多疑惑沒(méi)有解開(kāi)，可以關(guān)注億速云行業(yè)資訊頻道了解更多相關(guān)知識(shí)。