構(gòu)建微服務(wù)時(shí)的三大常見錯(cuò)誤

? 來自：分布式實(shí)驗(yàn)室 公眾號(hào)，作者：解博

想在網(wǎng)上挨罵，最簡(jiǎn)單的方法就是寫點(diǎn)關(guān)于微服務(wù)架構(gòu)的東西。每個(gè)人對(duì)微服務(wù)都有自己的一套見解；無論我們是贊揚(yáng)還是批評(píng)，總會(huì)有人跳出來強(qiáng)調(diào)“你錯(cuò)了”。行吧，這畢竟是個(gè)遍地懂王的時(shí)代，挨噴實(shí)屬難免。我最近也寫了幾篇關(guān)于微服務(wù)的熱鬧文章，讀者們的評(píng)論可謂魚龍混雜、荒誕與睿智交融。但必須承認(rèn)，我們確實(shí)能從中提煉出構(gòu)建微服務(wù)架構(gòu)時(shí)的幾種常見錯(cuò)誤。首先需要明確一點(diǎn)：構(gòu)建分布式系統(tǒng)確實(shí)相當(dāng)復(fù)雜。當(dāng)然，單體式系統(tǒng)的構(gòu)建也不簡(jiǎn)單。但二者的區(qū)別在于，分布式系統(tǒng)的復(fù)雜度有很大的空間，而很多人的實(shí)施方案在毫無必要的情況下拉升了復(fù)雜水平。任何有經(jīng)驗(yàn)的開發(fā)者或者架構(gòu)師都認(rèn)為，大多數(shù)人實(shí)際并不需要全盤接納微服務(wù)。所以接下來要討論的重點(diǎn)，就只針對(duì)那些確實(shí)有必要采用微服務(wù)架構(gòu)的場(chǎng)景。
另外，我們的團(tuán)隊(duì)在嘗試微服務(wù)方面確實(shí)起步較早，而且?guī)缀醢涯芊傅腻e(cuò)誤都犯了個(gè)遍。下面我就來聊聊我們自己當(dāng)年吃過的那些虧。

1. 定制化構(gòu)建太多

微服務(wù)架構(gòu)中各服務(wù)間的通信往往正是麻煩的來源。有人認(rèn)為之所以讓人頭痛，是因?yàn)槭聞?wù)也被系統(tǒng)架構(gòu)給硬生生“分布”掉了。以典型的電子商務(wù)應(yīng)用為例，微服務(wù)架構(gòu)下的新訂單創(chuàng)建流程可能需要在多項(xiàng)不同服務(wù)之間進(jìn)行操作，例如訂單與客戶服務(wù)。而在單體式應(yīng)用中，創(chuàng)建新訂單就只需要調(diào)用一個(gè)函數(shù)。大家當(dāng)然可以用saga來處理多服務(wù)事務(wù)，但saga本身的實(shí)現(xiàn)難度也同樣不低。
但我們確實(shí)沒找到更好的辦法，于是我們選擇基于編排的saga解決這個(gè)難題。這種方法的優(yōu)勢(shì)，是讓我們以定制化方式在各服務(wù)中使用消息代理實(shí)現(xiàn)saga的通信與執(zhí)行。接下來，使用Redis流與Go語言構(gòu)建之后，最終產(chǎn)出的成果相當(dāng)整潔、整個(gè)實(shí)現(xiàn)過程也充滿趣味。但事后來看，我們當(dāng)初就不該用微服務(wù)架構(gòu)，這類應(yīng)用完全就是單體式架構(gòu)的理想場(chǎng)景。

2. 復(fù)雜性失控

這個(gè)問題的實(shí)質(zhì)在于經(jīng)驗(yàn)：從技術(shù)上講，有些路線壓根就沒必要嘗試，因?yàn)槊黠@跟項(xiàng)目時(shí)間表和當(dāng)前團(tuán)隊(duì)的技術(shù)水平相沖突。如果意識(shí)不到這一點(diǎn)，或者說誤以為微服務(wù)是萬能的，那麻煩緊跟著就來了。
請(qǐng)?jiān)试S我強(qiáng)調(diào)一點(diǎn)：?jiǎn)螁卧赮ouTube講座里聽得熱鬧，并不代表那些解決方案就能在我們自己的項(xiàng)目中順利起效。所以最好能預(yù)先給能夠承受的復(fù)雜度設(shè)置明確的上限，這樣能給大家省下大量寶貴時(shí)間。換個(gè)角度說，這類問題也可能源自“我們留的時(shí)間太多了”——如果項(xiàng)目的截止日期更緊，沒準(zhǔn)就不會(huì)瞎折騰什么微服務(wù)架構(gòu)了。
這里同樣需要認(rèn)真權(quán)衡——如果把復(fù)雜度設(shè)置得太低，那我們最終拼湊出來的就是一架由筷子組成的飛機(jī)；但如果復(fù)雜度被定義得過高，那我們的飛機(jī)永遠(yuǎn)也沒機(jī)會(huì)離開跑道。無論哪種情況，都不是我們希望見到的。所以大家最好能先把項(xiàng)目要求整理明確，然后發(fā)布在Medium上進(jìn)行求助，聰明的工程師們肯定會(huì)給你一些靠譜的建議。

3. 定義過于松散

最后，別指望一套方案就能解決我們的大部分問題。歸根結(jié)底，分布式架構(gòu)的出現(xiàn)就是為了解決一個(gè)特定問題。所以在決定使用之前，先弄清楚分布式適合解決什么問題、您自己面對(duì)的是什么問題，二者之間到底匹不匹配。但那時(shí)候，我自己的團(tuán)隊(duì)這幾點(diǎn)都沒做到。畢竟，誰會(huì)在起步階段就花幾天時(shí)間明確定義問題？能這么干的團(tuán)隊(duì)太少見了，大多數(shù)人都習(xí)慣于先干再說。現(xiàn)在，我們意識(shí)到正確定義問題能讓自己少走彎路、反而節(jié)約了時(shí)間。正所謂磨刀不誤砍柴工，先把要解決的問題搞清楚真的非常重要。
很遺憾，那時(shí)候我們自己沒能做到。我們的探索不僅白白浪費(fèi)了時(shí)間和金錢，而且沒能得到任何有意義的產(chǎn)出。我們構(gòu)建了不少后來壓根用不上的東西，現(xiàn)在想想倒不如拿這段時(shí)間給大家放個(gè)假，至少還能提振一下士氣。總之，先明確問題、再跟預(yù)期中的解決方案進(jìn)行比對(duì)，這很重要。
如果一意孤行，結(jié)果就會(huì)像我這樣——浪費(fèi)大量時(shí)間開發(fā)了一堆垃圾，再把其中的血淚教訓(xùn)總結(jié)成文章發(fā)在這里供大家一樂。好在我們沒把自己折騰死，所以各位才有機(jī)會(huì)讀到這篇文章。要警惕啊，同志們！
原文鏈接：https://medium.com/codex/the-biggest-mistakes-we-made-building-microservices-10b555d80dae