資訊專欄INFORMATION COLUMN
摘要：使用反向代理和加速網站響應在性能權威指南中有講到，網站性能的瓶頸，大部分時間都浪費在的握手和傳輸上。因此可以通過和反向代理的方式來加快響應。分布式數據庫是數據庫拆分的最后手段，只用在單表數據規模特別龐大的時候才使用。
前幾天跟一個朋友聊了一些關于網站緩存分布式的一些東西，發現自己的知識還是太過貧瘠。理論+協議，這是現在我亟待加強的。這個周末買了兩本關于分布式網站的書，本著好記性不如爛筆頭，便有了這樣一系列的文章。希望一同分享，也請多指教。
前言code less, play more!
這個世界上沒有哪個網站從誕生起就是大型網站；也沒有哪個網站第一次發布的時候就擁有龐大的用戶，高并發的訪問，海量的數據；大型網站都是從小型網站發展而來。網站的價值在于它能給用戶提供什么家宅，在于網站能做什么，而不在于它是怎么做的，所以網站在小的時候就去追求網站的架構是舍本逐末，得不償失的。小型網站最需要做的就是為用戶提供更好的服務來創造價值，得到用戶認可，活下去，野蠻生長。
大型網站軟件系統的特點高并發，大流量
高可用
海量數據
用戶分布廣泛，網絡情況復雜
安全環境惡劣
需求快速變更，發布平頻繁
漸進式發展
大型網站的發展歷程初始階段的網站架構
最開始沒有多少人訪問，所以應用程序，數據庫，文件都在同一臺機器上。
應用服務器和數據服務分離
應用和數據分離之后，一般需要三臺服務器。應用服務器，文件服務器和數據庫服務器，這三種服務器對于硬件要求各不相同。
應用服務器：更強大的CPU
數據庫服務器：更快速的磁盤和更大的內存
文件服務器：容量更大的硬盤
使用緩存改善性能
網站的訪問也遵循二八定律：80%的業務集中在20%的數據上。因此可以把這一小部分數據緩存在內存中，減少數據庫的訪問壓力。
網站的緩存可以分為兩種：
本地緩存：緩存在應用服務器上。本地緩存訪問速度快，但是受制于內存限制，緩存數量有限，而且也會出現和應用程序爭搶內存的情況。
遠程分布式緩存：以集群的方式，緩存在大內存的專用緩存服務器。可以在理論上做到不受內存容量限制。
使用應用服務器集群提高并發能力
當一臺服務器的處理能力和存儲空間不足的時候，不要企圖更換更強大的服務器。對于大型網站來說，不管多么強大的服務器，都滿足不了網站持續增長的業務需求。此時就可以考慮集群的方式，通過負載均衡調度服務器，可以將來自用戶的請求分發到應用服務器集群中的任何一臺服務器上。
數據庫讀寫分離
使用緩存后，大部分的數據讀操作訪問都可以不通過數據庫完成，但是仍有部分讀操作（如緩存過期，緩存不命中）和全部的寫操作需要訪問數據庫。
目前大部分數據庫都提供主從熱備的功能，在寫數據的時候，訪問主庫，主庫通過主從復制機制將數據更新同步至從數據庫，在讀的時候就可以通過從數據庫獲取數據。
使用反向代理和CDN加速網站響應
在《web性能權威指南》中有講到，網站性能的瓶頸，大部分時間都浪費在TCP的握手和傳輸上。因此可以通過CDN和反向代理的方式來加快響應。
CDN和反向代理的本質都是通過緩存，不同的主要是：
CDN部署在服務器器上的機房，用戶在請求時，從距離自己最近的機房獲取數據。
反向代理是部署在中心機房，用戶請求到達中心機房之后，首先訪問的服務器是反向代理的拂去其，如果反向代理服務器中緩存著用戶請求的額資源，就將其返回給用戶。
使用分布式文件系統和分布式數據庫系統
隨著業務的發展，依舊不能滿足的時候，就采用分布式的文件和分布式的數據庫系統。
分布式數據庫是數據庫拆分的最后手段，只用在單表數據規模特別龐大的時候才使用。更常用的拆分手段是業務分庫，將不同的業務數據存儲在不同的數據庫中。
使用NoSQL和搜索引擎
對數據檢索和存儲越來越復雜的時候，就可以采用一些非關系型數據庫如HBase和非數據庫查詢技術如ElasticSearch等等
業務拆分
業務場景復雜的時候，一般講整個網站業務分為不同的產品線，如首頁，訂單，買家，賣家等等。
技術上也會根據產品線劃分，將一個網站分為許多不同的應用，每個應用獨立部署維護，應用之間可以通過一個超鏈接建立聯系，也可以通過消息隊列進行數據分發，當然最多的還是通過訪問同一個數據存儲系統來構成一個關聯的完整系統。
分布式服務
隨著業務越拆越小，存儲越來越大，維護越來越困難。此時就可以將相同業務操作的提取出來，獨立部署。應用系統只需要管理用戶界面，通過分布式服務調用共同的業務服務完成具體的業務操作。也就是最近概念越來越火的——微服務。
云計算
大型網站架構解決了海量數據庫管理和高并發事務處理，可以將這些解決方案應用到網站自身以外的業務上。現在像阿里云，亞馬遜等云計算平臺，將計算作為一種基礎資源出售，中小網站不需要關系技術架構等問題，只需要按需付費，就可以使網站隨著業務的增長獲得更大的存儲和計算資源。
未來
未來還能變成什么樣子，我也不清楚，也許以后都不是開發人員來維護了，所有的這些都是AI來完成，程序員要做的就是如何完善AI。也許AI發展到最后，人類都不需要存在了吧。
結語網站的技術是為業務而存在的，除此以外毫無意義。在技術選型和架構設計中，脫離業務發展實際，一味的追求新技術，可能會把技術發展引入一個歪路。
技術是用來解決業務的問題，而技術不可能將所有問題都解決掉，涉及業務自身的問題，還是要通過業務手段去解決。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/70651.html
摘要：阿里巴巴的共享服務理念以及企業級互聯網架構建設的思路，給這些企業帶來了不少新的思路，這也是我最終決定寫這本書的最主要原因。盡在雙阿里巴巴技術演進與超越是迄今唯一由阿里巴巴集團官方出品全面闡述雙八年以來在技術和商業上演進和創新歷程的書籍。 showImg(https://segmentfault.com/img/remote/1460000015386860); 1、大型網站技術架構：核...
摘要：使用緩存兩個前提條件數據訪問熱點不均衡數據某時段內有效，不會很快過期反向代理本地緩存分布式緩存異步旨在系統解耦。 大型網站技術架構-入門梳理 標簽 ： 架構設計 [TOC] 羅列了大型網站架構涉及到的概念，附上了簡單說明 前言 本文是對《大型網站架構設計》(李智慧 著)一書的梳理，類似文字版的思維導圖 全文主要圍繞性能，可用性，伸縮性，擴展性，安全這五個要素 性能，可用性，伸縮性...
摘要：本項目主要收集國內外各大互聯網公司技術大牛們出版的值得一看的書籍，歡迎推薦書籍完善內容和排版。逆流而上阿里巴巴技術成長之路阿里巴巴集團成長集編委會總結阿里巴巴技術團隊在基礎架構中間件數據庫業務開發等領域的經典實踐以及對未來的思考。 出自 GitHub 開源組織 Doocs源地址：https://github.com/doocs/tech... 后面將會在 GitHub 陸續更新書籍清...
閱讀 3331·2019-08-29 16:17
閱讀 1986·2019-08-29 15:31
閱讀 2656·2019-08-29 14:09
閱讀 2556·2019-08-26 13:52
閱讀 753·2019-08-26 12:21
閱讀 2150·2019-08-26 12:08
閱讀 1001·2019-08-23 17:08
閱讀 1934·2019-08-23 16:59
