網站架構方案全解析

時間 2019-11-16

原文原文鏈接

一、HTML靜態化其實你們都知道，效率最高、消耗最小的就是純靜態化的html頁面，因此咱們儘量使咱們的網站上的頁面採用靜態頁面來實現，這個最簡單的方法其實也是最有效的方法。可是對於大量內容而且頻繁更新的網站，咱們沒法所有手動去挨個實現，因而出現了咱們常見的信息發佈系統CMS，像咱們常訪問的各個門戶站點的新聞頻道，甚至他們的其餘頻道，都是經過信息發佈系統來管理和實現的，信息發佈系統能夠實現最簡單的信息錄入自動生成靜態頁面，還能具有頻道管理、權限管理、自動抓取等功能，對於一個大型網站來講，擁有一套高效、可管理的CMS是必不可少的。除了門戶和信息發佈類型的網站，對於交互性要求很高的社區類型網站來講，儘量的靜態化也是提升性能的必要手段，將社區內的帖子、文章進行實時的靜態化，有更新的時候再從新靜態化也是大量使用的策略，像Mop的大雜燴就是使用了這樣的策略，網易社區等也是如此。同時，html靜態化也是某些緩存策略使用的手段，對於系統中頻繁使用數據庫查詢可是內容更新很小的應用，能夠考慮使用html靜態化來實現，好比論壇中論壇的公用設置信息，這些信息目前的主流論壇均可以進行後臺管理而且存儲再數據庫中，這些信息其實大量被前臺程序調用，可是更新頻率很小，能夠考慮將這部份內容進行後臺更新的時候進行靜態化，這樣避免了大量的數據庫訪問請求。php

二、圖片服務器分離你們知道，對於Web服務器來講，無論是Apache、IIS仍是其餘容器，圖片是最消耗資源的，因而咱們有必要將圖片與頁面進行分離，這是基本上大型網站都會採用的策略，他們都有獨立的圖片服務器，甚至不少臺圖片服務器。這樣的架構能夠下降提供頁面訪問請求的服務器系統壓力，而且能夠保證系統不會由於圖片問題而崩潰，在應用服務器和圖片服務器上，能夠進行不一樣的配置優化，好比apache在配置ContentType的時候能夠儘可能少支持，儘量少的LoadModule，保證更高的系統消耗和執行效率。html

三、數據庫集羣和庫表散列大型網站都有複雜的應用，這些應用必須使用數據庫，那麼在面對大量訪問的時候，數據庫的瓶頸很快就能顯現出來，這時一臺數據庫將很快沒法知足應用，因而咱們須要使用數據庫集羣或者庫表散列。在數據庫集羣方面，不少數據庫都有本身的解決方案，Oracle、Sybase等都有很好的方案，經常使用的MySQL提供的Master/Slave也是相似的方案，您使用了什麼樣的DB，就參考相應的解決方案來實施便可。上面提到的數據庫集羣因爲在架構、成本、擴張性方面都會受到所採用DB類型的限制，因而咱們須要從應用程序的角度來考慮改善系統架構，庫表散列是經常使用而且最有效的解決方案。咱們在應用程序中安裝業務和應用或者功能模塊將數據庫進行分離，不一樣的模塊對應不一樣的數據庫或者表，再按照必定的策略對某個頁面或者功能進行更小的數據庫散列，好比用戶表，按照用戶ID進行表散列，這樣就可以低成本的提高系統的性能而且有很好的擴展性。sohu的論壇就是採用了這樣的架構，將論壇的用戶、設置、帖子等信息進行數據庫分離，而後對帖子、用戶按照板塊和ID進行散列數據庫和表，最終能夠在配置文件中進行簡單的配置便能讓系統隨時增長一臺低成本的數據庫進來補充系統性能。前端

四、緩存一詞搞技術的都接觸過，不少地方用到緩存。網站架構和網站開發中的緩存也是很是重要。這裏先講述最基本的兩種緩存。高級和分佈式的緩存在後面講述。架構方面的緩存，對Apache比較熟悉的人都能知道Apache提供了本身的緩存模塊，也可使用外加的Squid模塊進行緩存，這兩種方式都可以有效的提升Apache的訪問響應能力。網站程序開發方面的緩存，Linux上提供的Memory Cache是經常使用的緩存接口，能夠在web開發中使用，好比用Java開發的時候就能夠調用MemoryCache對一些數據進行緩存和通信共享，一些大型社區使用了這樣的架構。另外，在使用web語言開發的時候，各類語言基本都有本身的緩存模塊和方法，PHP有Pear的Cache模塊，Java就更多了，.net不是很熟悉，相信也確定有。java

五、鏡像是大型網站常採用的提升性能和數據安全性的方式，鏡像的技術能夠解決不一樣網絡接入商和地域帶來的用戶訪問速度差別，好比 ChinaNet和EduNet之間的差別就促使了不少網站在教育網內搭建鏡像站點，數據進行定時更新或者實時更新。在鏡像的細節技術方面，這裏不闡述太深，有不少專業的現成的解決架構和產品可選。也有廉價的經過軟件實現的思路，好比Linux上的rsync等工具。node

六、負載均衡將是大型網站解決高負荷訪問和大量併發請求採用的終極解決辦法。負載均衡技術發展了多年，有不少專業的服務提供商和產品能夠選擇，我我的接觸過一些解決方法，其中有兩個架構能夠給你們作參考。python

七、硬件四層交換第四層交換使用第三層和第四層信息包的報頭信息，根據應用區間識別業務流，將整個區間段的業務流分配到合適的應用服務器進行處理。第四層交換功能就象是虛 IP，指向物理服務器。它傳輸的業務服從的協議多種多樣，有HTTP、FTP、NFS、Telnet或其餘協議。這些業務在物理服務器基礎上，須要複雜的載量平衡算法。在IP世界，業務類型由終端TCP或UDP端口地址來決定，在第四層交換中的應用區間則由源端和終端IP地址、TCP和UDP端口共同決定。在硬件四層交換產品領域，有一些知名的產品能夠選擇，好比Alteon、F5等，這些產品很昂貴，可是物有所值，可以提供很是優秀的性能和很靈活的管理能力。Yahoo中國當初接近2000臺服務器使用了三四臺Alteon就搞定了。mysql

