我們?cè)跇?gòu)建微服務(wù)時(shí)犯過的最大錯(cuò)誤
點(diǎn)擊上方“服務(wù)端思維”，選擇“設(shè)為星標(biāo)”
回復(fù)”669“獲取獨(dú)家整理的精選資料集
回復(fù)”加群“加入全國服務(wù)端高端社群「后端圈」
因?yàn)檫@能讓我們面對(duì)現(xiàn)實(shí)：構(gòu)建分布式系統(tǒng)可能會(huì)變得很復(fù)雜。公平地說，建造單體系統(tǒng)也是如此。但不同的是，我們大多數(shù)人選擇了比分布式的復(fù)雜性更高的東西。任何有經(jīng)驗(yàn)的開發(fā)人員或架構(gòu)師都會(huì)告訴你，大多數(shù)人實(shí)際上不需要完全接受微服務(wù)。
我問過的所有人都建議將這兩者相結(jié)合。并且只在絕對(duì)必要的情況下才需單獨(dú)使用微服務(wù)。但我的團(tuán)隊(duì)沒有這樣，我當(dāng)時(shí)沒有這種智慧。所以我們搶先了一步。犯了書中提到的所有錯(cuò)誤。以下是一些最令人震驚的錯(cuò)誤示例。
在微服務(wù)領(lǐng)域，服務(wù)之間的通信是一個(gè)大問題。有人會(huì)說這是最大的問題。這一切都要?dú)w究于分布式事務(wù)。在電子商務(wù)應(yīng)用程序的經(jīng)典示例中，創(chuàng)建新訂單的過程可能會(huì)涉及到需在多個(gè)不同的服務(wù)中進(jìn)行操作，比如訂單服務(wù)、客戶服務(wù)等。在單體應(yīng)用中，只需一個(gè)函數(shù)調(diào)用即可。但是使用微服務(wù)，情況就不那么好了。你可以引入 Sagas 來處理多服務(wù)事務(wù)。但這會(huì)讓你感到脊椎發(fā)冷。實(shí)現(xiàn) Sagas 并非易事。
盡管如此，我們還是不太清楚。所以我們實(shí)現(xiàn)了基于編排的 Sagas 來解決這個(gè)問題。優(yōu)勢(shì)之處在于我們定制了每個(gè)服務(wù)用來通信和執(zhí)行這些 Sagas 的消息代理。使用 Redis 流和 Go 自行構(gòu)建。當(dāng)然，最終結(jié)果很好，建造起來也非常有趣。但我們本可以用做這個(gè)的時(shí)間，搭建一個(gè)單體應(yīng)用。開始就失敗了。
這一點(diǎn)可以歸結(jié)為經(jīng)驗(yàn)：從技術(shù)上講，有些地方是你不應(yīng)該去的。給定一個(gè)特定的項(xiàng)目時(shí)間表和一個(gè)具有特定能力的團(tuán)隊(duì)，有些路徑是你不應(yīng)該探索的。我們的錯(cuò)誤在于我們認(rèn)為我們可以去任何微服務(wù)之神召喚我們的地方。
這是不正確的。不幸的是，這完全是錯(cuò)誤的。在某種程度上，你會(huì)意識(shí)到，某些內(nèi)容僅僅在 YouTube 主題演講中聽起來可行，但并不意味著在你的項(xiàng)目它們也是可行的。如果我們對(duì)我們?cè)敢馓幚淼膹?fù)雜性設(shè)置了一個(gè)上限，我們就會(huì)為自己節(jié)省一些不必要的麻煩。我想你可以用另一種方式來表述這個(gè)錯(cuò)誤，“我們給了自己太多的時(shí)間”。如果我們有一個(gè)更短的截止日期，這些麻煩將會(huì)自動(dòng)消除。
話又說回來，這里有個(gè)很微妙的界限。如果復(fù)雜性限制設(shè)置的過低，你就會(huì)駕駛一架由筷子做成的飛機(jī)。但如果設(shè)置的過高，你就永遠(yuǎn)不會(huì)離開跑道。在這兩種情況下，你都會(huì)完蛋。知道如何切餡餅通常來自經(jīng)驗(yàn)。所以我建議你做出最好的猜測(cè)，然后在 Medium 上傳播，以吸引更聰明的工程師的注意，他們會(huì)糾正你的錯(cuò)誤。
最后，有一件事可以解決我們的大部分問題。歸根結(jié)底，分布式架構(gòu)是用來解決問題的。所以，在決定使用它之前，你需要知道這個(gè)問題是什么，你還需要了解你的解決方案，以確定它們的匹配程度。這兩個(gè)我們都不了解。
因?yàn)檎l會(huì)在一開始時(shí)就花上幾天的時(shí)間來定義問題呢？這種紀(jì)律很少見，尤其是在需要立即構(gòu)建的環(huán)境中?，F(xiàn)在，我知道，通過更關(guān)注實(shí)現(xiàn)，可以節(jié)省正確定義問題所“損失”的時(shí)間。換句話說，你花更少的時(shí)間構(gòu)建錯(cuò)誤的東西。浪費(fèi)的時(shí)間會(huì)少很多。因此，明智的做法是確保你正在構(gòu)建的東西是正確的。
然而，我們沒有。我們的彎路不僅花費(fèi)了我們的時(shí)間和金錢。它們最終也是毫無意義的。我們建造并修復(fù)了我們不需要的東西。完成后，我們沒有使用它們。在開發(fā)期間，我們還不如在辦公室一直玩《英雄聯(lián)盟》，這還能鼓舞士氣。因此，很好地了解你的問題和解決方案并不是一個(gè)糟糕的想法。
話說回來，這其中的樂趣何在呢？在我看來，你也可能會(huì)浪費(fèi)大量的時(shí)間去構(gòu)建錯(cuò)誤的東西，在這個(gè)過程中收集了經(jīng)驗(yàn)來寫文章，然后在網(wǎng)上抱怨。這對(duì)我們有用。我是說，我們還活著在講述這個(gè)故事。
— 本文結(jié)束 —
● 漫談設(shè)計(jì)模式在 Spring 框架中的良好實(shí)踐
關(guān)注我，回復(fù) 「加群」 加入各種主題討論群。
對(duì)「服務(wù)端思維」有期待，請(qǐng)?jiān)谖哪c(diǎn)個(gè)在看
喜歡這篇文章，歡迎轉(zhuǎn)發(fā)、分享朋友圈
