以下內(nèi)容主要摘自Jimmy Huang《大型互聯(lián)網(wǎng)架構(gòu)概述》
大型互聯(lián)網(wǎng)架構(gòu)的特點，依舊遵循著“分而治之”的理念。下圖是目前大型互聯(lián)網(wǎng)架構(gòu)常見的邏輯架構(gòu)：
互聯(lián)網(wǎng)架構(gòu)的主要目標，是滿足以下非功能的需求：
- 低成本：主要可以用QPS（Query Per Second）指標來衡量
- 高可用
- 易伸縮
- 高安全
基于邏輯架構(gòu)圖，對整個調(diào)用過程的簡要分析如下：
1.DNS
- 當用戶在瀏覽器中輸入網(wǎng)站地址后，瀏覽器會檢查瀏覽器緩存中是否存在對應域名的解析結(jié)果。如果有，則解析過程結(jié)束；否則進入下一個步驟
- 瀏覽器查找操作系統(tǒng)緩存中是否存在這個域名的解析結(jié)果。這個緩存的內(nèi)容來源就是操作系統(tǒng)的hosts文件。如果有，則解析過程結(jié)束；否則進入下一個步驟
- 前兩個步驟都是本地查找，沒有發(fā)生網(wǎng)絡交互。在本步驟中，會使用到在網(wǎng)絡配置的中DNS地址。這個地址我們通常稱之為LDNS（Local DNS）。操作系統(tǒng)會把域名發(fā)送給LDNS解析。如果解析成功，則解析過程結(jié)束；否則進入下一個步驟
- LDNS將請求返回給GTLD（Global Top Level Domain）服務器，GTLD服務器查找此域名對應的Name Server域名的地址。這個Name Server通常就是你的域名提供商的服務器。Name Server根據(jù)客戶請求，返回該域名對應的IP地址和TTL(Time To Live)值。
- 瀏覽器根據(jù)TTL值，把這個域名對應的IP緩存在本地系統(tǒng)中。域名至此解析結(jié)束
2.CDN
CDN（Content Delivery Network，內(nèi)容分發(fā)網(wǎng)絡）部署在網(wǎng)絡提供商的機房里面。在用戶請求網(wǎng)站服務時，可以從距離自己最近的網(wǎng)絡提供商獲取數(shù)據(jù)。比如視頻網(wǎng)站和內(nèi)容網(wǎng)站的熱點內(nèi)容。
如果需要自己搭建CDN系統(tǒng)，有3種主流方案可以選擇:
- squid是緩存服務器科班出生,自己實現(xiàn)了一套內(nèi)存頁/磁盤頁的管理系統(tǒng)
- varnish是覺得squid性能不行，varnish覺得linux內(nèi)核已經(jīng)把虛擬內(nèi)存管理做得很好了，squid的多此一舉反而影響了性能。
- nginx cache是屬于不務正業(yè)，得益于nginx強大的插件機制
3.LB
LB(Load Balance，負載均衡)就是將負載（用戶的請求）根據(jù)某些策略，將負載分攤給多個操作單元執(zhí)行。該技術(shù)可以提供服務器的響應速度以及利用效率，避免出現(xiàn)單點失效。
這里回顧下前面介紹的兩個小節(jié)，其實本質(zhì)上把數(shù)據(jù)分類（根據(jù)數(shù)據(jù)更新頻率，分為動態(tài)文件，靜態(tài)文件），并把數(shù)據(jù)放在離距離用戶最近的地方。另外一點就是，在DNS和CDN具體實現(xiàn)時，也是大量使用了負載均衡技術(shù)。
常見的負載均衡算法由：RR（Round Robin，輪詢）,WRR（Weighted RR，加權(quán)輪詢），Random（隨機），LC（Least Connection，最少連接），SH（Source Hash,源址哈希）
在常見的互聯(lián)網(wǎng)架構(gòu)中，通常使用軟件負載：
- LVS+HAproxy+WebServer（Nginx）。在部署時，LVS，HAProxy，WebServer都會部署一個集群，用來進行負載均衡。LVS工作在第4層，在網(wǎng)絡層利用IP地址進行轉(zhuǎn)發(fā)。 HAProxy工作在第7層，根據(jù)用戶的HTTP請求（比如根據(jù)URL，消息頭）來進行轉(zhuǎn)發(fā)。
- 在上述實現(xiàn)中，通常還會使用Keepalived+VIP(虛IP) 技術(shù)。Keepalived 提供健康檢查，故障轉(zhuǎn)移，提高系統(tǒng)的可用性。通過VIP（配置DNS 綁定域名）的形式對網(wǎng)站進行訪問。
4.WEB APP
- 前端技術(shù)：遵循基本的Web前端優(yōu)化經(jīng)驗，詳見CSDN《Web前端優(yōu)化最佳實踐及工具集錦 》介紹。另外還可以使用BigPipe，動態(tài)頁面靜態(tài)化，無限滾動的翻頁技術(shù)等技術(shù)提供更好的用戶體驗。另外一部分就是考慮mobile技術(shù)了。
- 后端技術(shù)：
- HTTP協(xié)議：HTTP協(xié)議大概分為請求頭，請求體，響應頭，響應體。無論是WebServer還是ApplicationServer，很多花樣都是基于請求頭的請求路徑來玩的。
- API接口：使用RESTFUL API，暴露接口。它具有如下好處：
- 充分利用 HTTP 協(xié)議本身語義。
- 面向資源，一目了然，具有自解釋性。
- 無狀態(tài)，在調(diào)用一個接口（訪問、操作資源）的時候，可以不用考慮上下文，極大的降低了復雜度。
- Application Server：在Java中，為了保證程序能夠在各個廠商的Application Server中兼容運行，Sun公司為制定了J2EE規(guī)范。從技術(shù)發(fā)展路徑來看， Serverlet、JSP演變都是為了更好地方便程序員們編程。以典型的Tomcat為例，Connector和Container組成一個 Service，多個Service組成一個Server。Connector主要負責接受外部請求，Container負責處理請求。Server提供了生命周期管理，如啟動，停止等。
- Session Framework：在大型互聯(lián)網(wǎng)架構(gòu)中，單臺機器已經(jīng)存放不了用戶的登錄信息。同時為了支持故障轉(zhuǎn)移等特性，需要一套session管理機制，支持海量用戶同時在線。通常可以在遵循J2EE的容器內(nèi)，使用Filter模式和分布式緩存系統(tǒng)來實現(xiàn)。
- MVC：即Model，View和Controller。Model代表業(yè)務邏輯，View表示頁面視圖，Controller表示根據(jù)用戶請求，執(zhí)行相應的業(yè)務邏輯，并選擇適當?shù)捻撁嬉晥D返回。用過ROR的同學都知道，里面的router配置了什么樣的URL和什么樣的action相對應。相應的，MVC的本質(zhì)就是根據(jù)不同的URL選擇不同的servlet來執(zhí)行。只不過，結(jié)合了Intercepting Filter提供了強大的功能而已。
- IOC：至于為什么需要IOC，在這篇文章進行了討論。究其本質(zhì)實現(xiàn)，無非是反射+單例模式+Hash算法+字節(jié)碼增強+ThreadLocal。前3者用來實現(xiàn)對象生命周期的管理，后2者用來支持AOP，聲明式事務。
- ORM：ORM主要完成了類和表的映射，對象和一條表數(shù)據(jù)記錄的映射。其核心實現(xiàn)是通過jdbc獲取數(shù)據(jù)庫的meta信息，然后根據(jù)映射關系（這里可以通過COC（Conversion Over Configuration，約定優(yōu)于配置），注解等技術(shù)來簡化配置）來動態(tài)生成sql和返回數(shù)據(jù)庫的執(zhí)行結(jié)果。
5.SOA
網(wǎng)站架構(gòu)的演進之路，從單一應用架構(gòu)到垂直應用架構(gòu)，分布式服務架構(gòu)以及流動計算架構(gòu)，越來越體現(xiàn)SOA框架的重要性。這里以優(yōu)秀的開源實現(xiàn)dubbo為例，簡單介紹下。
dubbo的功能介紹見服務治理過程，對dubbo架構(gòu)詳細介紹的有如何學習dubbo源代碼和dubbo源代碼閱讀。
簡而言之，就是使用了spring的schema的擴展機制，進而支持自定義dubbo標簽；通過類似serviceload機制配置多個可選服務。通過jdk動態(tài)代理和Javassist，使服務調(diào)用透明化。結(jié)合ZooKeeper實現(xiàn)高可用元數(shù)據(jù)管理
6.MQ
MQ（Message Queue，消息隊列）使服務調(diào)用異步化，可以消除并發(fā)訪問洪峰，提升網(wǎng)站響應速度。 在MQ實現(xiàn)中，可以參考Kafka/Metaq設計思想學習筆記
7.CACHE
Cache就是將數(shù)據(jù)放到距離計算最近的地方，用來加快處理速度。通常對一定時間內(nèi)的熱點數(shù)據(jù)進行緩存。 在使用緩存時，需要注意緩存預熱和緩存穿透問題。
一般海量數(shù)據(jù)的緩存系統(tǒng)不會使用Java來實現(xiàn)，是因為Java有額外的對象大小開銷以及GC壓力。所以一般是用ANSI C來實現(xiàn)。目前用的比較火的是Redis，更多介紹請查看Redis資料匯總
**8.Storage **
在出現(xiàn)NOSQL之前，一統(tǒng)天下的是MySQL分庫分表技術(shù)。結(jié)合類似TDDL等SQL agent技術(shù)，也能夠執(zhí)行類似join的操作。后來，就像忽如一夜春風來，出現(xiàn)了很多NOSQL/分布式存儲系統(tǒng)產(chǎn)品。
分布式存儲系統(tǒng)是分布式系統(tǒng)中最復雜的一部分，相比較SOA,CACHE等框架，它需要解決的問題更加復雜。常見的問題如下：
- 數(shù)據(jù)分布 在多臺服務器之間保證數(shù)據(jù)分布均勻，跨服務器如何讀寫
- 一致性 異常情況下如何保證副本一致性
- 容錯 把發(fā)生故障當成常態(tài)來設計，做到檢測是否發(fā)生故障并進行故障遷移
- 負載均衡 新增、移除服務器時如何負載均衡 數(shù)據(jù)遷移如何不影響已有服務
- 事務并發(fā)控制 如何實現(xiàn)分布式事務，如何實現(xiàn)多版本并發(fā)控制
- 壓縮、解壓縮 根據(jù)數(shù)據(jù)特點選擇恰當算法，如何平衡時間和空間的關系。
延伸理解可閱讀《大規(guī)模分布式存儲系統(tǒng)原理解析與架構(gòu)實戰(zhàn)》和google的兩篇存儲論文。
其它
- 配置數(shù)據(jù)、元數(shù)據(jù)管理系統(tǒng)：可以查看這篇ZooKeeper和Diamond有什么不同
- 搜索系統(tǒng)：機器學習分析用戶行為，結(jié)合搜索進行推薦排名。 各種大數(shù)據(jù)分析工具。
- 云計算：硬件虛擬化。創(chuàng)業(yè)公司可以購買云服務，避免固定資產(chǎn)開銷，可能閑置， 購買，管理，安裝費用 ，無法迅速購買等問題，屬于浮動消費，類似開車和租車的區(qū)別，僅是租用服務。 云廠商在能源，制冷，運維成本，量大硬件定制，充分利用閑置資源具有優(yōu)勢。
- 鷹眼系統(tǒng)：日志規(guī)范化+打點+數(shù)據(jù)分析+樹狀展現(xiàn)，詳細介紹可以參考 鷹眼下的淘寶-分布式調(diào)用跟蹤系統(tǒng)介紹
- 系統(tǒng)運維： 目標是自動化運維。監(jiān)控各種資源指標：
- OS:（cpu，memory，disk（空間，讀寫次數(shù)））
- 網(wǎng)絡流量
- 中間件： tomcat， jvm，
- MQ:通過監(jiān)控生產(chǎn)者，broker，消費者之間的隊列情況，動態(tài)決定增加、減少消費者
- 服務框架自省（運維監(jiān)控） 依賴關系統(tǒng)計，前臺系統(tǒng)訪問路徑，
- 顯示各種監(jiān)控結(jié)果：Agent —》 Explorer ，Analyze，Visual，Dashboard，Share。
- 預警，運維 自動、手工降級，系統(tǒng)問題自動排查甚至問題自動修復，
- 能源節(jié)省：能源消耗（CPU、機柜、水冷）
- 系統(tǒng)安全：涉及系統(tǒng)的方方面面，各種腳本，sql注入，0day等等。
- 版本開發(fā)、版本發(fā)布：開發(fā)環(huán)境，測試環(huán)境，支持開速發(fā)布，短周期，灰度發(fā)布，藍綠發(fā)布、回滾降級流程、周邊協(xié)調(diào)。 大眾點評的有個關于開發(fā)環(huán)境搭建的，感興趣的可以點擊打造高效的單機開發(fā)環(huán)境。
- 數(shù)據(jù)中心：在《程序員》2014年第一期介紹里面，提到了阿里使用了ZONE的概念來解決橫向擴展的問題。阿里主要是為了解決機房網(wǎng)絡瓶頸和超大規(guī)模系統(tǒng)的伸縮性問題，把完成某一特定業(yè)務需要的系統(tǒng)、核心服務、數(shù)據(jù)庫組合成一個業(yè)務單元