八、軟件四層交換你們知道了硬件四層交換機的原理後，基於OSI模型來實現的軟件四層交換也就應運而生，這樣的解決方案實現的原理一致，不過性能稍差。可是知足必定量的壓力仍是遊刃有餘的，有人說軟件實現方式其實更靈活，處理能力徹底看你配置的熟悉能力。軟件四層交換咱們可使用Linux上經常使用的LVS來解決，LVS就是Linux Virtual Server，他提供了基於心跳線heartbeat的實時災難應對解決方案，提升系統的魯棒性，同時可供了靈活的虛擬VIP配置和管理功能，能夠同時知足多種應用需求，這對於分佈式的系統來講必不可少。一個典型的使用負載均衡的策略就是，在軟件或者硬件四層交換的基礎上搭建squid集羣，這種思路在不少大型網站包括搜索引擎上被採用，這樣的架構低成本、高性能還有很強的擴張性，隨時往架構裏面增減節點都很是容易。這樣的架構我準備空了專門詳細整理一下和你們探討。對於大型網站來講，前面提到的每一個方法可能都會被同時使用到，我這裏介紹得比較淺顯，具體實現過程當中不少細節還須要你們慢慢熟悉和體會，有時一個很小的squid參數或者apache參數設置，對於系統性能的影響就會很大，但願你們一塊兒討論，達到拋磚引玉之效。linux

2nginx

用squid作web cache server，而apache在squid的後面提供真正的web服務。固然使用這樣的架構必需要保證主頁上大部分都是靜態頁面。這就須要程序員的配合將頁面在反饋給客戶端以前將頁面所有轉換成靜態頁面。程序員

基本看出sina和sohu對於頻道等欄目都用了相同的技術，即squid來監聽這些IP的80端口，而真正的web server來監聽另一個端口。從用戶的感受上來講不會有任何的區別，而相對於將web server直接和客戶端連在一塊兒的方式，這樣的方式明顯的節省的帶寬和服務器。用戶訪問的速度感受也會更快。

實例：Yupoo! 的網站技術架構

帶寬：4000M/S

服務器數量：60 臺左右

Web服務器：Lighttpd, Apache, nginx

應用服務器：Tomcat

其餘：Python, Java, MogileFS 、ImageMagick 等

首先看一下網站的架構圖：

該架構圖給出了很好的概覽(點擊能夠查看在 Yupoo! 上的大圖和原圖，請注意該圖版權信息)。

關於 Squid 與 Tomcat

Squid 與 Tomcat 彷佛在 Web 2.0 站點的架構中較少看到。我首先是對 Squid 有點疑問，對此阿華的解釋是"目前暫時還沒找到效率比 Squid 高的緩存系統，原來命中率的確不好，後來在 Squid 前又裝了層 Lighttpd, 基於 url 作 hash, 同一個圖片始終會到同一臺 squid 去，因此命中率完全提升了"

對於應用服務器層的 Tomcat，如今 Yupoo! 技術人員也在逐漸用其餘輕量級的東西替代，而 YPWS/YPFS 如今已經用 Python 進行開發了。

名次解釋：

YPWS--Yupoo Web Server YPWS 是用 Python開發的一個小型 Web 服務器，提供基本的 Web 服務外，能夠增長針對用戶、圖片、外鏈網站顯示的邏輯判斷，能夠安裝於任何有空閒資源的服務器中，遇到性能瓶頸時方便橫向擴展。
YPFS--Yupoo File System 與 YPWS 相似，YPFS 也是基於這個 Web 服務器上開發的圖片上傳服務器。

【Updated: 有網友留言質疑 Python 的效率，Yupoo 老大劉平陽在 del.icio.us 上寫到 "YPWS用Python本身寫的，每臺機器每秒能夠處理294個請求, 如今壓力幾乎都在10%如下"】

圖片處理層

接下來的 Image Process Server 負責處理用戶上傳的圖片。使用的軟件包也是 ImageMagick，在上次存儲升級的同時，對於銳化的比率也調整過了(我我的感受，效果的確好了不少)。」Magickd「是圖像處理的一個遠程接口服務，能夠安裝在任何有空閒 CPU資源的機器上，相似 Memcached的服務方式。

咱們知道 Flickr 的縮略圖功能原來是用 ImageMagick 軟件包的，後來被雅虎收購後出於版權緣由而不用了(?);EXIF 與 IPTC Flicke 是用 Perl 抽取的，我是很是建議 Yupoo! 針對 EXIF 作些文章，這也是潛在產生受益的一個重點。

圖片存儲層

原來 Yupoo! 的存儲採用了磁盤陣列櫃，基於 NFS 方式的，隨着數據量的增大，」Yupoo! 開發部從07年6月份就開始着手研究一套大容量的、能知足 Yupoo! 從此發展須要的、安全可靠的存儲系統「，看來 Yupoo! 系統比較有信心，也是滿懷期待的，畢竟這要支撐以 TB 計算的海量圖片的存儲和管理。咱們知道，一張圖片除了原圖外，還有不一樣尺寸的，這些圖片統一存儲在 MogileFS 中。

對於其餘部分，常見的 Web 2.0 網站必須軟件都能看到，如 MySQL、Memcached 、Lighttpd 等。Yupoo! 一方面採用很多相對比較成熟的開源軟件，一方面也在自行開發定製適合本身的架構組件。這也是一個 Web 2.0 公司所必須要走的一個途徑。

很是感謝一下 Yupoo! 阿華對於技術信息的分享，技術是共通的。下一個能爆料是哪家?

--EOF--

lighttpd+squid這套緩存是放在另一個機房做爲cdn的一個節點使用的，圖中沒描繪清楚，給你們帶來不便了。

squid前端用lighttpd沒用nginx，主要是用了這麼久，沒出啥大問題，因此就沒想其餘的了。

URL Hash的擴展性的確很差，能作的就是不輕易去增減服務器，咱們目前是5臺服務器作一組hash.

咱們如今用Python寫的Web Server，在效率方面，我能夠給個測試數據，根據目前的訪問日誌模擬訪問測試的結果是1臺ypws,平均每秒處理294個請求(加載全部的邏輯判斷)。

在可靠性上，還不沒具體的數據，目前運行1個多月尚未任何異常。

lvs每一個節點上都裝nginx，主要是爲了反向代理及處理靜態內容，不過apache已顯得不是那麼必需，準備逐漸去掉。

咱們處理圖片都是即時的，咱們目前半數以上的服務器都裝了magickd服務，用來分擔圖片處理請求。

