被噴了！聊聊我開源的RPC框架那些事

前段時間利用業餘時間寫了一個簡單的 RPC 框架，花費了很多精力。開源出來以後，少部分不太友好的技術人站在上帝視角說了風涼話。就很難受，兄弟，誰尚未一個玻璃心。

簡單吐槽一波，給你們聊聊關於 guide-rpc-framework 的一些事情。

01 個人自定義 RPC 框架近況

關注個人大部分小夥伴應該都知道，3個月前，我利用業餘時間手寫一個簡單的 RPC 框架（玩具），名字叫作 guide-rpc-framework。

目前的話，這個項目已經有 0.5k 的 star。感謝小夥伴們的支持！

寫這個 RPC 框架的主要目的是爲了我的學習，開源出來的目的主要是想幫助到更多人。

02 開源的魅力

開源出來以後，大部小夥伴都是比較支持的，有不少小夥伴都參與了進來一塊兒完善。

這裏點名表揚一下Github用戶名爲 sakuragi1111 和 smile2coder 這兩位老哥。

sakuragi1111 這位老哥經過參考 Dubbo 源碼實現了 SPI 機制。

smile2coder 這位老哥爲 guide-rpc-framework 添加了經過註解實現服務消費的功能。

目前的話， guide-rpc-framework 已經支持經過註解進行服務消費和註冊。

程序世界，什麼樣的人都有，有人感謝你，也會有人貶低你。

03 不那麼好的聲音

在個人 guide-rpc-framework 開源以後，也常常會受到像：「你有本事別用現成的框架寫一個啊？」、「你這個寫的一點亮點都沒有，有啥意思？」、「都有了 Dubbo 以後，爲啥還要本身寫一個？」、「重複造輪子沒意義」......之類的不太友善的話語。

說句內心話，通常說出來這種話的人每每技術水平很低。

若是，你指出我哪裏寫的很差，我很樂意地去修改。可是，你站在上帝視角說着風涼話，那就是人品有問題了。

1.爲何不能利用現成的框架呢？（好比爲啥不用 JDK NIO 而用 Netty?）

絕不誇張地說：開源出來的東西，就是全體技術人共同的財富。

Netty 比 NIO 更好用、更完善，我爲啥還要直接使用 NIO呢？咱們日常常常接觸的 Dubbo、RocketMQ、Elasticsearch、gRPC 等等都用到了 Netty 啊。

2.你這個寫的一點亮點都沒有，有啥意思？

有能耐的話，你也能夠本身寫一個。說出此類的話的人，每每是有及其嫉妒心理的人。並且，RPC 框架自己就已經有不少比較成熟的例子了好比 Dubbo。說實話，Dubbo 基本是已近把 RPC 框架能考慮到的點都考慮到了。

我不信你一我的，能幹過人家一個團隊好多年的成果。

3.都有了 Dubbo 以後，爲啥還要本身寫一個？

必定要學會看 README!!!

我在項目的 README 中明確說明了：寫這個 RPC 框架主要是爲了經過造輪子的方式來學習，檢驗本身對於本身所掌握的知識的運用。

4.重複造輪子沒意義

咱們實際項目開發中是比較忌諱造輪子的，可是，實際學習過程當中造輪子絕對是最本身百利而無一害的！

個人 RPC 框架確定是沒法和 Dubbo 這類已經這麼成熟的相提並論。可是，在本身去寫 RPC 框架的時候，更加加深了本身對於 RPC 框架的認識。實現的過程當中，遇到了不少問題，解決問題的過程當中也提升了本身的編程能力。總而言之，造輪子是一種特別可以提升本身系統編程能力的手段。

04 擁抱開源

開源絕對是編程領域最美妙的事情之一，大幅提升了咱們的生產力。

沒事就去開源社區好比 Github 或者 Gitee 逛逛，在這裏你能夠get到各類好東西。

你能夠在 Github 分享不少東西，你的學習筆記、本身作的實戰項目、本身造的輪子......（資源類的不太推薦，太容易侵權）。

雖然，如今 Github 被不少人單純玩成了引流工具。可是，總體來講 Github 總體技術環境和氛圍仍是很不錯的！

另外，最好的話是要給項目弄一個英文版本，項目代碼中的註釋最好也要是英文的。畢竟是開源，最好是能準守開源精神使用世界通用語言（這一點我本身也沒作好，反思！）。

若是你想讓本身的開源項目被更多人知道的話，你能夠在下面技術平臺宣傳（不宣傳的話，開源的東西很難被別人知道，不要讓好東西被埋沒）：

若是有幫助的話，不要吝嗇大家手中的在看和贊！「懟」起來！

以上 4 本優質原創 PDF 微信搜「JavaGuide」後臺回覆「面試突擊」便可免費領取。