大型網站技術架構

純陽書評（公衆號:純陽書評／微信號:chimbusco88）《構建可伸縮web應用》是一本重點關注網站伸縮性的架構好書，而本書則是關於大型網站性能、可用性、伸縮性、擴展性和安全性等5個核心要素的架構好書！ 好在三個方面，一是作者具很強洞察力，觀察並總結出了大型網站發展過程中架構立演化的規律和內在邏輯。 二是通過爲現階段大型網站架構做全景式透視，闡述了不同層面架構設計所要考慮的問題和解決思路，詳細討論了分層、分割、分離、分庫、分片和分佈的理念和實踐。 三是分享了關於架構師的分類、領導藝術、互聯網應用與傳統應用開發異同等方面的觀點，見解很精闢。

大型網站不是設計出來的，而是逐步發展演化出來的。 不要企圖去設計一個大型網站！ 有些傳統企業進軍互聯網，憑藉其雄厚的資金、豐富的行業經驗、近乎壟斷的市場地位，試圖在互聯網領域開發一個大型網站複製其在傳統行業的優勢地位。但是互聯網發展運行有其自己的規律，短暫的互聯網歷史已經一再證明這種企圖是行不通的。 壟斷、牌照、行業壁壘、國有資本、行政資源，這些在傳統行業呼風喚雨的魔法到了互聯網領域只會被嘲笑、被捉弄。龐大隻是笨拙而已，壁壘只會畫地爲牢，沒什麼了不起。 互聯網沒有門檻，誰都可以進來玩，但是進來後，最好把那些陳舊的思想和包袱放下，重新來過。 互聯網是一個開放和分享的世界，這裏是創新者的樂園，探險者的處女地。只要你努力，富有想象力和聰明才智，能爲用戶創造價值，能推動社會進步，不管你開始時多麼弱小，總有機會迅速聚集資金、人才和注意力，在的時間內發展壯大。 互聯網是一種精神，一種開放、分享、自由的精神；越是付出不問回報，越是獲得豐厚的回報；越是不設邊界，越是擁有整個世界。互聯網是一種顛覆，打碎所有的藩籬，給所有人平等表達和獲取的機會，每個人都可以發出自己的聲音。互聯網是一種建設，重塑人們的思維方式和社會運行方式，建設一個人和人彼此理解信任的大同世界。

一個大型網站不是設計出來的，是一步步發展演進而成的，書中主要介紹了網站設計的基本架構技術選型，包括架構的設計和優化等，一些重點技術的使用場景案例剖析，增長了不少見識，值得定期翻開再研讀。         最後書中說的真好:互聯網是一種精神，一種開放、分享、自由的精神；越是付出不問回報，越是獲得豐厚的回報；越是不設邊界，越是擁有整個世界。互聯網是一種顛覆，打碎所有的藩籬，給所有人平等表達和獲取的機會，每個人都可以發出自己的聲音。互聯網是一種建設，重塑人們的思維方式和社會運行方式，建設一個人和人彼此理解信任的大同世界。 互聯網正在並將繼續改變這個世界，一切纔剛剛開始，你我正生逢其時！

雖然這本書成書時間較早，裏面提到的技術放在如今大多已經過時，但是作者作爲架構師在解決這些技術問題過程中的思考方式和職業生涯的閱歷我認爲纔是這本書最值得稱道的地方。技術永遠在進步，只是表象，但是解決問題的思維方式纔是本質。因此不在於掌握多先進的技術，而在於根據實際業務使用最適合的技術，技術一定是要圍繞業務螺旋式展開的。

5分好評。技術書有其獨特的寫作難度，但這本書的作者能做到舉重若輕，靠的是豐富的經驗，嚴密的邏輯，廣闊的胸懷，甚至是禪師般的哲學境界。 全書精煉而全面，沒有代碼，沒有廢話，有一點理科基礎的讀者，都可以輕鬆看懂這本書，看過後會對網站的技術支持有一個全面的瞭解和理解。

