如何通俗地理解「分散式系統」；Vue是否可以在一個專案中使用多個UI框架；大廠上線流程：先上前端還是後端｜極客觀點

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

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

今日關鍵詞：#分散式系統 #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框架；大廠上線流程：先上前端還是後端｜極客觀點