實例：Tailrank 網站架構

天天數以千萬計的 Blog 內容中，實時的熱點是什麼? Tailrank 這個 Web 2.0 Startup 致力於回答這個問題。

專門爆料網站架構的 Todd Hoff 對 Kevin Burton 進行了採訪。因而咱們能瞭解一下 Tailrank 架構的一些信息。每小時索引 2400 萬的 Blog 與 Feed，內容處理能力爲 160-200Mbps，IO 寫入大約在10-15MBps。每月要處理 52T 之多的原始數據。Tailrank 所用的爬蟲如今已經成爲一個獨立產品：spinn3r

服務器硬件

目前大約 15 臺服務器，CPU 是 64 位的 Opteron。每臺主機上掛兩個 SATA 盤，作 RAID 0。據我所知，國內不少 Web 2.0 公司也用的是相似的方式，SATA 盤容量達，低廉價格，堪稱不二之選。操做系統用的是 Debian Linux 。Web 服務器用 Apache 2.0，Squid 作反向代理服務器。

數據庫

Tailrank 用 MySQL 數據庫，聯邦數據庫形式。存儲引擎用 InnoDB，數據量 500GB。Kevin Burton 也指出了 MySQL 5 在修了一些多核模式下互斥鎖的問題(This Bug?)。到數據庫的JDBC 驅動鏈接池用 lbpool 作負載均衡。MySQL Slave 或者 Master的複製用 MySQLSlaveSync 來輕鬆完成。不過即便這樣，還要花費 20%的時間來折騰 DB。

其餘開放的軟件

任何一套系統都離不開合適的 Profiling 工具，Tailrank 也不利外，針對 Java 程序的 Benchmark 用 Benchmark4j。Log 工具用 Log5j(不是 Log4j)。Tailrank 所用的大部分工具都是開放的。

Tailrank 的一個比較大的競爭對手是 Techmeme，雖然兩者暫時看面向內容的側重點有所不一樣。其實，最大的對手仍是本身，當須要挖掘的信息量愈來愈大，若是精準並及時的呈現給用戶內容的成本會愈來愈高。從如今來看，Tailrank 離預期目標還差的很遠。期待羅馬早日建成

YouTube架構學習

原文: YouTube Architecture

YouTube發展迅速，天天超過1億的視頻點擊量，但只有不多人在維護站點和確保伸縮性。

平臺

Apache
Python
Linux(SuSe)
MySQL
psyco，一個動態的Python到C的編譯器
lighttpd代替Apache作視頻查看

狀態

支持天天超過1億的視頻點擊量
成立於2005年2月
於2006年3月達到天天3千萬的視頻點擊量
於2006年7月達到天天1億的視頻點擊量
2個系統管理員，2個伸縮性軟件架構師
2個軟件開發工程師，2個網絡工程師，1個DBA
處理飛速增加的流量

Java代碼

1. while (true)
2. {
3. identify_and_fix_bottlenecks();
4. drink();
5. sleep();
6. notice_new_bottleneck();
7. }
while (true)
{
identify_and_fix_bottlenecks();
drink();
sleep();
notice_new_bottleneck();
}

天天運行該循環屢次

Web服務器

NetScaler用於負載均衡和靜態內容緩存
使用mod_fast_cgi運行Apache
使用一個Python應用服務器來處理請求的路由
應用服務器與多個數據庫和其餘信息源交互來獲取數據和格式化html頁面
通常能夠經過添加更多的機器來在Web層提升伸縮性
Python的Web層代碼一般不是性能瓶頸，大部分時間阻塞在RPC
Python容許快速而靈活的開發和部署
一般每一個頁面服務少於100毫秒的時間
使用psyco(一個相似於JIT編譯器的動態的Python到C的編譯器)來優化內部循環
對於像加密等密集型CPU活動，使用C擴展
對於一些開銷昂貴的塊使用預先生成並緩存的html
數據庫裏使用行級緩存
緩存完整的Python對象
有些數據被計算出來併發送給各個程序，因此這些值緩存在本地內存中。這是個使用不當的策略。應用服務器裏最快的緩存將預先計算的值發送給全部服務器也花不了多少時間。只需弄一個代理來監聽更改，預計算，而後發送。

視頻服務

1，花費包括帶寬，硬件和能源消耗

2，每一個視頻由一個迷你集羣來host，每一個視頻被超過一臺機器持有

3，使用一個集羣意味着：

-更多的硬盤來持有內容意味着更快的速度

-failover。若是一臺機器出故障了，另外的機器能夠繼續服務

-在線備份

4，使用lighttpd做爲Web服務器來提供視頻服務：

-Apache開銷太大

-使用epoll來等待多個fds

-從單進程配置轉變爲多進程配置來處理更多的鏈接

5，大部分流行的內容移到CDN：

-CDN在多個地方備分內容，這樣內容離用戶更近的機會就會更高

-CDN機器常常內存不足，由於內容太流行以至不多有內容進出內存的顛簸

6，不太流行的內容(天天1-20瀏覽次數)在許多colo站點使用YouTube服務器

-長尾效應。一個視頻能夠有多個播放，可是許多視頻正在播放。隨機硬盤塊被訪問

-在這種狀況下緩存不會很好，因此花錢在更多的緩存上可能沒太大意義。

-調節RAID控制並注意其餘低級問題

-調節每臺機器上的內存，不要太多也不要太少

視頻服務關鍵點

1，保持簡單和廉價

2，保持簡單網絡路徑，在內容和用戶間不要有太多設備

3，使用經常使用硬件，昂貴的硬件很難找到幫助文檔

4，使用簡單而常見的工具，使用構建在Linux裏或之上的大部分工具

5，很好的處理隨機查找(SATA，tweaks)

縮略圖服務

1，作到高效使人驚奇的難

2，每一個視頻大概4張縮略圖，因此縮略圖比視頻多不少

3，縮略圖僅僅host在幾個機器上

4，持有一些小東西所遇到的問題：

-OS級別的大量的硬盤查找和inode和頁面緩存問題

-單目錄文件限制，特別是Ext3，後來移到多分層的結構。內核2.6的最近改進可能讓Ext3容許大目錄，但在一個文件系統裏存儲大量文件不是個好主意

-每秒大量的請求，由於Web頁面可能在頁面上顯示60個縮略圖

-在這種高負載下Apache表現的很是糟糕

