讀《微服務架構設計模式》的感悟(2)

畢生狼 2021-08-15 21:29:51 阅读数:888

本文一共[544]字,预计阅读时长:1分钟~
微服 模式 感悟

書接前文,這篇會先講一下,我理解的微服務的最大優點。

最近總聽幾個在to B公司工作的產研朋友說,他們的研發團隊已經有了幾百人,但他們研發這塊還總是拖業務後腿,上線delay是家常便飯,所以一方面感覺還是缺人,在大量招人,另一方面感覺系統架構太爛太老了,迭代不動了。

這種情况,把我說得一愣一愣的,因為我這幾年的觀點一直是,現在的技術解决方案已經做得足够健全,信息化也做得足够好,各種雲生態做得也是更加完善,技術門檻已經低得不要不要的了。

詳細了解了一下,才知道,他們這些公司的研發團隊,之前在業務簡單,工程師人數比較少的時候,一直在用純單體應用,或者是SOA這樣較大的單體應用,系統架構就一直沒有動。

等到業務複雜度上來了,工程師人數也上來的時候,就開始面臨幾十個人改一個服務,各種代碼互相篡改,代碼合並的時候,各種各樣的代碼沖突,怎麼也合並不成功,費了好大的勁,耽誤了好長時間,終於合並成功了。但麻煩的還在後面,等到QA介入測試,發現各種代碼的業務邏輯相互影響,bug如同雨後春笋般的被提了過來,然後開始繼續改bug來互相傷害,但是bug短時間內根本沒有收斂的趨勢。工程師們加班加點、不眠不休、痛苦不堪地熬著,最後,最後,終於上線了,但已經延期了很久。已然是紅了櫻桃,綠了芭蕉,姑娘變成了少婦,兒子都有一米高。

事後技術負責人帶著團隊進行複盤的時候,大家達成的結論是——缺人。

其實真正的原因並不是缺人,而是,工程師數量上來了,但遠沒有達到1+1=2的效果。 這種場景有點像10個人擠在一個幾平米的家庭廚房裏面一起洗菜做飯一樣,它的效率未必比配合嫻熟的兩個人快多少。

因此,真正的問題原因是,沒有在一個適當的時機,把一個龐大的單體應用,演進為微服務架構。那麼我認為,相比於單體應用,微服務的最大優點是——使工程師團隊的工作情况從“並發”變成了“並行”,從而保證團隊研發效率盡可能小的發生損耗,讓研發團隊具備橫向擴容去縮短研發周期的能力。

平均每研發人員單比特時間釋放出的產品能力,即“研發效率”。那麼按照這種定義,工程師效率最高的時候,應該是一個人開發一個單體應用的時候。不需要輸出任何文檔進行接口約定,不需要跟其他工程師進行思路和技術方案的對齊,沒有業務代碼的相互影響,也不需要解决代碼合並的沖突,沒有跨服務進行聯調和問題排查,測試環境的搭建部署變得very easy,上線過程也是分分鐘的事情。這種情况下,雖然人效高了,但研發周期太長了,上線一個大的功能,以月為維度進行排期,是任何唯快不破的互聯網公司都接受不了的。而我們給研發團隊加人,是希望盡量縮短研發周期,進行架構上的微服務拆分,則是為了讓團隊的研發效率盡量小的發生損耗。畢竟工程師還是很貴的,如果人海戰術的ROI不高,導致產研成本居高不下,是絕大多數公司都承受不住的。


書中所列,微服務的其他優點:

微服務架構可以實現團隊的自治

微服務本身就是一種去中心化的理念,而一旦去中心化了,那就必須實現區域自治。其中包括:技術語言自治、技術選型自治、數據結構自治、上線部署自治等,這樣,工程師可以用自己最熟悉和擅長的方式進行工作。

服務可以獨立擴展

書中提出了一個擴展立方體的概念,即三維可擴展模型:

圖片

X軸擴展:無腦擴容服務器

Y軸擴展:按照功能進行服務拆分

Z軸擴展:在無腦擴容服務器的基礎上,再通過路由字段(如:userId)决定走到哪個實例上\

此外,無論是哪種維度的擴展,微服務因為足够小,足够內聚,我們都可以去有針對性地選擇適合的硬件去解决系統中的瓶頸。如:計算密集型的服務,可以增加CPU的核數提昇並行能力;IO密集型的服務,我們可以把微服務對應的存儲提昇硬件配置;如果服務比較吃內存,可以選擇高內存配置的服務器。

每個服務都相對較小並容易維護

微服務的代碼量少,工程師能够更關注和聚焦自己所負責的業務功能需求,這樣更容易理解和維護。但這同樣是有硬幣的兩面性的,比如:作為上遊服務,下遊服務的業務邏輯和存儲數據結構,對我們是透明的;作為下遊服務,上遊服務在什麼業務場景下調用了我們,又是如何和其他數據進行聚合展示的,對我們一樣是透明的;還有就是,我們的整體系統,還有多少個跟我們一樣的微服務,他們的運轉機制是什麼樣的,我們也知道得不多。就跟拼圖遊戲一樣,切得越碎,越難拼出整幅圖。那麼一旦我們的需求是需要對周邊系統有一些了解才能做完整技術方案和實現,我們想了解系統整體的完整運轉機制和業務邏輯,就會變得更加困難。


微服務能够提昇性能嗎?

同事之間對這個問題,似乎爭論頗多,且最終誰也沒能說服誰。

我的觀點是:具體case具體分析,但從通例的角度來說,微服務不能提昇性能,反而性能會略有降低。

有人說,微服務拆分的時候,按照微服務的規範,把服務所屬的數據庫也各自拆分了,然後性能瓶頸就沒有了,接口的平均響應時間也上去了。

但我覺得,這件事情的本質是,你的存儲擴容了導致了性能提昇,有本事你把這些拆分的庫錶還放在一個物理機上試試。

我們換個角度來看微服務,其實就是從以前的調用一個服務變成了多個服務來完成業務結果,從以前的本地調用變成了遠程調用而已。


微服務能够提昇系統可用性嗎?

毫無疑問,微服務可以具備更好的容錯性,但是,微服務能够提昇可用性嗎?

這是個非常燒腦的問題,因為維度太多,且標准也不太統一。在下一篇,我試試能否把這個問題給大家解釋清楚,順便聊下書中所說的,微服務的缺點。

未央。

版权声明:本文为[畢生狼]所创,转载请带上原文链接,感谢。 https://gsmany.com/2021/08/20210815212946417r.html