讀《大型網站技術架構》

大型網站技術架構這本書，囤積已久，最近終于有時間，從頭到尾瀏覽了一遍。看這本書的原因，頗有一些功利性，說白了，就是沖著書名去的。大型網站架構一直心向往之，讀完之后，收獲也是頗多，值得向大家推薦。

曾經看到一本馮唐的零散文集，其中有篇文章印象頗深。他在文章的開頭，提出了一個問題：如何寫好一首詩。大唐盛世300年，詩人不計其數，但最終留下唐詩300首。這么個簡單地問題，可以說上的上是讓古往今來的詩人們前赴后繼了。答案也很簡單，先學，學到什么程度呢？從模仿開始，讀遍前人之作，看遍前人所感，觸類旁通，一步一個腳印。就好比攀爬終南山，不沿著前人的腳印，怎么爬到山頂一覽眾山小呢？

本書作者也表達了類似的觀點，我想這點在技術上也是想通的。不多看看NB的技術是什么樣子的？怎么會有能力做出與之媲美甚至是超越之的完美技術解決方案呢？

本書在思想上，除了這點啟發之外，對架構的重視也值得一提。技術上得架構，類比于建筑業可以說是圖紙設計，類比于廣告業可以說是方案策劃。但是不同之處在于，技術架構影響深遠，而且由于應對的挑戰隨行業發展快速變化，因此必須足夠靈活多變。這對架構提出了很高的要求，也正是本書吸引我的一點。

但是盡管書名看起來像是程序員專享，但作者仍然點出了，給用戶提供有價值的產品和優秀的體驗才是關鍵，這點每個互聯網從業者應該都會贊同，至少都在內心有所追求。

技術上而言，這本書給我提供了一套體系。兩年前開始接觸web開發，零零散散做了不少的事情，也逐步建立了一些自己的體系，但與本書參照了之后，收獲仍是頗豐。無本之木不牢，因此技術體系很重要。從MVC的模型，到Restful API，再到web優化的準則。這些體系化的說明，使得我的技術層次更加清晰，也更加脫離悶頭亂撞的狀態了。不過說到優化，根據自己的經驗來看，對于一個編程基礎不算太差，人也不笨的程序員來說，優化往往不是什么大問題。主要的問題在于找到優化點。計算機是一門科學，因此任何優化都應該是有理有據的，通過高效的工具和經驗找到瓶頸再優化，比奢求瞎貓撞上死耗子，還是要靠譜一些的。而隨著技術了解的深入，我們總是希望自己承擔一些模塊的設計，這也被很多公司認為是區分初級工程師和熟練工程師的分水嶺。這件事要我說，跟打德州撲克很相似：你必須對自己的底牌足夠了解，才能打得出一手好牌。要設計后端存儲，你就必須知道mysql的特性、優化點、系統可能的瓶頸、存儲量、redis的應用場景、維護手段。如果這些你都不了解，那做什么設計呢？可以想象的場景就是，面向用戶的產品成了你的練兵場，存儲不知不覺掛了，你才知道mysql到底該怎么用。除此之外，程序員應該是很懶的一批人，個人認為，技術成長，應該越“懶”越好。為啥上線要手動上傳文件到服務器？這個時代還應該存在人肉測試么？新人來了還是要花一天安裝和熟悉環境？機器磁盤都要爆了，還要凌晨四點手動清理？每個人的時間有限，作為程序員，真的要讓自動化再多一點。與此同時，很多人把產品的發布作為一個里程碑，但卻對產品的安全問題視而不見。安全的代碼依賴于對漏洞的清晰認知、良好的編程習慣、流程保證與漏洞監測機制。當不安全的代碼上線的時候，你就是為自己埋了一個很大很大的坑。。

除卻這些技術上的啟發和細節，本書在安利個人技術的成長上面，不吝筆墨。第一點應該是在最開始說的：閱盡好的東西，你才能寫出接近甚至超越的代碼。蘋果的聯合創始人沃茲在自傳中講述了自己成為電腦專家的過程：對電腦的狂熱讓他把市面上所有的機型都拆了又裝，裝了又拆，從熟悉到自己重新設計，他從 copy，上升到了design。而第二點，則是不要沉迷于代碼，甚至不要沉迷于架構。很多人國人沉迷于某項技術，因此會在不恰當的時候做出背離實際情況的堅持。熟悉web前端優化的同學都知道，CDN是個好東西，那些前端文件、靜態資源，大可以通過CDN的方式來解決。但這并不意味著CDN是標準程序。結合成本、實際問題，應該量體裁衣。有時候基本的靜態資源服務器，就可以實現網站的需求，并不一定要“奢侈”的接入CDN。就連維基百科，都是多種方式相互結合，而并非完全依靠CDN這個“圣杯”。最后一點，則是說架構師，這個職業方向，承擔的責任很多，做的事情也需要更多的思考。有人說架構師最需要代碼能力，有人說架構師最需要設計能力，有人說最需要帶領團隊。但是我最認同一位技術公司首席架構師的說法：架構師說到底，需要具有非常強的problem- solving的能力。這突破了技術的限制，讓你能夠調動自己所有的腦細胞和能力，來解決你團隊遇到的技術、產品、等等問題。

作為一名程序員，遇到這本書十分的開心，接觸到很多很贊的技術細節，也見識了作者架構的功力。這也讓我更加期待接下來要看的《企業應用架構模式》了。不過在那之前，真誠推薦這本《大型網站技術架構》。