幾年前，我讀過，感覺學到了好多東西，很多東西聽都沒有聽過；這次讀感覺內容有點淺薄，即便是這樣，也學到了好多，再次鞏固一下，列出來，如下： 1、Facebook是伯克扎克同學在哈佛大學的宿舍裏開發的；Google的第一臺服務器部署在斯坦福大學的實驗室裏；阿里巴巴則是在馬雲家的客廳裏誕生的。好的互聯網產品都是慢慢運營出來的，不是一開始就開發好的，這也正好與網站架構的發展演化過程對應。 2、網站技術是爲業務而存在的，除此毫無意義。在技術選型和架構設計中，脫離網站業務發展的實際，一味追求時髦的新技術，可能會將網站技術發展引入崎嶇小道，架構之路越走越難。 3、技術是用來解決業務問題的，而業務的問題，也可以通過業務的手段去解決。 4、目前網站普遍使用Hadoop及其MapReduce分佈式計算框架進行此類批處理計算，其特點是移動計算而不是移動數據，將計算程序分發到數據所在的位置以加速計算和分佈式計算。此外，還有可以支持網站線上服務器配置實時更新的分佈式配置；分佈式環境下實現併發和協同的分佈式鎖；支持雲存儲的分佈式文件系統等。 5、在單一服務器內部可通過多線程共享內存隊列的方式實現異步，處在業務操作前面的線程將輸出寫入到隊列，後面的線程從隊列中讀取數據進行處理；在分佈式系統中，多個服務器集羣通過分佈式消息隊列實現異步，分佈式消息隊列可以看作內存隊列的分佈式部署。 6、訪問和負載很小的服務也必須部署至少兩臺服務器構成一個集羣，其目的就是通過冗餘實現服務高可用。 7、山寨與創新的最大區別不在於是否抄襲，是否模仿，而在於對問題和需求是否真正理解與把握。 8、一般說來，除了當前的系統功能需求外，軟件架構還需要關注性能、可用性、伸縮性、擴展性和安全性這5個架構要素，架構設計過程中需要平衡這5個要素之間的關係以實現需求和架構目標，也可以通過考察這些架構要素來衡量一個軟件架構設計的優劣，判斷其是否滿足期望。 9、衡量網站性能有一系列指標，重要的有響應時間、TPS、系統性能計數器等，通過測試這些指標以確定系統設計是否達到目標。 10、網站可伸縮架構的主要手段是事件驅動架構和分佈式服務。 事件驅動架構在網站通常利用消息隊列實現，將用戶請求和其他業務事件構造成消息發佈到消息隊列，消息的處理者作爲消費者從消息隊列中獲取消息進行處理。通過這種方式將消息產生和消息處理分離開來，可以透明地增加新的消息生產者任務或者新的消息消費者任務。 分佈式服務則是將業務和可複用服務分離開來，通過分佈式服務框架調用。新增產品可以通過調用可複用的服務實現自身的業務邏輯，而對現有產品沒有任何影響。可複用服務升級變更的時候，也可以通過提供多版本服務對應用實現透明升級，不需要強制應用同步變更。 11、衡量網站安全架構的標準就是針對現存和潛在的各種攻擊與竊密手段，是否有可靠的應對策略。 12、性能、可用性、伸縮性、擴展性和安全性是網站架構最核心的幾個要素，這幾個問題解決了，大型網站架構設計的大部分挑戰也就克服了。 14、吞吐量：指單位時間內系統處理的請求數量，體現系統的整體處理能力。對於網站，可以用“請求數/秒”或是“頁面數/秒”來衡量，也可以用“訪問人數/天”或是“處理的業務數/小時”等來衡量。TPS（每秒事務數）是吞吐量的一個常用量化指標，此外還有HPS（每秒HTTP請求數）、QPS（每秒查詢數）等。 15、性能測試是一個總稱，具體可細分爲性能測試、負載測試、壓力測試、穩定性測試。 16、減少HTTP的主要手段是合併CSS、合併JavaScript、合併圖片。 17、網站性能優化第一定律：優先考慮使用緩存優化性能。 18、網站數據訪問通常遵循二八定律，即80%的訪問落在20%的數據上 19、一般說來，數據的讀寫比在2:1以上，即寫入一次緩存，在數據更新前至少讀取兩次，緩存纔有意義。 20、因此應用要容忍一定時間的數據不一致，如賣家已經編輯了商品屬性，但是需要過一段時間才能被買家看到。 --所以商品屬性，沒有必要時時更新； 21、當緩存服務崩潰時，數據庫會因爲完全不能承受如此大的壓力而宕機，進而導致整個網站不可用。這種情況被稱作緩存雪崩。 22、產品在設計之初就需要一個明確的定位：什麼是產品要實現的功能，什麼不是產品提供的特性。在產品漫長的生命週期中，會有形形色色的困難和誘惑來改變產品的發展方向，左右搖擺、什麼都想做的產品，最後有可能成爲一個失去生命力的四不像。 23、如果因爲不恰當的業務、或者惡意攻擊持續高併發地請求某個不存在的數據，由於緩存沒有保存該數據，所有的請求都會落到數據庫上，會對數據庫造成很大壓力，甚至崩潰。一個簡單的對策是將不存在的數據也緩存起來（其value值爲null）。 24、啓動線程數=[任務執行時間/（任務執行時間-IO等待時間）]×CPU內核數 25、編程上，解決線程安全的主要手段有如下幾點。 將對象設計爲無狀態對象：所謂無狀態對象是指對象本身不存儲狀態信息（對象無成員變量，或者成員變量也是無狀態對象），這樣多線程併發訪問的時候就不會出現狀態不一致，Java Web開發中常用的Servlet對象就設計爲無狀態對象，可以被應用服務器多線程併發調用處理用戶請求。 使用局部對象：即在方法內部創建對象，這些對象會被每個進入該方法的線程創建，除非程序有意識地將這些對象傳遞給其他線程，否則不會出現對象被多線程併發訪問的情形。 併發訪問資源時使用鎖：即多線程訪問資源的時候，通過鎖的方式使多線程併發操作轉化爲順序操作，從而避免資源被併發修改。 26、從編程角度，資源複用主要有兩種模式：單例（Singleton）和對象池（Object Pool）。 27、事實上，Java開發常用的對象容器Spring默認構造的對象都是單例（需要注意的是Spring的單例是Spring容器管理的單例，而不是用單例模式構造的單例）。 28、對於每個Web請求（HTTP Request），Web應用服務器都需要創建一個獨立的線程去處理，這方面，應用服務器也採用線程池（Thread Pool）的方式。這些所謂的連接池、線程池，本質上都是對象池，即連接、線程都是對象，池管理方式也基本相同。 29、在JVM分代垃圾回收機制中，將應用程序可用的堆空間分爲年輕代（Young Generation）和年老代（Old Generation），又將年輕代分爲Eden區（Eden Space）、From區和To區，新建對象總是在Eden區中被創建，當Eden區空間已滿，就觸發一次Young GC（Garbage Collection，垃圾回收），將還被使用的對象複製到From區，這樣整個Eden區都是未被使用的空間，可供繼續創建對象，當Eden區再次用完，再觸發一次Young GC，將Eden區和From區還在被使用的對象複製到To區，下一次Young GC則是將Eden區和To區還被使用的對象複製到From區。因此，經過多次Young GC，某些對象會在From區和To區多次複製，如果超過某個閾值對象還未被釋放，則將該對象複製到Old Generation。如果Old Generation空間也已用完，那麼就會觸發Full GC，即所謂的全量回收，全量回收會對系統性能產生較大影響，因此應根據系統業務特點和對象生命週期，合理設置Young Generation和Old Generation大小，儘量減少Full GC。 30、目前許多NoSQL產品採用LSM樹作爲主要數據結構，LSM樹可以看作是一個N階合併樹，在LSM樹上進行一次數據更新不需要磁盤訪問，在內存即可完成，速度遠快於B+樹。當數據訪問以寫操作爲主，而讀操作則集中在最近寫入的數據上時，使用LSM樹可以極大程度地減少磁盤的訪問次數，加快訪問速度。 31、RAID5和RAID3很相似，但是校驗數據不是寫入第N塊磁盤，而是螺旋式地寫入所有磁盤中。這樣校驗數據的修改也被平均到所有磁盤上，避免RAID3頻繁寫壞一塊磁盤的情況。 32、網站性能優化的主要工作是改善高併發用戶訪問情況下的網站響應速度。 33、歸根結底，技術是爲業務服務的，技術選型和架構決策依賴業務規劃乃至企業戰略規劃，離開業務發展的支撐和驅動，技術走不遠，甚至還會迷路。 34、網站不可用時間（故障時間）=故障修復時間點-故障發現（報告）時間點。 35、對於大多數網站而言，2個9是基本可用，網站年度不可用時間小於88小時；3個9是較高可用，網站年度不可用時間小於9小時；4個9是具有自動恢復能力的高可用，網站年度不可用時間小於53分鐘；5個9是極高可用性，網站年度不可用時間小於5分鐘。 36、既然硬件故障是常態，網站的高可用架構設計的主要目的就是保證服務器硬件故障時服務依然可用、數據依然保存並能夠被訪問。 37、在應用程序中設置服務調用的超時時間，一旦超時，通信框架就拋出異常，應用程序根據服務調度策略，可選擇繼續重試或將請求轉移到提供相同服務的其他服務器上。 38、降級有兩種手段：拒絕服務及關閉服務。 39、數據一致性又可分爲如下幾點。、 數據強一致：各個副本的數據在物理存儲中總是一致的；數據更新操作結果和操作響應總是一致的，即操作響應通知更新失敗，那麼數據一定沒有被更新，而不是處於不確定狀態。 數據用戶一致：即數據在物理存儲中的各個副本的數據可能是不一致的，但是終端用戶訪問時，通過糾錯和校驗機制，可以確定一個一致的且正確的數據返回給用戶。 數據最終一致：這是數據一致性中較弱的一種，即物理存儲的數據可能是不一致的，終端用戶訪問到的數據可能也是不一致的（同一用戶連續訪問，結果不同；或者不同用戶同時訪問，結果不同），但系統經過一段時間（通常是一個比較短的時間段）的自我恢復和修正，數據最終會達到一致。 40、即使每次發佈的新功能都是在原有系統功能上的小幅增加，但爲了保證系統沒有引入未預料的Bug，網站測試還是需要對整個網站功能進行全面的迴歸測試。 41、比較流行的Web自動化測試工具是ThoughtWorks開發的Selenium。Selenium運行在瀏覽器中，模擬用戶操作進行測試，因此Selenium可以同時完成Web功能測試和瀏覽器兼容測試。 42、對於有固定發佈日期的網站（很多網站選擇週四作爲發佈日，這樣一週前面有三天時間可以準備發佈，後面還有一天時間可以挽回錯誤。如果選擇週五發佈，發現問題就必須要週末加班了。） 43、“不允許沒有監控的系統上線”，這是許多網站架構師在做項目上線評審時常說的一句話。 44、目前許多網站逐步開發基於實時計算框架Storm的日誌統計與分析工具。 45、事物總是先求生存，然後求發展。保證網站可用，萬無一失，任重而道遠。 46、使用三角傳輸模式的鏈路層負載均衡是目前大型網站使用最廣的一種負載均衡手段。在Linux平臺上最好的鏈路層負載均衡開源產品是LVS（Linux Virtual Server）。 47、負載均衡算法通常有以下幾種。 輪詢（Round Robin，RR）、加權輪詢（Weighted Round Robin，WRR）、隨機（Random）、最少連接（Least Connections）、源地址散列（Source Hashing） 48、計算機領域有句話：計算機的任何問題都可以通過增加一個虛擬層來解決。計算機硬件、計算機網絡、計算機軟件都莫不如此。計算機網絡的7層協議，每一層都可以看作是下一層的虛擬層；計算機操作系統可以看作是計算機硬件的虛擬層；Java虛擬機可以看作是操作系統的虛擬層；分層的計算機軟件架構事實上也是利用虛擬層的概念。 49、網站架構師必須對網站的商業目標、歷史演化、技術路線瞭然於胸，甚至還需要綜合考慮技術團隊的知識儲備和結構、管理層的戰略願景和規劃，才能最終做出對網站伸縮性架構最合適的決策。 50、高手定律：這個世界只有遇不到的問題，沒有解決不了的問題，高手之所以成爲高手，是因爲他們遇到了常人很難遇到的問題，並解決了。 51、救世主定律：遇到問題，分析問題，最後總能解決問題。如果遇到問題就急匆匆地從外面挖一個高手，然後指望高手如探囊取物般輕鬆搞定，最後怕是隻有彼此抱怨和傷害。許多問題只是看起來一樣，具體問題總是要具體對待的，沒有銀彈，沒有救世主。所以這個定律準確地說應該是“沒有救世主定律”。 52、擴展性（Extensibility）：指對現有系統影響最小的情況下，系統功能可持續擴展或提升的能力。表現在系統基礎設施穩定不需要經常變更，應用之間較少依賴和耦合，對需求變更可以敏捷響應。它是系統架構設計層面的開閉原則（對擴展開放，對修改關閉），架構設計考慮未來功能擴展，當系統增加新功能時，不需要對現有系統的結構和代碼進行修改。 伸縮性（Scalability）：指系統能夠通過增加（減少）自身資源規模的方式增強（減少）自己計算處理事務的能力。如果這種增減是成比例的，就被稱作線性伸縮性。在網站架構中，通常指利用集羣的方式增加服務器數量、提高系統的整體事務吞吐能力。 53、筆者認爲，軟件架構師最大的價值不在於掌握多少先進的技術，而在於具有將一個大系統切分成N個低耦合的子模塊的能力，這些子模塊包含橫向的業務模塊，也包含縱向的基礎技術模塊。這種能力一部分源自專業的技術和經驗，還有一部分源自架構師對業務場景的理解、對人性的把握、甚至對世界的認知。 54、馬克思的勞動價值理論告訴我們，產品的內在價值在於勞動的時間，勞動的時間不在於個體付出的勞動時間，而在於行業一般勞動時間，資本家只會爲行業一般勞動時間買單，如果你的效率低於行業一般勞動時間，對不起，請你自願加班。 55、HTTP請求頭的Referer域中記錄着請求來源，可通過檢查請求來源，驗證其是否合法。很多網站使用這個功能實現圖片防盜鏈（如果圖片訪問的頁面來源不是來自自己網站的網頁就拒絕）。 56、ModSecurity是一個開源的Web應用防火牆，探測攻擊並保護Web應用程序，既可以嵌入到Web應用服務器中，也可以作爲一個獨立的應用程序啓動。ModSecurity最早只是Apache的一個模塊，現在已經有Java、.NET多個版本，並支持Nginx。 57、信息加密技術可分爲三類：單項散列加密、對稱加密和非對稱加密。 58、在合適的場景下使用合適的產品，而不是最好的產品，所謂小腳穿大鞋，不但跑不快，還可能會摔跤。 59、Wikipedia通過約束業務獲得更大的技術方案選擇餘地，很多時候業務後退一小步，技術就可以前進一大步。 60、一般而言，服務器之間通信越少，就越少依賴，發生故障時互相影響就越少，集羣的可用性就越高。 61、網站的秒殺業務不能使用正常的網站業務流程，也不能和正常的網站交易業務共用服務器，必須設計部署專門的秒殺系統，進行專門應對。 62、 秒殺系統的應對策略爲了應對上述挑戰，秒殺系統的應對策略有如下幾點。 1）、秒殺系統獨立部署 2）、秒殺商品頁面靜態化 3）、租借秒殺活動網絡帶寬 4）、動態生成隨機下單頁面URL 63、大型網站的架構師最有價值的地方不在於他們掌握了多少技術，而在於他們經歷過多少故障。每一次故障都會給公司帶來難以估計的利益損失，所以培養一個網站架構師的成本不單要看付了他多少薪水，給了他多少股票，還要看爲他引起的故障買了多少次單。 64、高併發訪問數據庫引發的故障，經驗教訓： ●首頁不應該訪問數據庫，首頁需要的數據可以從緩存服務器或者搜索引擎服務器獲取。 ●首頁最好是靜態的。 65、高併發情況下鎖引發的故障，經驗教訓： ●使用鎖操作要謹慎。 66、緩存引發的故障，經驗教訓： 、 ●當緩存已經不僅僅是改善性能，而是成爲網站架構不可或缺的一部分時，對緩存的管理就需要提高到和其他服務器一樣的級別。 67、不規範的流程引發的故障，經驗教訓： ●代碼提交前使用diff命令進行代碼比較，確認沒有提交不該提交的代碼。 ●加強code review，代碼在正式提交前必須被至少一個其他工程師做過code review，並且共同承擔因代碼引起的故障責任。 68、不好的編程習慣引發的故障，經驗教訓： ●程序在處理一個輸入的對象時，如果不能明確該對象是否爲空，必須做空指針判斷。 ●程序在調用其他方法時，輸入的對象儘量保證不是null，必要時構造空對象（使用空對象模式）。 69、一定要堅信：一羣優秀的人做一件他們熱愛的事，一定能取得成功。 70、這也是領導的真諦：尋找一個值得共同奮鬥的目標，營造一個讓大家都能最大限度發揮自我價值的工作氛圍。 71、沒有懶惰的員工，只有沒被激發出來的激情。所有強迫員工加班的管理者都應該爲自己的無能而羞愧。 72、大多數人，包括我們自己，都比自己以爲的更優秀，有些優秀需要在合適的環境中才會被激發出來，比如做一些有挑戰的事，和更優秀的人合作，抑或擁有了超越自我的勇氣。發掘人的優秀遠比發掘優秀的人更有意義。 73、共同參與架構 1）、不要只有架構師一個人擁有架構 讓項目參與者對架構充分爭論，大家越是覺得自己是項目架構的重要貢獻者，就越是願意對開發過程承擔責任，越是願意共同維護架構和改善軟件。 2）、讓其他人維護框架與架構文檔 除非是重大的重構，否則架構師應該讓項目組成員維護框架和架構文檔，給項目組成員成長的機會也讓自己有更多的時間去尋找更大的挑戰。 74、不要企圖在項目中證明自己是正確的，一定要記住，你是來做軟件的，不是來當老大的。所以不要企圖去證明自己了不起，永遠也別幹這種浪費時間、傷害感情的事。 75、架構師作爲團隊的技術領導者，在項目過程中不要去試圖控制什麼，帶着一個彈性的計劃和藍圖推進，團隊會管好他們自己。你越是強加禁令，隊伍就越是沒有紀律；你越是強制，團隊就越是不能獨立自主；你越是從外面尋找幫助，大家就越是沒有信心。 76、開發軟件的目的是爲了解決現實世界的問題，但是很多時候人們並不清楚真正的問題是什麼。有可能大家很辛苦地忙活了一場，發現做出來的軟件一點價值沒有。 77、所謂問題，就是體驗—期望，當體驗不能滿足期望，就會覺得出了問題。消除問題有兩種手段：改善體驗或者降低期望。降低期望只是迴避了問題，而如果直面期望和體驗之間的差距，就會發現問題所在，找到突破點。 78、給上司提封閉式問題，給下屬提開放式問題 所以，只有“元方，你怎麼看？”，而沒有“大人，你怎麼看？”。 79、用一種溫和的方式提出問題“我非常贊同你的方案，不過我有一個小小的建議……”。 80、有時候，有些人會提出一些不怎麼靠譜的問題和方案。比如，一個急着要表現自己能力和價值的新員工，你如果和他直接說“不行”，會挫傷他的積極性，而他經過一段時間的磨合和思考，會自己意識到不可行。對於這種情況，適當逃避問題，將事情擱置起來是最好的辦法。“我去開個會，我們回來再談。”“這個idea非常好，我們改天組織一個會議好好討論一下……” 81、目前各種NoSQL數據庫層出不窮，在內存管理、數據模型、集羣分佈式管理等方面各有優勢，不過從社區活躍性角度看，HBase無疑是目前最好的。 82、這是一本講大型網站架構設計的書，但是大型網站不是設計出來的，而是逐步發展演化出來的。