-在Apache前端使用squid，這種方式工做了一段時間，可是因爲負載繼續增長而以失敗了結。它讓每秒300個請求變爲20個

-嘗試使用lighttpd可是因爲使用單線程它陷於困境。遇到多進程的問題，由於它們各自保持本身單獨的緩存

-如此多的圖片以至一臺新機器只能接管24小時

-重啓機器須要6-10小時來緩存

5，爲了解決全部這些問題YouTube開始使用Google的BigTable，一個分佈式數據存儲：

-避免小文件問題，由於它將文件收集到一塊兒

-快，錯誤容忍

-更低的延遲，由於它使用分佈式多級緩存，該緩存與多個不一樣collocation站點工做

-更多信息參考Google Architecture，GoogleTalk Architecture和BigTable

數據庫

1，早期

-使用MySQL來存儲元數據，如用戶，tags和描述

-使用一整個10硬盤的RAID 10來存儲數據

-依賴於信用卡因此YouTube租用硬件

-YouTube通過一個常見的革命：單服務器，而後單master和多read slaves，而後數據庫分區，而後sharding方式

-痛苦與備份延遲。master數據庫是多線程的而且運行在一個大機器上因此它能夠處理許多工做，slaves是單線程的而且一般運行在小一些的服務器上而且備份是異步的，因此slaves會遠遠落後於master

-更新引發緩存失效，硬盤的慢I/O致使慢備份

-使用備份架構須要花費大量的money來得到增長的寫性能

-YouTube的一個解決方案是經過把數據分紅兩個集羣來將傳輸分出優先次序：一個視頻查看池和一個通常的集羣

2，後期

-數據庫分區

-分紅shards，不一樣的用戶指定到不一樣的shards

-擴散讀寫

-更好的緩存位置意味着更少的IO

-致使硬件減小30%

-備份延遲下降到0

-如今能夠任意提高數據庫的伸縮性

數據中心策略

1，依賴於信用卡，因此最初只能使用受管主機提供商

2，受管主機提供商不能提供伸縮性，不能控制硬件或使用良好的網絡協議

3，YouTube改成使用colocation arrangement。如今YouTube能夠自定義全部東西而且協定本身的契約

4，使用5到6個數據中心加CDN

5，視頻來自任意的數據中心，不是最近的匹配或其餘什麼。若是一個視頻足夠流行則移到CDN

6，依賴於視頻帶寬而不是真正的延遲。能夠來自任何colo

7，圖片延遲很嚴重，特別是當一個頁面有60張圖片時

8，使用BigTable將圖片備份到不一樣的數據中心，代碼查看誰是最近的

學到的東西

1，Stall for time。創造性和風險性的技巧讓你在短時間內解決問題而同時你會發現長期的解決方案

2，Proioritize。找出你的服務中核心的東西並對你的資源分出優先級別

3，Pick your battles。別怕將你的核心服務分出去。YouTube使用CDN來分佈它們最流行的內容。建立本身的網絡將花費太多時間和太多money

4，Keep it simple!簡單容許你更快的從新架構來回應問題

5，Shard。Sharding幫助隔離存儲，CPU，內存和IO，不只僅是得到更多的寫性能

6，Constant iteration on bottlenecks：

-軟件：DB，緩存

-OS：硬盤I/O

-硬件：內存，RAID

7，You succeed as a team。擁有一個跨越條律的瞭解整個系統並知道系統內部是什麼樣的團隊，如安裝打印機，安裝機器，安裝網絡等等的人。With a good team all things are possible。

Google是伸縮性的王者。Google一直的目標就是構建高性能高伸縮性的基礎組織來支持它們的產品。

平臺

Linux

大量語言：Python，Java，C++

狀態

在2006年大約有450,000臺廉價服務器

在2005年Google索引了80億Web頁面，如今沒有人知道數目

目前在Google有超過200個GFS集羣。一個集羣能夠有1000或者甚至5000臺機器。成千上萬的機器從運行着5000000000000000字節存儲的GFS集羣獲取數據，集羣總的讀寫吞吐量能夠達到每秒40兆字節

目前在Google有6000個MapReduce程序，並且每月都寫成百個新程序

BigTable伸縮存儲幾十億的URL，幾百千千兆的衛星圖片和幾億用戶的參數選擇

堆棧

Google形象化它們的基礎組織爲三層架構：

1，產品：搜索，廣告，email，地圖，視頻，聊天，博客

2，分佈式系統基礎組織：GFS，MapReduce和BigTable

3，計算平臺：一羣不一樣的數據中內心的機器

4，確保公司裏的人們部署起來開銷很小

5，花費更多的錢在避免丟失日誌數據的硬件上，其餘類型的數據則花費較少

可信賴的存儲機制GFS(Google File System)

1，可信賴的伸縮性存儲是任何程序的核心需求。GFS就是Google的核心存儲平臺

2，Google File System - 大型分佈式結構化日誌文件系統，Google在裏面扔了大量的數據

3，爲何構建GFS而不是利用已有的東西?由於能夠本身控制一切而且這個平臺與別的不同，Google須要：

-跨數據中心的高可靠性

-成千上萬的網絡節點的伸縮性

-大讀寫帶寬的需求

-支持大塊的數據，可能爲上千兆字節

-高效的跨節點操做分發來減小瓶頸

4，系統有Master和Chunk服務器

-Master服務器在不一樣的數據文件裏保持元數據。數據以64MB爲單位存儲在文件系統中。客戶端與Master服務器交流來在文件上作元數據操做而且找到包含用戶須要數據的那些Chunk服務器

-Chunk服務器在硬盤上存儲實際數據。每一個Chunk服務器跨越3個不一樣的Chunk服務器備份以建立冗餘來避免服務器崩潰。一旦被Master服務器指明，客戶端程序就會直接從Chunk服務器讀取文件

6，一個上線的新程序可使用已有的GFS集羣或者能夠製做本身的GFS集羣

7，關鍵點在於有足夠的基礎組織來讓人們對本身的程序有所選擇，GFS能夠調整來適應個別程序的需求

使用MapReduce來處理數據

1，如今你已經有了一個很好的存儲系統，你該怎樣處理如此多的數據呢?好比你有許多TB的數據存儲在1000臺機器上。數據庫不能伸縮或者伸縮到這種級別花費極大，這就是MapReduce出現的緣由

