大型互聯網架構

時間 2019-11-16

標籤大型互聯網架構欄目系統架構简体版

原文原文鏈接

大型互聯網架構

解決問題的通用思路是將分而治之（divide-and-conquer），將大問題分爲若干個小問題，各個擊破。在大型互聯網的架構實踐中，無一不體現這種思想。html

架構目標

低成本:任何公司存在的價值都是爲了獲取商業利益。在可能的狀況下，但願一切都是低成本的。
高性能:網站性能是客觀的指標，能夠具體體現到響應時間、吞吐量等技術指標。系統的響應延遲，指系統完成某一功能須要使用的時間；系統的吞吐量，指系統在某一時間能夠處理的數據總量，一般能夠用系統每秒處理的總的數據量來衡量；系統的併發能力，指系統能夠同時完成某一功能的能力，一般也用 QPS(query per second)來衡量。
高可用：系統的可用性(availability)指系統在面對各類異常時能夠正確提供服務的能力。系統的可用性可
以用系統停服務的時間與正常服務的時間的比例來衡量，也能夠用某功能的失敗次數與成功次數的比例來衡量。
易伸縮：注重線性擴展，是否能夠容易經過加入機器來處理不斷上升的用戶訪問壓力。系統的伸縮性(scalability)指分佈式系統經過擴展集羣機器規模提升系統性能（吞吐、延遲、併發）、存儲容量、計算能力的特性。
高安全：如今商業環境中，常常出現被網站被拖庫，用戶帳戶被盜等現象。網站的安全性不言而喻。

典型實現

下面典型的一次web交互請求示意圖。前端

DNS

當用戶在瀏覽器中輸入網站地址後，瀏覽器會檢查瀏覽器緩存中是否存在對應域名的解析結果。若是有，則解析過程結束；不然進入下一個步驟
瀏覽器查找操做系統緩存中是否存在這個域名的解析結果。這個緩存的內容來源就是操做系統的hosts文件。若是有，則解析過程結束；不然進入下一個步驟
前兩個步驟都是本地查找，沒有發生網絡交互。在本步驟中，會使用到在網絡配置的中DNS地址。這個地址咱們一般稱之爲LDNS（Local DNS）。操做系統會把域名發送給LDNS解析。若是解析成功，則解析過程結束；不然進入下一個步驟
LDNS將請求返回給GTLD（Global Top Level Domain）服務器，GTLD服務器查找此域名對應的Name Server域名的地址。這個Name Server一般就是你的域名提供商的服務器。Name Server根據客戶請求，返回該域名對應的IP地址和TTL(Time To Live)值。
瀏覽器根據TTL值，把這個域名對應的IP緩存在本地系統中。域名至此解析結束。

CDN

CDN（Content Delivery Network，內容分發網絡）部署在網絡提供商的機房裏面。在用戶請求網站服務時，能夠從距離本身最近的網絡提供商獲取數據。好比視頻網站和內容網站的熱點內容。java

若是須要本身搭建CDN系統，有3種主流方案能夠選擇:linux

squid是緩存服務器科班出生,本身實現了一套內存頁/磁盤頁的管理系統
varnish是以爲squid性能不行，varnish以爲linux內核已經把虛擬內存管理作得很好了，squid的畫蛇添足反而影響了性能。
nginx cache是屬於遊手好閒，得益於nginx強大的插件機制。

LB

LB(Load Balance，負載均衡)就是將負載（用戶的請求）根據某些策略，將負載分攤給多個操做單元執行。該技術能夠提供服務器的響應速度以及利用效率，避免出現單點失效。nginx

這裏回顧下前面介紹的兩個小節，其實本質上把數據分類（根據數據更新頻率，分爲動態文件，靜態文件），並把數據放在離距離用戶最近的地方。另一點就是，在DNS和CDN具體實現時，也是大量使用了負載均衡技術。git

常見的負載均衡算法由：RR（Round Robin，輪詢）,WRR（Weighted RR，加權輪詢），Random（隨機），LC（Least Connection，最少鏈接），SH（Source Hash,源址哈希）程序員

