RT。

這裡的前端包括(h5 android ios)

當一個app推向市場時，

第一個階段

用戶比較少，前端後端的壓力一樣大。此時的重點在於把功能實現

伺服器可能只有1台 (單機架構)

第二個階段

公司開始通過一些渠道推廣app，

運營人員通過一些活動開始拉新，

每一天的註冊量都上萬，

日活慢慢的開始飆升，伺服器壓力變大，測試反饋說，app好像微微的有點卡。

考慮到後續的流量發展，後端老大，加了4伺服器(假設配置都一樣)，現在一共有5台

第三個階段

運營持續發力，產品功能繼續迭代，

新用戶越來越多，老用戶持續活躍，

日活慢慢靠近5萬

某天深夜，app掛了，打開任何一個頁面都空白一片，500 504頻繁出現。

監控系統，不停報警，老闆震怒，電話把技術部老大罵一頓，催促趕緊解決，

技術部老大，把核心後端叫醒，討論解決方案，

最快的解決方案是，先加機器，扛過今晚再說。

前端睡的很香，第二天醒來聽說app昨晚掛了

開始分析日誌和監控系統，昨晚流量高峰時，

發現mysql連接數耗盡，單機的扛不住，在調整了一些系統參數和mysql參數後，壓測，發現還是扛不住，升級資料庫架構，單機器升級為一主一從，把讀寫進行分離。

為了保證mysql的穩定性，又加了一個連接池。

第四個階段，

五十萬日活

cdn，

緩存系統，

集群架構升級當分散式架構

分散式再升級到微服務架構

用戶看不見的系統越搞越多，

比如

日誌系統

請求鏈路追蹤

隊列任務中心

網關係統

配置中心

等等，

中間件越用越多，

數據量越來越大，

慢慢的有了大數據崗位。

說的不夠細緻，總的來說，

當流量越來越大時，前端可優化的地方並不多。

介面還是那個介面，單日活1萬，和日活50萬

後端系統的複雜度，不可同日而語。

事實很內卷，faas/baas 是趨勢，後端必然要往集群化，集中化，資源化發展，後端不去研究devops，微服務，呆在中間件賴著不走，被噴也正常。

前端吐槽後端簡單，大概率是想把後端從中間件趕走，受不了奇葩的數據格式和聯調時的加班了。

不過還是少點內卷好，這麼搞的目的不就是讓資本家有更多用戶，少點風險么？都是打工的，那有什麼矛盾。

因為前端說的沒錯，80%以上的後端工作本身就很簡單，就是ifelse+curd。這些寫後端的天天都覺得從tcp協議棧，到操作系統，到文件系統，到數據結構演算法，到數據持久化，到分散式處理，到消息中間件，到一致性緩存，到負載均衡，到編程語言特性，到編譯原理，到cpu流水，到千萬並發，到秒百萬message等等等，巨龐大的知識鏈自己沒有哪一個不清楚不通曉？……但實際上呢？乾的不過是select * from t to json send to kafka，或者get header,body,formvalue from request do some bug and wrtite to response。 天天拿著人大神寫基礎組件的難度往自己臉上貼金而已。…當然前端也不例外，80%的工作也就V,A.R三架馬車捎帶上js,html,css三板斧外帶會github搜搜組件就完事。難嗎？形容難度感覺人人都在寫瀏覽器寫vsc實現js標準造方言似的…寫代碼壓根兒就不是個什麼難事，難得是把一坨屎一樣的產品設計做成成品上線，期間後端通過架構解決一年內拉的屎的兼容和性能問題，前端解決要求一坨屎和另一坨屎形狀要一樣但是又不能一樣的問題，從這點上來說，前端和後端真的都很難。……

我是個後端，我就覺得前端好難，反正我是學不會。

——前端渣渣 死月

軟體開發有幾條亘古不變的原則：模塊化、松耦合、封裝底層、向上層透明。

前後端分離就是上面這些原則驅動下的結果。前後端松耦合，沒有任何代碼層面的關聯，只有HTTP網路協議上的通信。後端封裝自己的業務邏輯，只給前端暴露出API來，讓前端透明調用。

正因為前端看到的只是API，並不會看到封裝在內部的複雜業務邏輯。所以就覺得簡單。

同樣，很多人也會覺得前端簡單。因為前端也只暴露出自己的介面(GUI，圖形用戶介面)，也封裝了很多複雜的交互邏輯。所以很多人就認為前端不就是做個網頁嗎。

同理，有人覺得製造CPU晶元也簡單。因為這些東西封裝的太好了，對他們來說太透明了，根本感覺不到存在。

推薦閱讀：
相关文章