2，MapReduce是一個處理和生成大量數據集的編程模型和相關實現。用戶指定一個map方法來處理一個鍵/值對來生成一箇中間的鍵/值對，還有一個reduce方法來合併全部關聯到一樣的中間鍵的中間值。許多真實世界的任務均可以使用這種模型來表現。以這種風格來寫的程序會自動並行的在一個大量機器的集羣裏運行。運行時系統照顧輸入數據劃分、程序在機器集之間執行的調度、機器失敗處理和必需的內部機器交流等細節。這容許程序員沒有多少並行和分佈式系統的經驗就能夠很容易使用一個大型分佈式系統資源

3，爲何使用MapReduce?

-跨越大量機器分割任務的好方式

-處理機器失敗

-能夠與不一樣類型的程序工做，例如搜索和廣告。幾乎任何程序都有map和reduce類型的操做。你能夠預先計算有用的數據、查詢字數統計、對TB的數據排序等等

4，MapReduce系統有三種不一樣類型的服務器

-Master服務器分配用戶任務到Map和Reduce服務器。它也跟蹤任務的狀態

-Map服務器接收用戶輸入並在其基礎上處理map操做。結果寫入中間文件

-Reduce服務器接收Map服務器產生的中間文件並在其基礎上處理reduce操做

5，例如，你想在全部Web頁面裏的字數。你將存儲在GFS裏的全部頁面拋入MapReduce。這將在成千上萬臺機器上同時進行而且全部的調整、工做調度、失敗處理和數據傳輸將自動完成

-步驟相似於：GFS -> Map -> Shuffle -> Reduction -> Store Results back into GFS

-在MapReduce裏一個map操做將一些數據映射到另外一箇中，產生一個鍵值對，在咱們的例子裏就是字和字數

-Shuffling操做彙集鍵類型

-Reduction操做計算全部鍵值對的綜合併產生最終的結果

6，Google索引操做管道有大約20個不一樣的map和reduction。

7，程序能夠很是小，如20到50行代碼

8，一個問題是掉隊者。掉隊者是一個比其餘程序慢的計算，它阻塞了其餘程序。掉隊者可能由於緩慢的IO或者臨時的CPU不能使用而發生。解決方案是運行多個一樣的計算而且當一個完成後殺死全部其餘的

9，數據在Map和Reduce服務器之間傳輸時被壓縮了。這能夠節省帶寬和I/O。

在BigTable裏存儲結構化數據

1，BigTable是一個大伸縮性、錯誤容忍、自管理的系統，它包含千千兆的內存和1000000000000000的存儲。它能夠每秒鐘處理百萬的讀寫

2，BigTable是一個構建於GFS之上的分佈式哈希機制。它不是關係型數據庫。它不支持join或者SQL類型查詢

3，它提供查詢機制來經過鍵訪問結構化數據。GFS存儲存儲不透明的數據而許多程序需求有結構化數據

4，商業數據庫不能達到這種級別的伸縮性而且不能在成千上萬臺機器上工做

5，經過控制它們本身的低級存儲系統Google獲得更多的控制權來改進它們的系統。例如，若是它們想讓跨數據中心的操做更簡單這個特性，它們能夠內建它

6，系統運行時機器能夠自由的增刪而整個系統保持工做

7，每一個數據條目存儲在一個格子裏，它能夠經過一個行key和列key或者時間戳來訪問

8，每一行存儲在一個或多個tablet中。一個tablet是一個64KB塊的數據序列而且格式爲SSTable

9，BigTable有三種類型的服務器：

-Master服務器分配tablet服務器，它跟蹤tablet在哪裏而且若是須要則從新分配任務

-Tablet服務器爲tablet處理讀寫請求。當tablet超過大小限制(一般是100MB-200MB)時它們拆開tablet。當一個Tablet服務器失敗時，則100個Tablet服務器各自挑選一個新的tablet而後系統恢復。

-Lock服務器造成一個分佈式鎖服務。像打開一個tablet來寫、Master調整和訪問控制檢查等都須要互斥

10，一個locality組能夠用來在物理上將相關的數據存儲在一塊兒來獲得更好的locality選擇

11，tablet儘量的緩存在RAM裏

硬件

1，當你有不少機器時你怎樣組織它們來使得使用和花費有效?

2，使用很是廉價的硬件

3，A 1,000-fold computer power increase can be had for a 33 times lower cost if you you use a failure-prone infrastructure rather than an infrastructure built on highly reliable components. You must build reliability on top of unreliability for this strategy to work.

4，Linux，in-house rack design，PC主板，低端存儲

5，Price per wattage on performance basis isn't getting better. Have huge power and cooling issues

6，使用一些collocation和Google本身的數據中心

其餘

1，迅速更改而不是等待QA

2，庫是構建程序的卓越方式

3，一些程序做爲服務提供

4，一個基礎組織處理程序的版本，這樣它們能夠發佈而不用懼怕會破壞什麼東西

Google未來的方向

1，支持地理位置分佈的集羣

2，爲全部數據建立一個單獨的全局名字空間。當前的數據由集羣分離

3，更多和更好的自動化數據遷移和計算

4，解決當使用網絡劃分來作廣闊區域的備份時的一致性問題(例如保持服務即便一個集羣離線維護或因爲一些損耗問題)

學到的東西

1，基礎組織是有競爭性的優點。特別是對Google而言。Google能夠很快很廉價的推出新服務，而且伸縮性其餘人很難達到。許多公司採起徹底不一樣的方式。許多公司認爲基礎組織開銷太大。Google認爲本身是一個系統工程公司，這是一個新的看待軟件構建的方式

2，跨越多個數據中心仍然是一個未解決的問題。大部分網站都是一個或者最多兩個數據中心。咱們不得不認可怎樣在一些數據中心之間完整的分佈網站是很須要技巧的

3，若是你本身沒有時間從零開始從新構建全部這些基礎組織你能夠看看Hadoop。Hadoop是這裏不少一樣的主意的一個開源實現

4，平臺的一個優勢是初級開發人員能夠在平臺的基礎上快速而且放心的建立健全的程序。若是每一個項目都須要發明一樣的分佈式基礎組織的輪子，那麼你將陷入困境由於知道怎樣完成這項工做的人相對較少

5，協同工做不一直是擲骰子。經過讓系統中的全部部分一塊兒工做則一個部分的改進將幫助全部的部分。改進文件系統則每一個人從中受益並且是透明的。若是每一個項目使用不一樣的文件系統則在整個堆棧中享受不到持續增長的改進

