藍圖系列（一）：高並發、高可用、高性能、分散式系統架構

05-01

做後端系統的，最喜歡做題目中的事情——聽起來就很有挑戰性呢：）

去聽過一些技術論壇，經驗分享會什麼的，扯的也是這些問題。

更重要的是，去面阿里的系統事業部，二面的時候被打回來，理由就是我不懂題目中的這些問題。當我反問面試官他問我的問題時，他是這樣說的：「就像醫生不可能對一個門診患者詳細解釋病因、發病機制、檢查結果判讀、鑒別診斷之類的一樣，你一個學醫的應該知道，我不可能給你講，講上一天都講不完」，「你學習能力不是強嗎？你先學習學習，找個正經的互聯網公司干兩年，再來投我們」。我當時特別的火，現在已經過去好多天想起來也還是特別火。不論本來就在阿里干後端以為高人一等的傲慢，單就不願意講問題，還用上面的話搪塞我，就足夠讓人氣憤的了。

我自己也做過面試官面別人，選人，技術背景不是最重要的。遇到問題去解決問題的能力才是決定一個人是不是合適的第一標準。題目中的這些技術，不在阿里這種大一統架構去抗業務的場景下討論，不到一定的數量級，根本就不會成為挑戰。就像有人問MySQL百萬條數據查詢會被人鄙視一樣，MySQL設計上對付這種量級的數據輕輕鬆鬆呀。很多時候出現技術挑戰是沒有能很好的理解問題，用了不合適的技術去處理問題。「沒有銀彈」，不存在一套看似簡單而神奇的技術可以解決一切問題。相對地，能全面地，客觀地理解問題，使用合適的工具，正確的方式去處理問題，絕大多數的問題都不是問題。

所以，我打算寫一個藍圖系列，專門討論一下題目里的問題，這些問題的出現的場景是什麼，解決的思路是什麼，常用的手段是什麼，不局限於具體案例和具體場景地探討整個方法論。

圍觀群眾們可以放心，不需要擔心有什麼高深的看不懂的技術，我才疏學淺，又是紙上談兵，到底對大家有沒有價值，屆時可以自行判定。本篇就作為一個序言，順便給目錄留一個位置。