構(gòu)建微服務(wù)時的三大常見錯誤程序員面試吧關(guān)注共 1798字，需瀏覽 4分鐘 ·2021-11-08 20:54 想在網(wǎng)上挨罵，最簡單的方法就是寫點關(guān)于微服務(wù)架構(gòu)的東西。每個人對微服務(wù)都有自己的一套見解；無論我們是贊揚(yáng)還是批評，總會有人跳出來強(qiáng)調(diào)“你錯了”。行吧，這畢竟是個遍地懂王的時代，挨噴實屬難免。我最近也寫了幾篇關(guān)于微服務(wù)的熱鬧文章，讀者們的評論可謂魚龍混雜、荒誕與睿智交融。但必須承認(rèn)，我們確實能從中提煉出構(gòu)建微服務(wù)架構(gòu)時的幾種常見錯誤。首先需要明確一點：構(gòu)建分布式系統(tǒng)確實相當(dāng)復(fù)雜。當(dāng)然，單體式系統(tǒng)的構(gòu)建也不簡單。但二者的區(qū)別在于，分布式系統(tǒng)的復(fù)雜度有很大的空間，而很多人的實施方案在毫無必要的情況下拉升了復(fù)雜水平。任何有經(jīng)驗的開發(fā)者或者架構(gòu)師都認(rèn)為，大多數(shù)人實際并不需要全盤接納微服務(wù)。所以接下來要討論的重點，就只針對那些確實有必要采用微服務(wù)架構(gòu)的場景。另外，我們的團(tuán)隊在嘗試微服務(wù)方面確實起步較早，而且?guī)缀醢涯芊傅腻e誤都犯了個遍。下面我就來聊聊我們自己當(dāng)年吃過的那些虧。1. 定制化構(gòu)建太多微服務(wù)架構(gòu)中各服務(wù)間的通信往往正是麻煩的來源。有人認(rèn)為之所以讓人頭痛，是因為事務(wù)也被系統(tǒng)架構(gòu)給硬生生“分布”掉了。以典型的電子商務(wù)應(yīng)用為例，微服務(wù)架構(gòu)下的新訂單創(chuàng)建流程可能需要在多項不同服務(wù)之間進(jìn)行操作，例如訂單與客戶服務(wù)。而在單體式應(yīng)用中，創(chuàng)建新訂單就只需要調(diào)用一個函數(shù)。大家當(dāng)然可以用saga來處理多服務(wù)事務(wù)，但saga本身的實現(xiàn)難度也同樣不低。但我們確實沒找到更好的辦法，于是我們選擇基于編排的saga解決這個難題。這種方法的優(yōu)勢，是讓我們以定制化方式在各服務(wù)中使用消息代理實現(xiàn)saga的通信與執(zhí)行。接下來，使用Redis流與Go語言構(gòu)建之后，最終產(chǎn)出的成果相當(dāng)整潔、整個實現(xiàn)過程也充滿趣味。但事后來看，我們當(dāng)初就不該用微服務(wù)架構(gòu)，這類應(yīng)用完全就是單體式架構(gòu)的理想場景。2. 復(fù)雜性失控這個問題的實質(zhì)在于經(jīng)驗：從技術(shù)上講，有些路線壓根就沒必要嘗試，因為明顯跟項目時間表和當(dāng)前團(tuán)隊的技術(shù)水平相沖突。如果意識不到這一點，或者說誤以為微服務(wù)是萬能的，那麻煩緊跟著就來了。請允許我強(qiáng)調(diào)一點：單單在YouTube講座里聽得熱鬧，并不代表那些解決方案就能在我們自己的項目中順利起效。所以最好能預(yù)先給能夠承受的復(fù)雜度設(shè)置明確的上限，這樣能給大家省下大量寶貴時間。換個角度說，這類問題也可能源自“我們留的時間太多了”——如果項目的截止日期更緊，沒準(zhǔn)就不會瞎折騰什么微服務(wù)架構(gòu)了。這里同樣需要認(rèn)真權(quán)衡——如果把復(fù)雜度設(shè)置得太低，那我們最終拼湊出來的就是一架由筷子組成的飛機(jī)；但如果復(fù)雜度被定義得過高，那我們的飛機(jī)永遠(yuǎn)也沒機(jī)會離開跑道。無論哪種情況，都不是我們希望見到的。所以大家最好能先把項目要求整理明確，然后發(fā)布在Medium上進(jìn)行求助，聰明的工程師們肯定會給你一些靠譜的建議。3. 定義過于松散最后，別指望一套方案就能解決我們的大部分問題。歸根結(jié)底，分布式架構(gòu)的出現(xiàn)就是為了解決一個特定問題。所以在決定使用之前，先弄清楚分布式適合解決什么問題、您自己面對的是什么問題，二者之間到底匹不匹配。但那時候，我自己的團(tuán)隊這幾點都沒做到。畢竟，誰會在起步階段就花幾天時間明確定義問題？能這么干的團(tuán)隊太少見了，大多數(shù)人都習(xí)慣于先干再說。現(xiàn)在，我們意識到正確定義問題能讓自己少走彎路、反而節(jié)約了時間。正所謂磨刀不誤砍柴工，先把要解決的問題搞清楚真的非常重要。很遺憾，那時候我們自己沒能做到。我們的探索不僅白白浪費(fèi)了時間和金錢，而且沒能得到任何有意義的產(chǎn)出。我們構(gòu)建了不少后來壓根用不上的東西，現(xiàn)在想想倒不如拿這段時間給大家放個假，至少還能提振一下士氣。總之，先明確問題、再跟預(yù)期中的解決方案進(jìn)行比對，這很重要。如果一意孤行，結(jié)果就會像我這樣——浪費(fèi)大量時間開發(fā)了一堆垃圾，再把其中的血淚教訓(xùn)總結(jié)成文章發(fā)在這里供大家一樂。好在我們沒把自己折騰死，所以各位才有機(jī)會讀到這篇文章。要警惕啊，同志們！原文鏈接：https://medium.com/codex/the-biggest-mistakes-we-made-building-microservices-10b555d80dae 瀏覽 51點贊 評論 收藏 分享 手機(jī)掃一掃分享分享 舉報 評論圖片表情視頻評價全部評論推薦 我們在構(gòu)建微服務(wù)時犯過的最大錯誤服務(wù)端思維0使用PyTorch時，最常見的4個錯誤小白學(xué)視覺0使用PyTorch時，最常見的4個錯誤極市平臺0使用PyTorch時，最常見的4個錯誤AI算法與圖像處理05 個使用 Promise 時的常見錯誤web前端開發(fā)0選擇項目管理軟件時應(yīng)避免的三大錯誤市場上有各種各樣的項目管理軟件。 但是，有許多競爭解決方案可供選擇，這會造成混亂，并使項目經(jīng)理和業(yè)務(wù)專業(yè)人員感到不知所措。選擇錯誤的軟件程序會導(dǎo)致一系列問題，例如減少通信流，報告，賬單和整體生產(chǎn)率。基本上，選擇錯誤的項目管理軟件會增加犯下更大的，無法預(yù)料的錯誤的風(fēng)險，從而使您的公司蒙受損失。 正確的軟件選擇很重要，可以從避免一些太常見的錯誤開始。如果您希望避免因選擇不適合您的需求而導(dǎo)致的與選擇項目管理軟件相關(guān)的錯誤，那么下面的信息會有所幫助。 錯誤1：無法檢查您的業(yè)務(wù)流程并將其與軟件產(chǎn)品相匹配 就像任何類型的選擇項目一樣，首先要弄清楚您的需求是值得的。必須考慮項目是如何在公司內(nèi)部形成的，包括通常涉及哪些團(tuán)隊以及他們需要什么以Go 使用 interface 時的 7 個常見錯誤寫在正文之前閱讀本文之前我們來先熟悉以下的代碼原則，如果你已經(jīng)很熟悉這些內(nèi)容，可以直接跳到正文。接口隔離原則：絕不能強(qiáng)迫客戶實現(xiàn)其不使用的接口，也不能強(qiáng)迫客戶依賴其不使用的方法。多態(tài)性：代碼變化會根據(jù)接收到的具體數(shù)據(jù)改變其行為。里氏替換原則：如果你的代碼依賴于一個抽象概念，那么一個實現(xiàn)可以被另一個實springcloud微服務(wù)架構(gòu)開發(fā)實戰(zhàn)：常見微服務(wù)的消費(fèi)者愿天堂沒有BUG0五個常見的Django錯誤馬哥Linux運(yùn)維0幾個常見的 slice 錯誤最近看到 medium 上有篇文章[1]把關(guān)于 slice 的常見錯誤總結(jié)出來了，有些甚至是老司機(jī)也容易犯的。每個錯誤都先描述問題，再給出修改建議，最后再展示一個代碼樣例。之前饒大寫過一篇關(guān)于 slice 的文章《深度解密 Go...點贊 評論 收藏 分享 手機(jī)掃一掃分享分享 舉報
下載APP下載APP