6，構建自管理系統讓你不必讓系統關機。這容許你更容易在服務器之間平衡資源、動態添加更大的容量、讓機器離線和優雅的處理升級

7，建立可進化的基礎組織，並行的執行消耗時間的操做並採起較好的方案

8，不要忽略學院。學院有許多沒有轉變爲產品的好主意。Most of what Google has done has prior art, just not prior large scale deployment.

9，考慮壓縮。當你有許多CPU而IO有限時壓縮是一個好的選擇。

實例：Lighttpd+Squid+Apache搭建高效率Web服務器

架構原理

Apache一般是開源界的首選Web服務器，由於它的強大和可靠，已經具備了品牌效應，能夠適用於絕大部分的應用場合。可是它的強大有時候卻顯得笨重，配置文件得讓人望而生畏，高併發狀況下效率不過高。而輕量級的Web服務器Lighttpd倒是後起之秀，其靜態文件的響應能力遠高於 Apache，聽說是Apache的2-3倍。Lighttpd的高性能和易用性，足以打動咱們，在它可以勝任的領域，儘可能用它。Lighttpd對 PHP的支持也很好，還能夠經過Fastcgi方式支持其餘的語言，好比Python。

畢竟Lighttpd是輕量級的服務器，功能上不能跟Apache比，某些應用沒法勝任。好比Lighttpd還不支持緩存，而如今的絕大部分站點都是用程序生成動態內容，沒有緩存的話即便程序的效率再高也很難知足大訪問量的需求，並且讓程序不停的去作同一件事情也實在沒有意義。首先，Web程序是須要作緩存處理的，即把反覆使用的數據作緩存。即便這樣也還不夠，單單是啓動Web處理程序的代價就很多，緩存最後生成的靜態頁面是必不可少的。而作這個是 Squid的強項，它本是作代理的，支持高效的緩存，能夠用來給站點作反向代理加速。把Squid放在Apache或者Lighttpd的前端來緩存 Web服務器生成的動態內容，而Web應用程序只須要適當地設置頁面實效時間便可。

即便是大部份內容動態生成的網站，仍免不了會有一些靜態元素，好比圖片、JS腳本、CSS等等，將Squid放在Apache或者Lighttp 前端後，反而會使性能降低，畢竟處理HTTP請求是Web服務器的強項。並且已經存在於文件系統中的靜態內容再在Squid中緩存一下，浪費內存和硬盤空間。所以能夠考慮將Lighttpd再放在Squid的前面，構成 Lighttpd+Squid+Apache的一條處理鏈，Lighttpd在最前面，專門用來處理靜態內容的請求，把動態內容請求經過proxy模塊轉發給Squid，若是Squid中有該請求的內容且沒有過時，則直接返回給Lighttpd。新請求或者過時的頁面請求交由Apache中Web程序來處理。通過Lighttpd和Squid的兩級過濾，Apache須要處理的請求將大大減小，減小了Web應用程序的壓力。同時這樣的構架，便於把不一樣的處理分散到多臺計算機上進行，由Lighttpd在前面統一把關。

在這種架構下，每一級都是能夠進行單獨優化的，好比Lighttpd能夠採用異步IO方式，Squid能夠啓用內存來緩存，Apache能夠啓用MPM 等，而且每一級均可以使用多臺機器來均衡負載，伸縮性很好。

六、負載均衡將是大型網站解決高負荷訪問和大量併發請求採用的終極解決辦法。負載均衡技術發展了多年，有不少專業的服務提供商和產品能夠選擇，我我的接觸過一些解決方法，其中有兩個架構能夠給你們作參考。

用squid作web cache server，而apache在squid的後面提供真正的web服務。固然使用這樣的架構必需要保證主頁上大部分都是靜態頁面。這就須要程序員的配合將頁面在反饋給客戶端以前將頁面所有轉換成靜態頁面。

實例：Yupoo! 的網站技術架構

帶寬：4000M/S

服務器數量：60 臺左右

Web服務器：Lighttpd, Apache, nginx

應用服務器：Tomcat

其餘：Python, Java, MogileFS 、ImageMagick 等

首先看一下網站的架構圖：

該架構圖給出了很好的概覽(點擊能夠查看在 Yupoo! 上的大圖和原圖，請注意該圖版權信息)。

關於 Squid 與 Tomcat

對於應用服務器層的 Tomcat，如今 Yupoo! 技術人員也在逐漸用其餘輕量級的東西替代，而 YPWS/YPFS 如今已經用 Python 進行開發了。

名次解釋：

YPWS--Yupoo Web Server YPWS 是用 Python開發的一個小型 Web 服務器，提供基本的 Web 服務外，能夠增長針對用戶、圖片、外鏈網站顯示的邏輯判斷，能夠安裝於任何有空閒資源的服務器中，遇到性能瓶頸時方便橫向擴展。
YPFS--Yupoo File System 與 YPWS 相似，YPFS 也是基於這個 Web 服務器上開發的圖片上傳服務器。

圖片處理層

圖片存儲層

很是感謝一下 Yupoo! 阿華對於技術信息的分享，技術是共通的。下一個能爆料是哪家?

--EOF--

lighttpd+squid這套緩存是放在另一個機房做爲cdn的一個節點使用的，圖中沒描繪清楚，給你們帶來不便了。

squid前端用lighttpd沒用nginx，主要是用了這麼久，沒出啥大問題，因此就沒想其餘的了。

URL Hash的擴展性的確很差，能作的就是不輕易去增減服務器，咱們目前是5臺服務器作一組hash.

在可靠性上，還不沒具體的數據，目前運行1個多月尚未任何異常。

lvs每一個節點上都裝nginx，主要是爲了反向代理及處理靜態內容，不過apache已顯得不是那麼必需，準備逐漸去掉。

咱們處理圖片都是即時的，咱們目前半數以上的服務器都裝了magickd服務，用來分擔圖片處理請求。

實例：Tailrank 網站架構

天天數以千萬計的 Blog 內容中，實時的熱點是什麼? Tailrank 這個 Web 2.0 Startup 致力於回答這個問題。

服務器硬件

數據庫

其餘開放的軟件

YouTube架構學習

原文: YouTube Architecture

YouTube發展迅速，天天超過1億的視頻點擊量，但只有不多人在維護站點和確保伸縮性。

平臺

Apache
Python
Linux(SuSe)
MySQL
psyco，一個動態的Python到C的編譯器
lighttpd代替Apache作視頻查看

