拼多多APP上線本地生活入口，群雄逐鹿萬億市場
Tech星球（微信ID：tech618）文 | 陳橋輝 Tech星球獨家獲悉，拼多多在其APP內上線了“本地生活”入口，位置較深，位于首頁的“充值中心”內，目前主要售賣美食相關的
大家好，我是君哥。
前段時間滴滴的故障相信大家都知道了。中斷業務 12 小時定級為 P0 級故障一點都不冤。
圖片
網上有傳言是運維人員升級 k8s 時，本來計劃是從 1.12 版本升級到 1.20，但是操作失誤選錯了版本，操作了集群降級到低版本。
從下面滴滴技術的博客中也可以看到滴滴的升級方案：
圖片
滴滴為了降低升級成本，選擇了原地升級的方式。首先升級 master，然后升級 node。我們一起看一下 k8s 官方架構：
圖片
master(官網圖中叫 CONTROL PLANE) 節點由 3 個重要的組件組成:
Node 節點向 kube-api-server 注冊成功后，才可以運行 Pod。從滴滴的博客中可以看到，采用原地升級的方式，升級了 master 之后，逐步升級 Node，Node 會有一個重新注冊的過程，不過既然選擇這個方案，運維人員應該反復演練過，重新注冊耗時應該非常短，用戶無感知。
但是 master 選錯版本發生降級時，會把 kube-api-server 污染，Node 節點注冊 master 失敗，又不能快速回滾，這樣 Node 節點被集群認為是非健康節點，上面的 pod 被 kill 掉，服務停止。
圖片
這次故障大家討論的話題還有一個比較熱門的就是 k8s 集群隔離，因為多個業務比如打車業務、單車業務同時掛，說明都在一個集群上，沒有單獨建集群來做隔離，這可能也是博客中說的“最大集群規模已經遠遠超出了社區推薦的5千個 node 上限”的原因。
當然也有可能當時野蠻生長的時候，為了快速上線開展業務，就多個業務建在了一個集群上，后來可能也有過拆分的想法，但發現業務上升空間已經很小，現有集群可以維持，所以就擱置了。
拆分成多個集群好處很明顯，業務隔離，故障隔離，可靠性增加，就拿這次升級來說，先升級一個不太關鍵、業務量也比較小的集群做試點，升級成功了再逐個升級其他集群。
但缺點也很明顯，運維復雜度增加，成本增加。
工作這些年，也參與過一些大規模的平臺重構，但原地升級真的是沒有接觸過，主要原因就是架構師們不太愿意選擇原地升級的方案。而他們主要出于下面考慮：
對于滴滴這樣的大公司，相信運維團隊大咖如云，無論采用哪種方案，肯定都是經過反復驗證的，或許不要選錯版本，原地升級也沒有問題。
看了微博上滴滴道歉的留言區，好多人猜測這次事故的原因是降本增效，裁掉了一線高成本的運維，保留了成本低的新人。
從數據上來看，出于降本增效的目的，滴滴這兩年確實少了很多人，但我不相信這是造成事故的直接原因。
在快速增長的階段，確實需要投入大量的技術人員來建設系統。但國內互聯網規模也基本見頂了，一個業務經營這么多年，不會再有爆發式地增長，系統也已經非常穩定。這樣的背景下，公司確實用不了這么多技術人員了，留下部分人員來維護就夠了。
所以，無論哪家公司，降本增效是業務穩定后必定會經歷的階段。想想滴滴這次 12 小時故障的損失，能比養 1000 個技術人員的成本高嗎？
對于我們研發人員，如果有機會進入快速增長的公司，那就抓住機會多掙錢，被裁員的時候平常心看待就可以了，想在一家公司干到退休太難了。同時也要看到自己給公司帶來的價值，千萬不要認為我們技術厲害就比那個 PPT 工程師更有價值。
本文根據網上流傳的滴滴故障的原因，分析了升級方案和降本增效。最后，又快年末了，希望大家都能維護好自己的系統，不要發生嚴重故障影響自己的年底考核。
本文鏈接：http://www.tebozhan.com/showinfo-26-38111-0.html一次 K8s 升級，竟然導致滴滴故障 12 小時？
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： 源碼解密協程隊列和線程隊列的實現原理
下一篇： 優雅地統一處理接口返回值的最佳實踐
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號