如何通俗地理解「分佈式系統」;Vue是否可以在一個項目中使用多個UI框架;大廠上線流程:先上前端還是後端|極客觀點

語言: CN / TW / HK

#極客觀點 聚焦於技術方向、程序員職業發展、個人成長等主題,致力於發起有價值的討論,輸出有價值的觀點。

在本欄目中,我們將為大家推薦在 #極客觀點 版塊被熱烈討論的話題,甄選出有趣的觀點為你呈現。期待我們一起成長和進步呀 🥰🥰

今日關鍵詞:#分佈式系統 #UI 框架 #大廠上線流程

如何通俗地理解「分佈式系統」?

話題發起人:Alluxio

如何通俗地理解「分佈式系統」,它解決了哪些問題,有什麼優缺點?

有趣的觀點:

關於“分佈式系統”的定義,《分佈式系統原理和範型》一書中是這樣定義分佈式系統的:“分佈式系統是若干獨立計算機的集合,這些計算機對於用户來説就像是單個相關係統”。關於這個定義,我們直觀的感受就是:首先,這種系統相對來説比較牛逼,起碼由好幾台主機組成。以谷歌、亞馬遜等服務商而言,他們的數據中心都由上萬台主機支撐起來的。其次,雖然很牛逼,但對於外人來説,是感覺不到這些主機的存在。也就是説,我們只看到是一個系統在運作。

"宕機事件"為例,平時,我們壓根不知道所提供的服務背後是由多少台主機組成,但是等到宕機才知道,是多麼嚴重的事故。從進程角度看,兩個程序分別運行在兩個台主機的進程上,它們相互協作最終完成同一個服務(或者功能),那麼理論上這兩個程序所組成的系統,也可以稱作是“分佈式系統”。當然,這個兩個程序可以是不同的程序,也可以是相同的程序。如果是相同的程序,我們又可以稱之為“集羣”。所謂集羣,就是將相同的程序,通過不斷橫向擴展,以提高服務能力的方式。“分佈式系統”和“集羣”的定義夠都簡單吧。分佈式系統有哪些優勢那麼,為啥我們要用分佈式系統?説起分佈式系統,我們就不得不説下分佈式系統的祖先——集中式系統。集中式系統跟分佈式系統是完全相反的兩個概念。集中式系統就是把所有的程序、功能都集中到一台主機上,從而往外提供服務的方式。集中式系統最容易理解了。比如,我們主機的PC電腦,或者手機,我們把各種軟件都安裝在一台機子上,當我需要什麼功能,我就從這台機子上去獲取。再比如,我們在學生時代做的課程設計或者開發時的小應用,我們把Web服務器、數據庫等都會安裝到一台電腦上。好處是,易於理解、方便維護,想要的東西我都放到了一個地方,東西好找啊。當然弊端也是顯而易見的,如果這台機子崩了,或者硬盤壞了,那相當與整個系統就奔潰了,而且如果備份也是在這個硬盤上,那相當於招了滅頂之災。

有個名言,就是“不要把雞蛋放在一個籃子裏”。對於系統而言也是如此。廠商的機子不可能永遠保證永遠不壞,我們也無法保證黑客不會來對我們的系統搞基,最為關鍵的是,我們自己無法保證自己的程序不會出bug。所以問題無法避免,錯誤也不可避免。我們只能雞蛋分散到不同的籃子裏,來減輕一鍋端的風險。這就是為什麼需要分佈式系統的原因。使用分佈式系統的另外一個理由是可擴展性。畢竟任何主機(哪怕是小型機、超級計算機)都會有性能的極限。而分佈式系統可以通過不斷擴張主機的數量以實現橫向水平性能的擴展。

————社區用户:bucai

有趣的觀點:

我自己的理解:分佈式系統能廣為人知,跟社會的發展脱不了干係,每年的網民數量在逐步遞增,隨即帶來的就是訪問量以及數據量的問題,以前的單體架構不足以滿足社會的發展,分佈式系統存在的意義就是解決這樣的事情,高併發、高可用、高、高性能,這也是常説的三高;至於優點前面已經説了,缺點的話我個人理解是取決於物理因素了,比如網絡帶寬等等,也會因為一些環境架構原因,通常最讓人頭疼的優化就是實時數據更新的問題

————社區用户:小乘字節

Vue 可以在一個項目中使用多個 UI 框架嗎?

話題發起人:mmkk_ccvv

Vue的UI框架有ElementUI, AntUI 等,可以在一個項目中使用多個UI框架嗎?

有趣的觀點:

先説明:沒問題,但是不推薦。

有幾點考慮:

全局樣式不同。會導致衝突,雖然可能很少,但是隻要出現一個,就會很煩。
站點 UI 設計通常是基於一個組件庫。多個組件的風格混合會讓呈現效果顯得格格不入,因為每套組件庫都有自己一套設計模式,組合使用效果更佳。
組件齊全。當前來説,應該不會出現組件不夠用,要去隔壁借一個用的場景,真出現了,那麼可以考慮那種,專門做一種組件的插件,會更加專業。

————社區用户:YangFong

有趣的觀點:

可以,但完全沒有必要。

首先一個UI框架打包下來,即使按需加載,再怎麼也得100K往上了。你用幾個框架,打出來的包會相當大。
不同UI框架使用的CSS預編譯不同,有些是less,有些是scss,混用會相當混亂,並且你必須安裝兩個loader。無形之中你的開發環境會變得非常臃腫。
設計語言不同,不同的UI框架遵循的設計語言和規範不同,容易出現放在一起不和諧的情況。
主題換膚功能不好做,需要統一兩個框架的換膚方式。比如Ant Design可以直接用less.js換膚,但是Quasar是scss,沒法通用。
可能引起樣式衝突。

————社區用户:Gomi

大廠上線流程:是先上前端,還是先上後端?怎麼保證平滑上線?

話題發起人:孟思行

1、如果先上前端,還沒上後端,就請求不到新的接口。
2、如果先上後端,還沒上前端,使用老接口的頁面可能會報錯。

有趣的觀點:

一般情況都是後端先上線,這樣現網對上線的感知也是最小的。畢竟前端上線之後,客户有了交互的界面,配合早已發佈的後端環境,可以流暢體驗新功能。

————社區用户:這個殺手不太冷靜

有趣的觀點:

如果是一個新項目,無所謂前後端先上後上

如果是老項目,在開發的時候,就該考慮到比如接口的兼容性了,然後後端先上線,然後前端上線。

————社區用户:冴羽

有趣的觀點:

正常情況後端->bff->前端,如果是特殊情況比如前後端沒有關聯,先後上線不影響線上功能等就可以不關注順序,想怎麼上就怎麼上。
還有一種情況就是沒有規範的小公司了,可能是線上流量不大不在乎宕機就可以不關注上線順序。

————社區用户:bucai


他們的觀點和討論是否也能帶給你啟發呢?你又有什麼有趣的觀點,希望與大家分享?

快掃描二維碼加入我們,一起交流成長吧,等你哦 🙌🙌🙌歡迎在評論區留下你的觀點呀~

本文來源:如何通俗地理解「分佈式系統」;Vue是否可以在一個項目中使用多個UI框架;大廠上線流程:先上前端還是後端|極客觀點