073. 互聯網系統架構演進之路

 

1. 互聯網技術演進之路

---

1. 初生

• 無名的網站 -> 訪問量低，一臺服務器知足需求。

• 典型的技術 LAMP：Linux + Apache + MySQL + PHP

2. 發展問題

• 性能愈來愈差
• 愈來愈多的數據致使存儲空間不足

3. 應用服務和數據服務分離

• 服務器對應不一樣的硬件需求
  • 應用服務器：須要更快更強大的 CPU（處理大量的業務邏輯）
  • 數據庫服務器：須要更快的硬盤和更大的內存（快速磁盤檢索和數據緩存）
  • 文件服務器：須要更大的硬盤（存儲大量用戶上傳的文件）
• 不一樣的服務器承擔不一樣的角色
  • 併發處理能力。
  • 數據存儲空間。

4. 發展問題

• 數據庫壓力太大致使訪問延遲，進而影響整個網站的性能，用戶體驗受到影響。

5. 使用緩存改善性能

• 緩存
  • 本地緩存（能存的數據量較少，而且會與應用程序爭奪內存）
  • 遠程分佈式緩存

6. 發展問題

• 可以處理的請求鏈接有限，網站訪問高峯期，應用服務器成爲整個網站的瓶頸。

7. 應用服務器集羣

• 負載均衡
  • 軟件：Apache、Nginx、Reverse-proxy、pWEB、LVS
  • 硬件：F5
  • DNS 負載均衡

8. 發展問題

• 有一部分讀操做（緩存訪問不命中，緩存過時）和所有的寫操做要訪問數據庫，當用戶達到必定規模後，數據庫由於負載壓力太高而成爲整個系統的瓶頸。

9. 數據庫讀寫分離

• 數據訪問模塊
  • 在 Mybatis 中開發插件
  • Mycat
  • Sharding-JDBC

10. 發展問題

• 用戶規模愈來愈大，發佈地域愈來愈廣，地域網絡環境差異很大，面臨問題：如何保證用戶的訪問體驗，不至於因訪問慢而流失用戶？

11. 反向代理和 CDN 加速

• 加快用戶訪問響應速度。
• 減輕後端服務器的負載壓力。

12. 發展問題

• 單文件服務器、單數據庫服務器，面臨問題：存不下日益增加的數據。

13. 分佈式文件系統和分佈式數據庫系統

• 適合存儲小文件、圖片的分佈文件系統
  • FastDFS
  • TFS
• 數據訪問模塊
  • Mycat
  • Sharding-JDBC

14. 發展問題

• 隨着業務的發展，數據的存儲需求和檢索需求愈來愈複雜，面臨的問題：
  • 存儲的字段差別較大，骷髏表。
  • 複雜的文本檢索。

15. 使用 NoSQL、搜索引擎

• 搜索引擎：lucene、solr、elasticsearch
• NoSQL：mongodb、elasticsearch

16. 發展問題

• 網站越作越好，業務不斷擴大，愈來愈複雜，面臨的問題：應用程序將變得無比龐大，迭代週期愈來愈快，牽一髮而動全身，怎樣應對快速的業務發展須要？

17. 業務拆分

• 如大型電商網站會將首頁、商鋪、訂單、買家等拆分不一樣的產品線，分歸不一樣的團隊負責，分紅不一樣的應用，獨立部署。經過連接、MQ、數據存儲系統創建關聯。

18. 發展問題

• 業務規模不斷增大，應用拆分愈來愈小，愈來愈多，面臨問題：
  • 應用間的關係愈來愈複雜，應用中存在大量相同的業務操做。
  • 後端的數據庫要被成千上萬應用服務器鏈接，數據庫鏈接資源不足。

19. 分佈式服務（服務化）

• 服務化的兩種架構方式

• 服務框架：Dubbo、SpringCloud

• 配置中心：Dubbo、SpringCloud config、Disconf（百度）、Config-toolkit（噹噹）、Diamond（阿里）

20. 發展問題

• 數據挖掘、分析、推薦等業務需求，龐大系統的監控、問題分析等需求。

21. 大數據技術、監控、 日誌分析系統

• 大數據：Hadoop、Spark
• 系統監控：Zabbix、ElasticSearch+beats+Kibana
• 集中式日誌分析系統：ELK

2. 架構設計思想總結

---

• 分而治之。
• 隨網站所需靈活應對。
• 業務發展驅動技術發展，技術發展反哺業務。
• 軟件系統的價值在於它能爲用戶提供什麼價值，在於網站能作什麼，而不在於他是怎麼作的。

3. 架構設計的誤區

---

• 一味追隨大公司的解決方案。
• 爲了技術而技術。
• 企圖用技術解決全部問題。