互聯網系統面臨的挑戰
高併發、大流量
QPS：每秒鐘請求或者查詢的數量，在互聯網領域，指每秒鐘請求數（指HTTP請求）
吞吐量：單位時間沒處理的請求數量（通常由QPS與併發數決定）
響應時間：從請求發出到收到響應花費的時間。例如系統處理一個HTTP請求需要100ms，這個100ms就是系統的響應時間
PV：綜合瀏覽量（Page View），即頁面瀏覽量或者點擊量，一個訪客在24小時內訪問的頁面數量 同一個人瀏覽你的網站同一頁面，只記作一次PV
高可用
高可用HA（High Availability）是分佈式系統架構設計中必須考慮的因素之一，它通常是指，通過設計減少系統不能提供服務的時間。假設系統一直能夠提供服務，我們說系統的可用性是100%；如果系統每運行100個時間單位，會有1個時間單位無法提供服務，我們說系統的可用性是99%。很多公司的高可用目標是4個9，也就是99.99%，這就意味着，系統的年停機時間爲8.76個小時。
海量數據
隨着互聯網應用的廣泛普及，海量數據的存儲和訪問成爲了系統設計的瓶頸問題。對於一個大型的互聯網應用，每天幾十億的PV無疑對數據庫造成了相當高的負載。對於系統的穩定性和擴展性造成了極大的問題。
水平切分數據庫，可以降低單臺機器的負載，同時最大限度的降低了了宕機造成的損失。通過負載均衡策略，有效的降低了單臺機器的訪問負載，降低了宕機的可能性；通過集羣方案，解決了數據庫宕機帶來的單點數據庫不能訪問的問題；通過讀寫分離策略更是最大限度了提高了應用中讀取（Read）數據的速度和併發量。
安全問題
安全在今天是一個非常嚴肅的事，能做到絕對的安全基本上是不可能的，我們只能不斷提高黑客入侵的門檻。當黑客的投入和收益大大不相符時，黑客也就失去了入侵的意義。
需求變更快、發佈頻繁
因競爭、成本等因素，工期已經確定且極不合理；用戶在需求開發期間技術不足，提出不合理需求或用戶需求不明確；項目組對業務不熟悉，或者沒有與用戶密切配合，需求分析工作不細緻；項目組沒有很好地實施需求管理。
高併發發展的兩個方向
垂直伸縮
通過升級硬件和網絡吞吐能力可以實現垂直伸縮，由於不需要改變應用架構，所以通常認爲是最簡單的短期伸縮性方案；
-
通過使用RAID(獨立冗餘磁盤列陣)增加I/O吞吐能力；
-
通過切換到SSD（固態硬盤）概述I/O訪問速度；
-
通過增加內存加上I/O操作；
-
通過升級網絡接口或者增加網絡接口提高網絡吞吐能力；
-
更新服務器使用更多處理器或者更多線程；
缺點：達到某個程度後，增加計算能力需要更多的花費；垂直伸縮有物理限制；操作系統的設計或者應用程序自身制約着垂直伸縮最多隻能達到某個點。
水平伸縮
水平伸縮是指通過增加服務器提升計算能力的一類架構方法，水平伸縮被認爲是伸縮性的聖盃，水平伸縮可以克服垂直伸縮帶來的成本迅速增加的問題。水平伸縮總是可以增加更多的服務器，就不會遇到單臺服務器的極限。
互聯網架構演化
-
最簡單的互聯網架構由 一臺服務器組成；
-
應用數據分類階段，應用+數據庫+文件服務器分開處理；
-
使用緩存改善系統性能，加上本地緩存和遠程分佈式緩存；
-
應用服務器使用集羣模式，並用負載均衡調度服務器；
-
數據庫讀寫分離，數據庫分爲主從模式；
-
使用方向代理和CDN加速網站響應；
-
使用分佈式文件系統和分佈式數據庫系統；
-
使用nosql和搜索引擎；
-
業務拆分，按照功能模塊進行應用拆分；
-
採用微服務設計以及抽象中臺架構；
核心架構要素
高性能
性能是互聯網的一個重要指標，除非是沒有選擇，否則用戶無法忍受一個響應緩慢的應用。一個打開緩慢應用會導致嚴重的用戶流失，很多時候系統性能問題是系統架構升級優化的觸發器。可以說性能是互聯網系統架構設計的重要一個方面，任何架構設計方案都必須考慮可能帶來的性能問題。
高可用
因爲互聯網分佈式系統使用的服務器硬件通常是普通的商用服務器，這些服務器的設計目標本身不具備高可用，也就是說，很有可能會出現服務器硬件故障，也就是服務器宕機。大型互聯網通常會有上萬臺服務器，每天必定會有一些服務器宕機，每日爲系統高可用架構設計的前提是必然會出現服務器宕機。而高可用科技的目標就是服務器宕機是服務依舊可以用。
可伸縮
大型互聯網應用通過集羣的方式將多臺服務器組成一個整體共同提供服務。所謂伸縮性是指通過不斷向集羣中增加服務器的手段緩解不斷上升用戶的併發訪問的壓力和不斷增長的數據存儲需求。
可擴張
不同於其他架構要素主要關注功能性需求，擴展性架構直接關注系統的功能需求。互聯網應用快速發展，功能不斷擴張，如果設計系統的架構使其能夠快速響應需求的變化，是系統可擴展架構的主要目的。