? 來自：分布式實驗室 公眾號，作者：解博

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

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

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

2. 復雜性失控

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

3. 定義過于松散

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