某些App怎麼扛住1分鐘10億請求？
架構的演進路線
百萬級併發：1秒100萬次請求。
千萬級併發：一分鐘6億次請求，差不多就是需求的極限。
架構的設計和架構優化要符合需求本身，不能無限制優化。
基本概念
（1）分佈式（系統中，多個模塊在不同服務器上部署）
（2）集羣（一個軟件部署在多臺服務器，並作爲一個整體，提供一類服務）
（3）高可用（系統中部分節點失效，其他節點能夠接替它繼續工作或有相應的處理預案）
（4）負載均衡（把請求均勻的發到多個節點上）
架構演進：
DNS服務器，做域名解析的服務器，作用是，經過DNS將www.taobao.com這類的域名轉換爲實際IP地址，瀏覽器轉而訪問這個IP對應的tomcat。
瓶頸：用戶增長，tomcat和數據庫之間競爭資源，單機性能不足以支撐業務。
第一次：Tomcat和數據庫分開部署（最常見架構）
Tomcat和數據庫分別獨佔服務器資源，顯著提高兩者各自性能（tomcat服務器找一個內存大的，DB服務器找一個硬盤大的，帶寬更寬的）。
瓶頸：用戶量增長，數據庫併發讀寫，尤其是讀，成爲瓶頸。
注意，不會通過數據庫集羣解決。
第二次演進：引入本地緩存甚至分佈式緩存
在Tomcat服務器上（Java程序所在的地方）加入緩存，可以把絕大多數請求（尤其是查詢）在訪問數據庫前攔截掉。
Redis放在Tomcat服務器上，如果不夠用。
那麼Redis可以自己放在一個服務器，也可以多弄幾臺Redis服務器，配置成主從同步（提升可用性可以加上哨兵）。
瓶頸：用戶數量增長，併發壓力主要在單機的tomcat上，響應逐漸變慢。
第三次演進：引入反向代理和負載均衡
使用反向代理，將大量的用戶請求，均勻分發到每個Tomcat中（一般來講，Tomcat對應100個併發，nginx對應5萬個併發，具體的要看服務器性能）。
瓶頸：應用服務器可支持的併發量大大增加，緩存能力也可以輕易擴展，併發量增長意味着更多請求穿透到數據庫，單機的數據庫最終成爲瓶頸。
第四次演進：數據庫讀寫分離
把數據庫劃分爲讀庫和寫庫，讀庫可以有多個，通過同步機制把寫庫的數據同步到讀庫，使用數據庫中間件（Mycat），通過它來組織數據庫的分離讀寫。
瓶頸：業務逐漸變多，不同業務之間的訪問量差距較大，不同業務直接競爭數據庫，相互影響性能。
第五次演進：數據庫按業務分庫
把不同的業務數據保存到不同的數據庫中，業務之間的資源競爭降低，訪問量大的業務可以部署更多的服務器。
瓶頸：用戶數量增長，單機的寫庫會逐漸達到性能瓶頸。
第六次演進：把數據庫的大表拆成小表
其他環節同上。
比如針對訂單生成，可以按照月份，甚至小時創建表。
這種做法可以稱作分佈式數據庫，但邏輯上仍然是一個完整的數據庫整體，現在有一種架構叫MPP（大規模並行處理），針對於各種這類問題的使用場景。
瓶頸：數據庫和tomcat都可以大規模水平擴展，最終單機的nginx會成爲瓶頸。
第七次演進：使用LVS讓多個Nginx負載均衡
LVS是軟件，運行在操作系統內核態，可以對TCP請求或高層網絡協議進行轉發，分發的性能遠高於Nginx，大概十幾萬。
F5是硬件，跟LVS做的事情類似，但性能更高，而且價格昂貴。
這種方式，用戶可達千萬或上億級別。
瓶頸：LVS達到瓶頸，或用戶分佈在不同的地區，與服務器機房的距離不同，導致訪問延遲的不同。
第八次演進：DNS輪詢實現機房間的負載均衡
在DNS中配置一個域名對應多個IP。
每個IP地址對應到不同的機房裏的虛擬IP。
做到機房級別的水平擴展，已經是從請求併發量來講，過億的處理方案，十幾億或幾十億的併發，暫時沒人考慮。
瓶頸：檢索，分析的需求越來越多，單靠數據庫無法解決各種各樣的需求。
第九次演進：引入NoSQL數據庫和搜索引擎
數據量多到一定規模的時候，關係型數據庫不再適用，而且數據量較大的查詢，MySQL不一定能運行出結果，對於海量數據的處理，通過分佈式文件系統HDFS來存儲，對於key-value類型的數據，通過HBase、Redis等處理，對於抓取查詢，可以通過ES等解決，對於多維分析，通過kylin、Druid等解決。
引入更多的組件同時必然極大的提高系統複雜度，不同的組件的數據還需要同步，需要考慮一致性問題。
第十次演進：大應用拆爲小應用
結構圖中上下不變：
按照業務板塊來劃分應用，使單個應用的職責更清晰，相互之間可以做到獨立升級迭代，甚至可以做到部分功能關閉。
瓶頸：不同應用之間，存在公用的模塊，導致包含公共功能的部分在升級時，全部相關代碼都要跟着升級。
第十一次演進，抽離成微服務
類似於我們現在寫的SpringCloud的項目結構，尤其是當用戶，支付等功能在多個應用中都存在，抽離出來效率更高
現在想實現這種效果，可以用現成的框架。
再往下演進，ESB服務總線做接口管理，容器化技術實現運行環境隔離，雲平臺承載大型系統
雲平臺中的幾個概念：
IaaS：基礎設施即服務，可申請硬件資源的層面。
PaaS：平臺即服務，提供雲平臺常用的技術組件的開發和維護。
SaaS：軟件即服務，開發好一個應用，部署之後，按照功能或要求付費。
總結
（1）架構調整是否必須按照上面的路線演變？
不一定！！！上面講的是電商方向，已有的演化線路。
（2）對於即將實施的系統，架構要設計到什麼程度？
夠用就行，問清楚什麼叫夠用，設計要滿足下一階段用戶量和性能指標的要求。
（3）微服務和大數據架構？
這倆架構，解決的是同一個系統中，不同環節的問題。
不用比好壞，也不用分開處理。