背景

前段時間在使用 Pulsar 的 admin API 時，發(fā)現(xiàn)其中的一個接口響應(yīng)非常慢：

admin.topics().getPartitionedStats(topic);

使用 curl 拿到的響應(yīng)結(jié)果非常大，同時也非常耗時：

圖片

具體的 issue 在這里：https://github.com/apache/pulsar/issues/21200

后面經(jīng)過分析，是因為某些 topic 的生產(chǎn)者和消費者非常多，導(dǎo)致這個查詢 topic 統(tǒng)計的接口數(shù)據(jù)量非常大。

圖片

但在我這個場景其實是不需要這些生產(chǎn)者和消費者信息的，現(xiàn)在就導(dǎo)致這個 topic 無法查看狀態(tài)，所以就建議新增兩個參數(shù)可以過濾這兩個字段。

流程

因為涉及到新增 API 了，所以社區(qū)維護者就建議我起草一個提案試試：

圖片

什么時候需要提案

此時就涉及到什么情況下需要給社區(qū)發(fā)起一個提案的問題了。

圖片

在官方的提案指南中有著詳細的說明，簡單來說就是：

• 對任何模塊新增了 API、或者是重大改動的新特性、監(jiān)控指標(biāo)、配置參數(shù)時都需要發(fā)起提案
• 對應(yīng)的如果只是對現(xiàn)有 bug 的修復(fù)、文檔等一些可控的變更時，是不需要發(fā)起提案的，直接提交 PR 即可。

提案步驟

起草

首先第一步就是根據(jù)官方模版起草一個提案：重點描述背景、目的、詳細設(shè)計等。

圖片

并發(fā)起一個 PR，如果不確定怎么寫的話可以參考已經(jīng)合并了的提案。

郵件討論

之后則是將這個 PR 發(fā)送到開發(fā)組郵箱中，讓社區(qū)成員參與討論。

圖片

這一步可能會比較耗時，提案內(nèi)容可能會被反復(fù)修改。

發(fā)起提案的一個重要目的是可以讓社區(qū)成員進行討論，評估是否需要這個提案或者是否 有其他解決方法。

發(fā)起投票

經(jīng)過討論，如果提案獲得通過后就可以發(fā)起投票了，至少需要有三個 binding 通過的投票后這個提案就通過了。

雖然任何人都可以參與投票，但社區(qū)只會考慮 PMC 的投票建議；投票的時效性也只有 48h。

圖片

image.png

48 小時候便可以發(fā)一個投票結(jié)果的郵件，如果達到通過條件便可以通知參與投票的 PMC 合并這個 PR 了。

圖片

實現(xiàn)提案

之后就是沒啥好說的實現(xiàn)過程，因為通常我們是需要在提案里詳細描述實現(xiàn)過程以及涉及到修改的地方。

總結(jié)

只要提案被 review 通過后實現(xiàn)起來就非常簡單了，跟著提案里的流程實現(xiàn)就好了。

這點非常類似于我們在企業(yè)中對某個業(yè)務(wù)做技術(shù)方案，如果大家都按照類似的流程嚴(yán)格審核方案，那實現(xiàn)起來是非?？斓?，而且可以盡量的減少事后扯皮。

所以最后我的實現(xiàn) PR 提交之后，都沒有任何的修改意見，直接就合并了；也大大降低了審核人員的負擔(dān)，提高整體效率。

以上就是我第一次參與 Pulsar 社區(qū)的提案過程，我猜測其他社區(qū)的流程也是大差不差；其中重點就是異步溝通；大家都認(rèn)可之后真的會比實時通信的效率高很多。

具體的提案細節(jié)可以閱讀官方指南 https://github.com/apache/pulsar/blob/master/pip/README.md