Categories
程式開發

我們為什麼用gRPC取代了Kafka


本文作者的技術團隊第一個 App 高度依賴 Kafka,她希望這個 App 能夠支持審計,具有很高的穩定性,從長遠看,隨著用戶量的增長也能夠輕鬆地處理高負載。但 Kafka 同樣帶來了基礎設施、系統維護和支持方面的成本問題,最終他們選擇了用 gRPC 取代了 Kafka。值得說明的是,二者的技術選型並沒有明確的優劣之分,有的只是業務場景和需求所帶來的取捨。

保持簡單的技術選型更重要

程序員職業生涯的大部分時間都用於維護和修復已有的系統。運氣好的話,如果你加入了一家初創公司,就有機會從頭開始構建全新的系統。這種興奮是無可言喻的,因為你有了一個可以“重新來過”的機會,終於可以把舊系統那些讓你感到反胃的東西扔掉了。

你開始思考可以使用哪些新技術,有些是你已經嘗試過的,有些是你在某篇文章上剛剛看到的,有些是你在之前項目中用得很成功的。也就是在這個時候,你感到了稍許的輕鬆,起碼在一段時間之內,你或者你的團隊會一直維護這個新系統。

於是你開始想:這個跟這篇文章的標題又有什麼關係?我為什麼討厭 Kafka?我其實不討厭 Kafka,或者更確切地說,是有那麼一點點。從使用體驗看,Kafka 並沒有給我留下非常好的印象,而且我們也只是在用它解決原本就不存在的問題。

不管你有沒有在遵循KISS(Keep It Simple Stupid,保持簡單)或YAGNI(You Aren't Gonna Need It,你其實不需要它)原則,又或者你只是想嘗試一下,我都希望你能夠從我們犯過的錯誤中學到一些東西,並在開始下一個項目時意識到,保持簡單是多麼的重要。

背景

我們的第一個 App 高度依賴 Kafka,因為我們希望我們的 App 能夠支持審計,具有很高的穩定性,從長遠看,隨著用戶量的增長也能夠輕鬆地處理高負載。

但 Kafka 卻讓整件事情變複雜了。我們的核心系統是一個投資系統,大多數時候不會直接與用戶發生交互,所以我們沒有必要創建一個高負載系統來支持用戶。我們的團隊本來就不大,時間又緊,在發布第一個版本時沒有必要花費額外的開銷。大多數情況下,真正到了需要處理大流量的時候,你可能已經把系統都重寫過了。而如果能夠走到這一步,說明離成功不遠了。

到了這個時候,被忽略的往往是基礎設施、系統維護和支持方面的成本問題。

問題

採用新技術需要時間

每一種技術都有它自己的特點和正確的“打開”方式。如果你團隊裡沒有人熟悉一項新技術,那麼很可能在一開始不知道怎樣做才是對的。等你知道該怎麼做的時候,可能已經需要重新來過了。

即使你團隊裡有人熟悉這項新技術,要讓其他人都熟悉起來也是需要時間的。有時候採用新技術是勢在必行的,但你要讓整個團隊都知道,並一起討論這樣做的必要性,另外也要注意不要在短時間內引入太多新技術。

技術棧越簡單就越容易上手

對於新手來說,簡單且在業內隨處可見的技術相比複雜的技術棧更容易上手。吃透一家公司的業務邏輯本來就需要很長時間,如果在技術棧層面再加入額外的複雜性,那麼開發團隊的產出必然會打折扣。在初創公司,一方面人員流動率很高,一方面公司又想快速成長,這種情況就會越加嚴重。

方便查找問題

調試生產環境的應用程序通常不是件容易的事情。如果應用程序本身很複雜,就會帶來更多的問題。

如果團隊裡只有一個人知道怎麼處理這些問題,那他就要一直盯著。如果這個人生病或者離開公司,對於團隊來說就是一個嚴重的打擊。而對於這個人來說,老是處理這些問題也是件很枯燥的事情,因為他也想做一些不一樣的事情。

另一個是處理問題需要很長的時間,這可能會導致用戶不開心,特別是如果你是一個新手,很可能會讓用戶暴跳如雷,然後留下不好的評論,或者跟他們的朋友說你的壞話。

方便維護和修改

簡單的應用程序不僅開發起來容易,修復、更新和添加新特性也很容易。有時候,對一個複雜的遺留應用程序進行更新通常會被列為“高難度”的難題,因為沒有人心裡有底,不敢去碰它,所以遲遲不敢動手。所以說,沒事不要去摸老虎的屁股,小心它回頭過來咬你。

我們是如何解決這些問題的

我的解決方案是改用 gPRC,並把 Kafka 從我們的技術棧中移掉。至於我們是怎麼做的就說來話長了,我們做了很多規劃,整個團隊花了三到四周的時間。我們是幸運的,因為公司給了我們足夠的時間來償還這筆巨額技術債務。

改造給我們帶來了很可觀的好處。新手上手的時間縮短了,他們跟支持工程師在一起一兩個禮拜就能夠對公司的業務有所了解。團隊成員可以輪流提供支持,因為每個人對代碼多多少少都了解一些,至少知道如何搜索日誌,找到問題的根源。支持 SLA 時間大幅下降,輪流值班也限制了知識孤島的形成,支持人員也不再感到無聊,因為他們每次做的事情可能不一樣。另外,我們的服務器數量減少了 50%。

每家公司都有自己的問題要解決,有時候採用複雜的技術架構也是在所難免的。但你需要確保採用技術是為了解決問題,而不是製造問題。代碼越少,bug 就越少。

英文原文

Killing Kafka: The Pitfalls of Over-architecting