頁頁乾貨，字字珠璣，喜歡看這種短小而精悍、深入而淺出的書，作者從從一個大的視角高屋建瓴的分析了大型(高併發和海量數據處理)網站的方方面面，前面幾章偏技術，後面幾章偏項目管理，總體來看是一本目錄級別的入門書，對於具體技術的細節仍需要深入研究。

一刷書評： 這是一本關於系統架構設計技術啓蒙或入門的書籍，5星推薦。 這是一本無意或有意間偶然看到的書，雖做着與之無關的工作，但周圍也碰到一些類似問題，同時因爲興趣而讀了下來，讀得比較細，歷時超過8小時，大概5天的時間，做了超過300條筆記，在讀的過程中，有一種醍醐灌頂或者說是柳暗花明又一村的感覺，正如作者在書中所說，原理其實是很簡單清晰的，這或者也可以說是“系統架構設計應該是簡單的，簡單到沒有明顯的問題”，不管我們是否讀懂了該書，如果要落實到底，對我們來說仍然任重而道遠，不可輕視。 這是一本技術指導的書，建議帶着問題來讀，這樣就感覺特別想讀，同時強烈建議先讀完<<淘寶技術這十年>>後，再讀該書，也許我們的感受會更好些，如果能夠和實踐中碰到問題結合起來，也許我們的感受會更深，乃至該書的循序漸進的解決方案會有一種水到渠成的感覺，或者說理所當然應該如此做。這兩本書都是“阿里人”所著，反映了阿里的一個特點趨勢，業務不斷驅動技術，技術促進業務發展，這何嘗不是對於現實裏中小公司具有極好的借鑑學習呢。比較好奇的是：業界常說百度強技術，阿里強運營，騰訊強產品。感覺同爲bat，阿里技術人這邊出類似技術類書籍要多於另外兩家，也許是其他2家可能不喜歡分享吧，但是最大的也許是我讀書少😅。 這也是一本關於做人做事的書。在書中最後部分，揮灑了很多筆墨，傳遞了作者的一些觀點。以前也碰到過類似問題，一直難以忘懷，在讀該書中，豁然開朗。看來，讀書真的是一件好事。當我們讀完一百本，我們或許會與之前有了一些不同吧；當我們讀完500本，也許會到達另一個層次吧；而當我們讀完1000本，又會是怎麼一番場景了，也許對於自己、對於這個社會、對於這個世界、乃至對於我們這個宇宙，會有獨屬於自己全新的認知吧。然而真正到達這幾個節點的人幾乎不會告訴我們這是一種怎樣的感覺，即使講述出來我們是否又能真正切實感受到呢？而這也是我們一直持續不斷追求的東西。 而我此時比較好奇的只是這樣一個問題，讀完100本書，我們需要多少時間😂。 以上僅爲一個非架構師初學者詞不達意的喃喃自語。