在常見的互聯網架構中，一般使用軟件負載：LVS+HAproxy+WebServer（Nginx）。在部署時，LVS，HAProxy，WebServer都會部署一個集羣，用來進行負載均衡。LVS工做在第4層，在網絡層利用IP地址進行轉發。 HAProxy工做在第7層，根據用戶的HTTP請求（好比根據URL，消息頭）來進行轉發。github

在上述實現中，一般還會使用Keepalived+VIP(虛IP) 技術。Keepalived 提供健康檢查，故障轉移，提升系統的可用性。經過VIP（配置DNS 綁定域名）的形式對網站進行訪問。web

WEB APP

前端技術：遵循基本的Web前端優化經驗，詳見Web前端優化最佳實踐及工具集錦
介紹。另外還可使用BigPipe，動態頁面靜態化，無限滾動的翻頁技術等技術提供更好的用戶體驗。另一部分就是考慮mobile技術了，這塊筆者暫時還沒涉足，就不談了。算法

後端技術：

HTTP協議：HTTP協議大概分爲請求頭，請求體，響應頭，響應體。不管是WebServer仍是ApplicationServer，不少花樣都是基於請求頭的請求路徑來玩的。
API接口:使用RESTFUL API，暴露接口。它具備以下好處：1.充分利用 HTTP 協議自己語義。2.面向資源，一目瞭然，具備自解釋性。3.無狀態，在調用一個接口（訪問、操做資源）的時候，能夠不用考慮上下文，極大的下降了複雜度。
Application Server：在Java中，爲了保證程序可以在各個廠商的AS中兼容運行，Sun公司爲制定了J2EE規範。從技術發展路徑來看， Serverlet,JSP演變都是爲了更好地方便程序員們編程。以典型的Tomcat爲例，Connector和Container組成一個 Service，多個Service組成一個Server。Connector主要負責接受外部請求，Container負責處理請求。Server提供了生命週期管理，如啓動，中止等。
Session Framework：在大型互聯網架構中，單臺機器已經存放不了用戶的登陸信息。同時爲了支持故障轉移等特性，須要一套session管理機制，支持海量用戶同時在線。一般能夠在遵循J2EE的容器內，使用Filter模式和分佈式緩存系統來實現。
MVC：即Model，View和Controller。Model表明業務邏輯，View表示頁面視圖，Controller表示根據用戶請求，執行相應的業務邏輯，並選擇適當的頁面視圖返回。用過ROR的同窗都知道，裏面的router配置了什麼樣的URL和什麼樣的action相對應。相應的，MVC的本質就是根據不一樣的URL選擇不一樣的servlet來執行。只不過，結合了Intercepting Filter提供了強大的功能而已。
IOC：至於爲何須要IOC，筆者在這篇文章進行了討論。究其本質實現，無非是反射+單例模式+Hash算法+字節碼加強+ThreadLocal。前3者用來實現對象生命週期的管理，後2者用來支持AOP，聲明式事務。
ORM：這個詞實際上放在這裏介紹不太合適，可是筆者目前沒想把它單獨拉出章節來說。根據筆者的經驗，ORM主要完成了類和表的映射，對象和一條表數據記錄的映射。其核心實現是經過jdbc獲取數據庫的meta信息，而後根據映射關係（這裏能夠經過COC（Conversion Over Configuration，約定優於配置），註解等技術來簡化配置）來動態生成sql和返回數據庫的執行結果。

SOA

網站架構的演進之路，從單一應用架構到垂直應用架構，分佈式服務架構以及流動計算架構，愈來愈體現SOA框架的重要性。這裏以優秀的開源實現dubbo爲例，簡單介紹下。

dubbo的功能介紹見服務治理過程，對dubbo架構詳細介紹的有如何學習dubbo源代碼和dubbo源代碼閱讀。

簡而言之，就是使用了spring的schema的擴展機制，進而支持自定義dubbo標籤；經過相似serviceload機制配置多個可選服務。經過jdk動態代理和Javassist，使服務調用透明化。結合ZooKeeper實現高可用元數據管理。

MQ