狀態

支持天天超過1億的視頻點擊量
成立於2005年2月
於2006年3月達到天天3千萬的視頻點擊量
於2006年7月達到天天1億的視頻點擊量
2個系統管理員，2個伸縮性軟件架構師
2個軟件開發工程師，2個網絡工程師，1個DBA
處理飛速增加的流量

Java代碼

1. while (true)
2. {
3. identify_and_fix_bottlenecks();
4. drink();
5. sleep();
6. notice_new_bottleneck();
7. }
while (true)
{
identify_and_fix_bottlenecks();
drink();
sleep();
notice_new_bottleneck();
}

天天運行該循環屢次

Web服務器

NetScaler用於負載均衡和靜態內容緩存
使用mod_fast_cgi運行Apache
使用一個Python應用服務器來處理請求的路由
應用服務器與多個數據庫和其餘信息源交互來獲取數據和格式化html頁面
通常能夠經過添加更多的機器來在Web層提升伸縮性
Python的Web層代碼一般不是性能瓶頸，大部分時間阻塞在RPC
Python容許快速而靈活的開發和部署
一般每一個頁面服務少於100毫秒的時間
使用psyco(一個相似於JIT編譯器的動態的Python到C的編譯器)來優化內部循環
對於像加密等密集型CPU活動，使用C擴展
對於一些開銷昂貴的塊使用預先生成並緩存的html
數據庫裏使用行級緩存
緩存完整的Python對象
有些數據被計算出來併發送給各個程序，因此這些值緩存在本地內存中。這是個使用不當的策略。應用服務器裏最快的緩存將預先計算的值發送給全部服務器也花不了多少時間。只需弄一個代理來監聽更改，預計算，而後發送。

視頻服務

1，花費包括帶寬，硬件和能源消耗

2，每一個視頻由一個迷你集羣來host，每一個視頻被超過一臺機器持有

3，使用一個集羣意味着：

-更多的硬盤來持有內容意味着更快的速度

-failover。若是一臺機器出故障了，另外的機器能夠繼續服務

-在線備份

4，使用lighttpd做爲Web服務器來提供視頻服務：

-Apache開銷太大

-使用epoll來等待多個fds

-從單進程配置轉變爲多進程配置來處理更多的鏈接

5，大部分流行的內容移到CDN：

-CDN在多個地方備分內容，這樣內容離用戶更近的機會就會更高

-CDN機器常常內存不足，由於內容太流行以至不多有內容進出內存的顛簸

6，不太流行的內容(天天1-20瀏覽次數)在許多colo站點使用YouTube服務器

-長尾效應。一個視頻能夠有多個播放，可是許多視頻正在播放。隨機硬盤塊被訪問

-在這種狀況下緩存不會很好，因此花錢在更多的緩存上可能沒太大意義。

-調節RAID控制並注意其餘低級問題

-調節每臺機器上的內存，不要太多也不要太少

視頻服務關鍵點

1，保持簡單和廉價

2，保持簡單網絡路徑，在內容和用戶間不要有太多設備

3，使用經常使用硬件，昂貴的硬件很難找到幫助文檔

4，使用簡單而常見的工具，使用構建在Linux裏或之上的大部分工具

5，很好的處理隨機查找(SATA，tweaks)

縮略圖服務

1，作到高效使人驚奇的難

2，每一個視頻大概4張縮略圖，因此縮略圖比視頻多不少

3，縮略圖僅僅host在幾個機器上

4，持有一些小東西所遇到的問題：

-OS級別的大量的硬盤查找和inode和頁面緩存問題

-單目錄文件限制，特別是Ext3，後來移到多分層的結構。內核2.6的最近改進可能讓Ext3容許大目錄，但在一個文件系統裏存儲大量文件不是個好主意

-每秒大量的請求，由於Web頁面可能在頁面上顯示60個縮略圖

-在這種高負載下Apache表現的很是糟糕

-在Apache前端使用squid，這種方式工做了一段時間，可是因爲負載繼續增長而以失敗了結。它讓每秒300個請求變爲20個

-嘗試使用lighttpd可是因爲使用單線程它陷於困境。遇到多進程的問題，由於它們各自保持本身單獨的緩存

-如此多的圖片以至一臺新機器只能接管24小時

-重啓機器須要6-10小時來緩存

5，爲了解決全部這些問題YouTube開始使用Google的BigTable，一個分佈式數據存儲：

-避免小文件問題，由於它將文件收集到一塊兒

-快，錯誤容忍

-更低的延遲，由於它使用分佈式多級緩存，該緩存與多個不一樣collocation站點工做

-更多信息參考Google Architecture，GoogleTalk Architecture和BigTable

數據庫

1，早期

-使用MySQL來存儲元數據，如用戶，tags和描述

-使用一整個10硬盤的RAID 10來存儲數據

-依賴於信用卡因此YouTube租用硬件

-YouTube通過一個常見的革命：單服務器，而後單master和多read slaves，而後數據庫分區，而後sharding方式

-更新引發緩存失效，硬盤的慢I/O致使慢備份

-使用備份架構須要花費大量的money來得到增長的寫性能

-YouTube的一個解決方案是經過把數據分紅兩個集羣來將傳輸分出優先次序：一個視頻查看池和一個通常的集羣

2，後期

-數據庫分區

-分紅shards，不一樣的用戶指定到不一樣的shards

-擴散讀寫

-更好的緩存位置意味着更少的IO

-致使硬件減小30%

-備份延遲下降到0

-如今能夠任意提高數據庫的伸縮性

數據中心策略

1，依賴於信用卡，因此最初只能使用受管主機提供商

2，受管主機提供商不能提供伸縮性，不能控制硬件或使用良好的網絡協議

3，YouTube改成使用colocation arrangement。如今YouTube能夠自定義全部東西而且協定本身的契約

4，使用5到6個數據中心加CDN

5，視頻來自任意的數據中心，不是最近的匹配或其餘什麼。若是一個視頻足夠流行則移到CDN

6，依賴於視頻帶寬而不是真正的延遲。能夠來自任何colo

7，圖片延遲很嚴重，特別是當一個頁面有60張圖片時

8，使用BigTable將圖片備份到不一樣的數據中心，代碼查看誰是最近的

學到的東西

1，Stall for time。創造性和風險性的技巧讓你在短時間內解決問題而同時你會發現長期的解決方案

