構建微服務時的三大常見錯誤
** 來自：分佈式實驗室 公衆號，作者：解博**
想在網上捱罵，最簡單的方法就是寫點關於微服務架構的東西。每個人對微服務都有自己的一套見解；無論我們是讚揚還是批評，總會有人跳出來強調 “你錯了”。行吧，這畢竟是個遍地懂王的時代，挨噴實屬難免。我最近也寫了幾篇關於微服務的熱鬧文章，讀者們的評論可謂魚龍混雜、荒誕與睿智交融。但必須承認，我們確實能從中提煉出構建微服務架構時的幾種常見錯誤。首先需要明確一點：構建分佈式系統確實相當複雜。當然，單體式系統的構建也不簡單。但二者的區別在於，分佈式系統的複雜度有很大的空間，而很多人的實施方案在毫無必要的情況下拉昇了複雜水平。任何有經驗的開發者或者架構師都認爲，大多數人實際並不需要全盤接納微服務。所以接下來要討論的重點，就只針對那些確實有必要採用微服務架構的場景。
另外，我們的團隊在嘗試微服務方面確實起步較早，而且幾乎把能犯的錯誤都犯了個遍。下面我就來聊聊我們自己當年喫過的那些虧。
- 定製化構建太多
微服務架構中各服務間的通信往往正是麻煩的來源。有人認爲之所以讓人頭痛，是因爲事務也被系統架構給硬生生 “分佈” 掉了。以典型的電子商務應用爲例，微服務架構下的新訂單創建流程可能需要在多項不同服務之間進行操作，例如訂單與客戶服務。而在單體式應用中，創建新訂單就只需要調用一個函數。大家當然可以用 saga 來處理多服務事務，但 saga 本身的實現難度也同樣不低。
但我們確實沒找到更好的辦法，於是我們選擇基於編排的 saga 解決這個難題。這種方法的優勢，是讓我們以定製化方式在各服務中使用消息代理實現 saga 的通信與執行。接下來，使用 Redis 流與 Go 語言構建之後，最終產出的成果相當整潔、整個實現過程也充滿趣味。但事後來看，我們當初就不該用微服務架構，這類應用完全就是單體式架構的理想場景。
- 複雜性失控
這個問題的實質在於經驗：從技術上講，有些路線壓根就沒必要嘗試，因爲明顯跟項目時間表和當前團隊的技術水平相沖突。如果意識不到這一點，或者說誤以爲微服務是萬能的，那麻煩緊跟着就來了。
請允許我強調一點：單單在 YouTube 講座裏聽得熱鬧，並不代表那些解決方案就能在我們自己的項目中順利起效。所以最好能預先給能夠承受的複雜度設置明確的上限，這樣能給大家省下大量寶貴時間。換個角度說，這類問題也可能源自 “我們留的時間太多了”——如果項目的截止日期更緊，沒準就不會瞎折騰什麼微服務架構了。
這裏同樣需要認真權衡——如果把複雜度設置得太低，那我們最終拼湊出來的就是一架由筷子組成的飛機；但如果複雜度被定義得過高，那我們的飛機永遠也沒機會離開跑道。無論哪種情況，都不是我們希望見到的。所以大家最好能先把項目要求整理明確，然後發佈在 Medium 上進行求助，聰明的工程師們肯定會給你一些靠譜的建議。
- 定義過於鬆散
最後，別指望一套方案就能解決我們的大部分問題。歸根結底，分佈式架構的出現就是爲了解決一個特定問題。所以在決定使用之前，先弄清楚分佈式適合解決什麼問題、您自己面對的是什麼問題，二者之間到底匹不匹配。但那時候，我自己的團隊這幾點都沒做到。畢竟，誰會在起步階段就花幾天時間明確定義問題？能這麼幹的團隊太少見了，大多數人都習慣於先幹再說。現在，我們意識到正確定義問題能讓自己少走彎路、反而節約了時間。正所謂磨刀不誤砍柴工，先把要解決的問題搞清楚真的非常重要。
很遺憾，那時候我們自己沒能做到。我們的探索不僅白白浪費了時間和金錢，而且沒能得到任何有意義的產出。我們構建了不少後來壓根用不上的東西，現在想想倒不如拿這段時間給大家放個假，至少還能提振一下士氣。總之，先明確問題、再跟預期中的解決方案進行比對，這很重要。
如果一意孤行，結果就會像我這樣——浪費大量時間開發了一堆垃圾，再把其中的血淚教訓總結成文章發在這裏供大家一樂。好在我們沒把自己折騰死，所以各位纔有機會讀到這篇文章。要警惕啊，同志們！
原文鏈接：https://medium.com/codex/the-biggest-mistakes-we-made-building-microservices-10b555d80dae
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/pCdLnK6xp7P0CoR3yE_Dng