MQ（Message Queue，消息隊列）使服務調用異步化，能夠消除併發訪問洪峯，提高網站響應速度。在MQ實現中，筆者寫過一篇介紹Kafka的學習筆記，詳細介紹見Kafka/Metaq設計思想學習筆記，再也不多言。

CACHE

Cache就是將數據放到距離計算最近的地方，用來加快處理速度。一般對必定時間內的熱點數據進行緩存。
在使用緩存時，須要注意緩存預熱和緩存穿透問題。

通常海量數據的緩存系統不會使用Java來實現，是由於Java有額外的對象大小開銷以及GC壓力。因此通常是用ANSI C來實現。目前用的比較火的是Redis，更多介紹請查看Redis資料彙總

STORAGE

在出現NOSQL以前，一統天下的是MySQL分庫分表技術。結合相似TDDL等SQL agent技術，也可以執行相似join的操做。後來，就像忽如一晚上春風來，出現了不少NOSQL/分佈式存儲系統產品。

分佈式存儲系統是分佈式系統中最複雜的一部分，相比較SOA,CACHE等框架，它須要解決的問題更加複雜。常見的問題以下：

數據分佈在多臺服務器之間保證數據分佈均勻，跨服務器如何讀寫
一致性異常狀況下如何保證副本一致性
容錯把發生故障當成常態來設計，作到檢測是否發生故障並進行故障遷移
負載均衡新增、移除服務器時如何負載均衡數據遷移如何不影響已有服務
事務併發控制如何實現分佈式事務，如何實現多版本併發控制
壓縮、解壓縮根據數據特色選擇恰當算法，如何平衡時間和空間的關係。

當筆者閱讀完《大規模分佈式存儲系統原理解析與架構實戰》和google的兩篇存儲論文後，感受裏面的實現細節太多了。若是要寫的話，仍是後面單獨列一片把。因此這裏暫且略過。

其餘

還有其餘方面的知識，等後面積累再多些，再重點寫吧，這裏僅僅是索引下，讀者能夠自行略過。

配置數據、元數據管理系統：能夠查看這篇ZooKeeper和Diamond有什麼不一樣
搜索系統：機器學習分析用戶行爲，結合搜索進行推薦排名。各類大數據分析工具。
雲計算：硬件虛擬化。創業公司能夠購買雲服務，避免固定資產開銷，可能閒置，購買，管理，安裝費用，沒法迅速購買等問題，屬於浮動消費，相似開車和租車的區別，僅是租用服務。雲廠商在能源，製冷，運維成本，量大硬件定製，充分利用閒置資源具備優點。
鷹眼系統：日誌規範化+打點+數據分析+樹狀展示，詳細介紹能夠參考鷹眼下的淘寶-分佈式調用跟蹤系統介紹
系統運維：目標是自動化運維。
- 監控各類資源指標：
  - OS:（cpu，memory，disk（空間，讀寫次數））
  - 網絡流量
  - 中間件： tomcat， jvm，
  - MQ:經過監控生產者，broker，消費者之間的隊列狀況，動態決定增長、減小消費者
  - 服務框架自省（運維監控）依賴關係統計，前臺系統訪問路徑，
- 顯示各類監控結果：Agent —》 Explorer ，Analyze，Visual，Dashboard，Share。
- 預警，運維自動、手工降級，系統問題自動排查甚至問題自動修復，
能源節省：能源消耗（CPU,機櫃，水冷）
系統安全：涉及系統的方方面面，各類腳本，sql注入，0day等等。
版本開發、版本發佈：開發環境，測試環境，支持開速發佈，不用大的cycle，灰色發佈，回滾降級流程，周邊協調。大衆點評的有個關於開發環境搭建的，感興趣的能夠點擊打造高效的單機開發環境。
數據中心：在《程序員》2014年第一期介紹裏面，提到了阿里使用了ZONE的概念來解決橫向擴展的問題。阿里主要是爲了解決機房網絡瓶頸和超大規模系統的伸縮性問題，把完成某一特定業務須要的系統、核心服務、數據庫組合成一個業務單元。