系統設計的一本入門指南級圖書。大，全，而不深。 針對大型網站架構的追求：性能，可用性，伸縮性，擴展性，安全性。作者都列舉了常見的具體的解決方案，且簡單描述了原因，原理，實現和效果。這些解決方案大都是自底向上的經驗總結，而缺少宏觀設計。又可能篇幅受限，流於淺顯。最可惜的是，作者沒有給出參考文獻，好像把人胃口吊起來，然後菜沒了。 除了技術的部分，對架構師職業性質和內容的探討，真誠而有啓發，個人覺得反而比前文更有價值。

在互聯網領域，任何一個小問題，當數據規模，業務場景增長到一定量級時，問題都會開始變得棘手起來。《大型網站技術架構：核心技術原理與案例分析》一書簡單的介紹了一個網站是如何一步步從最簡單的單體架構模式逐漸演變成集羣分佈式架構。針對大型網站在性能、可用性、伸縮性、擴展性、安全性等方面的常見問題以及處理方案也做了比較細緻的介紹。 在演變的過程中，網站的性能、可用性、伸縮性、擴展性、安全性收到了前所未有的挑戰，但正是有了這些挑戰，也才促進了技術的快速進步與發展；另一方面，技術是服務於業務的，如果爲了技術而技術往往得不償失，業務的發展過程也是漸進式的，在業務的不同階段需要不同的架構和模式，因此，在軟件行業，沒有聖盃和銀彈。但在發展過程中，我們逐漸吸取經驗教訓，卻又總結了一套可以服用的理論和方法，在實際過程中還是需要特殊情況特殊處理，切不可生搬硬套。