2，Proioritize。找出你的服務中核心的東西並對你的資源分出優先級別

3，Pick your battles。別怕將你的核心服務分出去。YouTube使用CDN來分佈它們最流行的內容。建立本身的網絡將花費太多時間和太多money

4，Keep it simple!簡單容許你更快的從新架構來回應問題

5，Shard。Sharding幫助隔離存儲，CPU，內存和IO，不只僅是得到更多的寫性能

6，Constant iteration on bottlenecks：

-軟件：DB，緩存

-OS：硬盤I/O

-硬件：內存，RAID

Google是伸縮性的王者。Google一直的目標就是構建高性能高伸縮性的基礎組織來支持它們的產品。

平臺

Linux

大量語言：Python，Java，C++

狀態

在2006年大約有450,000臺廉價服務器

在2005年Google索引了80億Web頁面，如今沒有人知道數目

目前在Google有6000個MapReduce程序，並且每月都寫成百個新程序

BigTable伸縮存儲幾十億的URL，幾百千千兆的衛星圖片和幾億用戶的參數選擇

堆棧

Google形象化它們的基礎組織爲三層架構：

1，產品：搜索，廣告，email，地圖，視頻，聊天，博客

2，分佈式系統基礎組織：GFS，MapReduce和BigTable

3，計算平臺：一羣不一樣的數據中內心的機器

4，確保公司裏的人們部署起來開銷很小

5，花費更多的錢在避免丟失日誌數據的硬件上，其餘類型的數據則花費較少

可信賴的存儲機制GFS(Google File System)

1，可信賴的伸縮性存儲是任何程序的核心需求。GFS就是Google的核心存儲平臺

2，Google File System - 大型分佈式結構化日誌文件系統，Google在裏面扔了大量的數據

3，爲何構建GFS而不是利用已有的東西?由於能夠本身控制一切而且這個平臺與別的不同，Google須要：

-跨數據中心的高可靠性

-成千上萬的網絡節點的伸縮性

-大讀寫帶寬的需求

-支持大塊的數據，可能爲上千兆字節

-高效的跨節點操做分發來減小瓶頸

4，系統有Master和Chunk服務器

6，一個上線的新程序可使用已有的GFS集羣或者能夠製做本身的GFS集羣

7，關鍵點在於有足夠的基礎組織來讓人們對本身的程序有所選擇，GFS能夠調整來適應個別程序的需求

使用MapReduce來處理數據

3，爲何使用MapReduce?

-跨越大量機器分割任務的好方式

-處理機器失敗

4，MapReduce系統有三種不一樣類型的服務器

-Master服務器分配用戶任務到Map和Reduce服務器。它也跟蹤任務的狀態

-Map服務器接收用戶輸入並在其基礎上處理map操做。結果寫入中間文件

-Reduce服務器接收Map服務器產生的中間文件並在其基礎上處理reduce操做

-步驟相似於：GFS -> Map -> Shuffle -> Reduction -> Store Results back into GFS

-在MapReduce裏一個map操做將一些數據映射到另外一箇中，產生一個鍵值對，在咱們的例子裏就是字和字數

-Shuffling操做彙集鍵類型

-Reduction操做計算全部鍵值對的綜合併產生最終的結果

6，Google索引操做管道有大約20個不一樣的map和reduction。

7，程序能夠很是小，如20到50行代碼

9，數據在Map和Reduce服務器之間傳輸時被壓縮了。這能夠節省帶寬和I/O。

在BigTable裏存儲結構化數據

1，BigTable是一個大伸縮性、錯誤容忍、自管理的系統，它包含千千兆的內存和1000000000000000的存儲。它能夠每秒鐘處理百萬的讀寫

2，BigTable是一個構建於GFS之上的分佈式哈希機制。它不是關係型數據庫。它不支持join或者SQL類型查詢

3，它提供查詢機制來經過鍵訪問結構化數據。GFS存儲存儲不透明的數據而許多程序需求有結構化數據

4，商業數據庫不能達到這種級別的伸縮性而且不能在成千上萬臺機器上工做

6，系統運行時機器能夠自由的增刪而整個系統保持工做

7，每一個數據條目存儲在一個格子裏，它能夠經過一個行key和列key或者時間戳來訪問

8，每一行存儲在一個或多個tablet中。一個tablet是一個64KB塊的數據序列而且格式爲SSTable

9，BigTable有三種類型的服務器：

-Master服務器分配tablet服務器，它跟蹤tablet在哪裏而且若是須要則從新分配任務

-Lock服務器造成一個分佈式鎖服務。像打開一個tablet來寫、Master調整和訪問控制檢查等都須要互斥

10，一個locality組能夠用來在物理上將相關的數據存儲在一塊兒來獲得更好的locality選擇

11，tablet儘量的緩存在RAM裏

硬件

1，當你有不少機器時你怎樣組織它們來使得使用和花費有效?

2，使用很是廉價的硬件

4，Linux，in-house rack design，PC主板，低端存儲

5，Price per wattage on performance basis isn't getting better. Have huge power and cooling issues

6，使用一些collocation和Google本身的數據中心

其餘

1，迅速更改而不是等待QA

2，庫是構建程序的卓越方式

3，一些程序做爲服務提供

4，一個基礎組織處理程序的版本，這樣它們能夠發佈而不用懼怕會破壞什麼東西

Google未來的方向

1，支持地理位置分佈的集羣

2，爲全部數據建立一個單獨的全局名字空間。當前的數據由集羣分離

3，更多和更好的自動化數據遷移和計算

4，解決當使用網絡劃分來作廣闊區域的備份時的一致性問題(例如保持服務即便一個集羣離線維護或因爲一些損耗問題)

學到的東西

3，若是你本身沒有時間從零開始從新構建全部這些基礎組織你能夠看看Hadoop。Hadoop是這裏不少一樣的主意的一個開源實現

6，構建自管理系統讓你不必讓系統關機。這容許你更容易在服務器之間平衡資源、動態添加更大的容量、讓機器離線和優雅的處理升級

7，建立可進化的基礎組織，並行的執行消耗時間的操做並採起較好的方案

8，不要忽略學院。學院有許多沒有轉變爲產品的好主意。Most of what Google has done has prior art, just not prior large scale deployment.

9，考慮壓縮。當你有許多CPU而IO有限時壓縮是一個好的選擇。

實例：Lighttpd+Squid+Apache搭建高效率Web服務器

架構原理

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。