很多團隊都有過這樣的經(jīng)歷項目上線時風(fēng)風(fēng)光光可沒過多久系統(tǒng)開始頻繁崩潰——接口超時、數(shù)據(jù)庫連接耗盡、服務(wù)雪崩。于是加班排查、緊急擴容、重構(gòu)代碼可問題依然反復(fù)。其實很多時候不是代碼寫得差而是技術(shù)棧選型從一開始就錯了。一、盲目追新小團隊扛不起“大廠架構(gòu)”見過一個十人的創(chuàng)業(yè)團隊業(yè)務(wù)剛跑通就上了微服務(wù)全家桶Spring Cloud、Eureka、Gateway、Config、Sleuth、Kafka、Redis Cluster、Elasticsearch……結(jié)果呢注冊中心頻繁掉線配置中心同步延遲鏈路追蹤數(shù)據(jù)爆炸。運維成本遠超開發(fā)成本每次發(fā)版都像拆炸彈。大廠用這套是因為有幾百人的基礎(chǔ)架構(gòu)團隊小團隊連專職運維都沒有硬上就是自找苦吃。技術(shù)棧要匹配團隊規(guī)模和業(yè)務(wù)階段單體應(yīng)用加幾個模塊往往比微服務(wù)更穩(wěn)。二、數(shù)據(jù)層選型失誤性能瓶頸全在這里后端崩潰十有八九是數(shù)據(jù)層先垮。有人為了“高并發(fā)”選了MongoDB結(jié)果事務(wù)支持弱訂單數(shù)據(jù)對不上有人用Redis做唯一數(shù)據(jù)源宕機后數(shù)據(jù)全丟有人消息隊列選了Kafka卻用來做延遲任務(wù)堆積幾百萬條。選型時要問數(shù)據(jù)一致性要求多高讀寫比例如何需不需要事務(wù)需不需要復(fù)雜查詢MySQL加Redis緩存能解決90%的場景別為了“先進”而選NoSQL。消息隊列也一樣RabbitMQ適合業(yè)務(wù)解耦Kafka適合日志流RocketMQ適合電商事務(wù)消息選錯就是災(zāi)難。三、忽略團隊技術(shù)棧匹配度招聘和協(xié)作全是坑技術(shù)棧不是越流行越好而是團隊越熟越好。一個Java團隊聽說Go性能好硬轉(zhuǎn)Go重構(gòu)結(jié)果半年招不到人現(xiàn)有成員邊學(xué)邊寫bug率飆升。前端用React后端用Python本來沒問題但團隊沒人懂異步接口全同步阻塞并發(fā)一上來就崩。選型時要考慮現(xiàn)有成員能多快上手社區(qū)資料多不多招聘市場好不好招學(xué)習(xí)成本也是成本而且往往被低估。四、不考慮擴展性和成本云原生未必省錢Serverless、K8s、Service Mesh聽起來很美好但真用起來賬單可能嚇?biāo)廊?。某公司用AWS Lambda做核心業(yè)務(wù)流量一上來冷啟動延遲高費用暴漲最后又遷回EC2。K8s確實強大但如果沒有專職SRE光是網(wǎng)絡(luò)插件、存儲、監(jiān)控就能折騰幾個月。選型要算總賬開發(fā)效率、運維成本、云資源費用、故障恢復(fù)時間。有時候一臺大內(nèi)存服務(wù)器加Nginx比一堆容器更穩(wěn)更便宜。五、選型后不壓測、不演練等于沒選很多團隊選完技術(shù)棧就埋頭寫代碼從不做容量規(guī)劃。上線前不壓測不知道QPS上限不做故障演練不知道數(shù)據(jù)庫主從切換要多久。結(jié)果一到大促系統(tǒng)直接崩。選型不是一錘子買賣要配套壓測方案、監(jiān)控告警、降級預(yù)案。比如Redis集群模式下要測節(jié)點故障時客戶端表現(xiàn)消息隊列要測積壓時消費能力。沒有驗證的選型都是紙上談兵。怎么選才靠譜記住五個原則業(yè)務(wù)驅(qū)動別為技術(shù)而技術(shù)團隊熟悉優(yōu)先學(xué)習(xí)成本要可控簡單優(yōu)先能單體不微服務(wù)能MySQL不NoSQL可演進留好退路別鎖死成本可控算清人力和云資源。技術(shù)棧沒有銀彈適合的才是最好的。下次系統(tǒng)再崩先別急著改代碼回頭看看選型可能病根就在那里。