軟體系結(jié)構(gòu) (南理工)10案例分析

軟件體系結(jié)構(gòu)案例分析

——Twitter簡析趙學龍1/5/20241Twitter是什么？一種可以向你的朋友或者follower

發(fā)送短信息的免費網(wǎng)絡效勞。是多種通信方式的綜合Email電子郵件instantmessenger短信blog博客Rss〔不同之處在于它的字數(shù)限制在140字〕起源于“Whatareyoudoing？〞的答案現(xiàn)在是“what’shappening〞1/5/20242Twitter的起源與開展隨著信息爆炸的加劇，微博客網(wǎng)站Twitter橫空出世了。從2006年5月Twitter上線，到2007年12月，一年半的時間里，Twitter用戶數(shù)從0增長到6.6萬。2021年12月，Twitter的用戶數(shù)到達5百萬，消息數(shù)量就到達了10億條，2021年3月，Twitter的消息數(shù)量首次到達100億條，Twitter全球用戶數(shù)已達1億。Twitter的日均注冊數(shù)約為30萬人，獨立訪問量達1.8億。1/5/20243Twitter開展目前，60%的Twitter新用戶現(xiàn)在來自美國以外，而其75%的流量也來自Twitter之外。新浪微博5百萬用戶〔2021年3月〕〔2021年8月內(nèi)測〕QQ同時在線用戶1億〔2021年3月〕(2007年9月注冊用戶8.5億)用戶7.47億〔2021年1月，工信部〕中國上網(wǎng)人數(shù)4.04億〔2021年5月〕1/5/20244Twitter體系結(jié)構(gòu)Twitter網(wǎng)站的成功，先決條件是能夠同時給千萬用戶提供效勞，而且提供效勞的速度要快。有觀點認為，Twitter的業(yè)務邏輯簡單，所以競爭門檻低。Twitter的競爭力，離不開嚴謹?shù)南到y(tǒng)架構(gòu)設計。1/5/20245Twitter業(yè)務邏輯Twitter的核心業(yè)務邏輯，在于Following和Befollowed。進入Twitter個人主頁，你會看到你following的那些作者，最近發(fā)表的微博客。所謂微博客，就是一那么短信，Twitter規(guī)定，短信的長度不得超過140個字。這就是following的過程。當你寫了一那么短信并發(fā)表以后，你的followers會立刻在他們的個人主頁中看到你寫的最新短信。這就是befollowed的過程。1/5/20246Twitter業(yè)務邏輯1.為每一個注冊用戶訂制一個Be-followed的表，主要內(nèi)容是每一個follower的ID。同時，也訂制一個Following的表，主要內(nèi)容是每一個following作者的ID。2.當用戶翻開自己的個人空間時，Twitter先查閱Following表，找到所有following的作者的ID。然后去數(shù)據(jù)庫讀取每一位作者最近寫的短信。匯總后按時間順序顯示在用戶的個人主頁上。3.當用戶寫了一那么短信時，Twitter先查閱Be-followed表，找到所有followers的IDs。然后逐個更新那些followers的主頁。實現(xiàn)這個業(yè)務流程似乎很容易。1/5/20247Twitter業(yè)務邏輯從作者發(fā)表到讀者獲取，中間的延遲，取決于JavaScript更新的間隔，以及Twitter效勞器更新每個follower的主頁的時間。從系統(tǒng)架構(gòu)上來說，似乎傳統(tǒng)的三層體系結(jié)構(gòu)〔Three-tierarchitecture〕足夠滿足這個業(yè)務邏輯的需要。事實上，最初的Twitter系統(tǒng)架構(gòu)，確實就是三層結(jié)構(gòu)。1/5/20248三層體系結(jié)構(gòu)三層架構(gòu)就是將整個業(yè)務應用劃分為：表現(xiàn)層〔UI〕、業(yè)務邏輯層〔BLL〕、數(shù)據(jù)訪問層〔DAL〕。區(qū)分層次的目的即為了“高內(nèi)聚，低耦合〞的思想。表現(xiàn)層〔UI〕：通俗講就是展現(xiàn)給用戶的界面，即用戶在使用一個系統(tǒng)的時候他的所見所得。業(yè)務邏輯層〔BLL〕：針對具體問題的操作，也可以說是對數(shù)據(jù)層的操作，對數(shù)據(jù)業(yè)務邏輯處理。數(shù)據(jù)訪問層〔DAL〕：該層所做事務直接操作數(shù)據(jù)庫，針對數(shù)據(jù)的增添、刪除、修改、更新、查找等。網(wǎng)站的架構(gòu)設計，傳統(tǒng)的做法是三層結(jié)構(gòu)。所謂“傳統(tǒng)的〞，并不等同于“過時的〞。1/5/20249Twitter的體系結(jié)構(gòu)2006年5月Twitter剛上線的時候，為了簡化網(wǎng)站的開發(fā)，他們使用了Ruby-On-Rails工具，而Ruby-On-Rails的設計思想，就是三層結(jié)構(gòu)。1.表述層(PresentationTier)用的工具是ApacheWebServer，主要任務是解析HTTP協(xié)議，把來自不同用戶的，不同類型的請求，分發(fā)給邏輯層。2.邏輯層(LogicTier〕用的工具是MongrelRailsServer，利用Rails現(xiàn)成的模塊，降低開發(fā)的工作量。3.數(shù)據(jù)層(DataTier)用的工具是MySQL數(shù)據(jù)庫。1/5/202410數(shù)據(jù)層Twitter的效勞概括為兩個核心：用戶，短信。用戶與用戶之間的關系，是追與被追的關系，也就是Following和Befollowed。對于一個用戶來說，他只讀自己“追〞的那些人寫的短信。而他自己寫的短信，只有那些“追〞自己的人才會讀。抓住這兩個核心，就不難理解Twitter的其它功能是如何實現(xiàn)的。1/5/202411數(shù)據(jù)層圍繞這兩個核心，就可以著手設計數(shù)據(jù)模式，也就是存放在數(shù)據(jù)層中的數(shù)據(jù)的組織方式。不妨設置三個表，1.用戶表：用戶ID，姓名，登錄名和密碼，狀態(tài)〔在線與否〕。2.短信表：短信ID，作者ID，正文〔定長，140字〕，時間戳。3.用戶關系表，記錄追與被追的關系：用戶ID，他追的用戶IDs(Following)，追他的用戶IDs(Befollowed)。1/5/202412邏輯層當用戶發(fā)表一條短信的時候，執(zhí)行以下五個步驟，1.把該短信記錄到“短信表〞中去。2.從“用戶關系表〞中取出追他的用戶的IDs。3.有些追他的用戶目前在線，另一些可能離線。在線與否的狀態(tài)，可以在“用戶表〞中查到。過濾掉那些離線的用戶的IDs。4.把那些追他的并且目前在線的用戶的IDs，逐個推進一個隊列(Queue)中去。5.從這個隊列中，逐個取出那些追他的并且目前在線的用戶的IDs，并且更新這些人的主頁，也就是添加最新發(fā)表的這條短信。前三步容易解決，都是簡單的數(shù)據(jù)庫操作。最后兩步，需要用到一個輔助工具，隊列。隊列的意義在于，別離了任務的產(chǎn)生與任務的執(zhí)行1/5/202413邏輯層簡單的數(shù)據(jù)結(jié)構(gòu)來實現(xiàn)隊列，例如動態(tài)鏈表，甚至靜態(tài)數(shù)組就可以。為了支持聯(lián)絡多臺機器的、分布式的隊列。Twitter團隊自己動手實現(xiàn)了一個隊列：Kestrel。1/5/202414表現(xiàn)層表述層的主要職能：1.HTTP協(xié)議處理器(HTTPProcessor)，包括拆解接收到的用戶請求，以及封裝需要發(fā)出的結(jié)果。2.分發(fā)器(Dispatcher)，把接收到的用戶請求，分發(fā)給邏輯層的機器處理。如果邏輯層只有一臺機器，那么分發(fā)器無意義。但是如果邏輯層由多臺機器組成，什么樣的請求，發(fā)給邏輯層里面哪一臺機器，就大有講究了。邏輯層里眾多機器，可能各自專門負責特定的功能，而在同功能的機器之間，要分攤工作，使負載均衡。1/5/202415表現(xiàn)層訪問Twitter網(wǎng)站的，不僅僅是瀏覽器，而且還有，還有像QQ那樣的電腦桌面工具，另外還有各式各樣的網(wǎng)站插件。因此，Twitter的訪問者與Twitter網(wǎng)站之間的通訊協(xié)議，不一定是HTTP，也存在其它協(xié)議。三層Twitter架構(gòu)，主要是針對HTTP協(xié)議的終端。但是對于其它協(xié)議的終端，Twitter的架構(gòu)沒有明顯地劃分成三段，而是把表述層和邏輯層合二為一，在Twitter的文獻中，這二合一經(jīng)常被稱為“API〞。1/5/202416Twitter三層體系結(jié)構(gòu)這么知名的網(wǎng)站，架構(gòu)就這么簡單？真正的Twitter架構(gòu)與差距不大，不一樣的地方在于加了一些簡單的緩存(Cache)1/5/202417Cache==Cash緩存等于現(xiàn)金。雖然這話有點夸張，但是正確使用緩存，對于大型網(wǎng)站的建設，是至關重要的大事。網(wǎng)站在回應用戶請求時的反響速度，是影響用戶體驗的一大因素。而影響速度的原因有很多，其中一個重要的原因在于硬盤的讀寫(DiskIO)。硬盤的讀寫，速度比內(nèi)存的慢了百萬倍20211/5/202418好的網(wǎng)站Twitter工程師認為，一個用戶體驗良好的網(wǎng)站，當一個用戶請求到達以后，應該在平均500ms以內(nèi)完成回應。而Twitter的理想，是到達200ms-300ms的反響速度。因此在網(wǎng)站架構(gòu)上，Twitter大規(guī)模地，多層次多方式地使用緩存。Twitter在緩存使用方面的實踐，以及從這些實踐中總結(jié)出來的經(jīng)驗教訓，是Twitter網(wǎng)站架構(gòu)的一大看點。1/5/202419哪里需要緩存？越是DiskIO頻繁的地方，越需要緩存。有沒有必要把這幾個核心的數(shù)據(jù)庫表統(tǒng)統(tǒng)存放到緩存中去？1.用戶表：2.短信表：3.用戶關系表Twitter的做法是把這些表拆解，把其中讀寫最頻繁的列放進緩存。1/5/202420緩存VectorCacheIDs緩存。即新發(fā)表的短信的IDs，熱門短信的IDs，相關作者的IDs，訂閱這些作者的讀者的IDs。RowCache

存放短信正文使用的工具都是開源的MemCached實踐結(jié)果：VectorCache的命中率是99%，RowCache的命中率是95%1/5/202421緩存FragmentCache緩存熱門作者寫的短信的布局頁面(Fragment)，就可以提高網(wǎng)站整體的讀取效率。PageCache：緩存熱門作者主頁。與FragmentCache主機分開使用的工具都是開源的MemCached實際結(jié)果：FragmentCache的命中率是95%PageCache的命中率是40%API通道受理的流量占總流量的80%-90%

1/5/202422緩存HTTPAccelerator

Web通道的壓力，主要來自于搜索。尤其是面臨突發(fā)事件時，讀者們會搜索相關短信，而不理會這些短信的作者，是不是自己“追〞的那些作者。

要降低搜索的壓力，就是把搜索關鍵詞，及其對應的搜索結(jié)果，緩存起來。使用的工具開源工程VarnishVarnish的操作比較復雜，為了降低崩潰造成整個網(wǎng)站癱瘓的可能性1/5/202423緩存ApacheWebServer的主要任務，是解析HTTP，以及分發(fā)任務。不同的MongrelRailsServer負責不同的任務。但是絕大多數(shù)MongrelRailsServer，都要與VectorCache和RowCache聯(lián)系，讀取數(shù)據(jù)。RailsServer通過Rails插件〔CacheMoney〕與MemCached聯(lián)系。1/5/202424緩存雖然Twitter沒有公開Varnish的命中率是多少，使用了Varnish以后，導致整個Twitter網(wǎng)站的負載下降了50%，1/5/202425Twitter體系結(jié)構(gòu)消息隊列(MessageQueue)隔離用戶請求與相關操作，均衡流量頂峰通過讓Apache進程空循環(huán)的方法，迅速接納用戶的訪問，推遲效勞，說白了是個緩兵之計，目的是讓用戶不至于收到“HTTP503〞錯誤提示，“503錯誤〞是指“效勞不可用(ServiceUnavailable)〞，也就是網(wǎng)站拒絕訪問。1/5/202426消息隊列(MessageQueue)其中洪峰時刻，Twitter網(wǎng)站每秒鐘收到350條新短信，這個流量洪峰維持了大約5分鐘。根據(jù)統(tǒng)計，平均每個Twitter用戶被120人“追〞，這就是說，這350條短信，平均每條都要發(fā)送120次。這意味著，在這5分鐘的洪峰時刻，Twitter網(wǎng)站每秒鐘需要發(fā)送350x120=42,000條短信。2021年1月20日星期二，美國總統(tǒng)BarackObama就職并發(fā)表演說。1/5/202427消息隊列(MessageQueue)面對洪峰，如何才能保證網(wǎng)站不崩潰？方法是迅速接納，但是推遲效勞。打個比方，在晚餐頂峰時段，餐館常?？蜐M。對于新來的顧客，餐館效勞員不是拒之門外，而是讓這些顧客在休息廳等待。這就是所說的“燙平流量頂峰〞。1/5/202428消息隊列(MessageQueue)當一位用戶訪問Twitter網(wǎng)站時，接待他的是ApacheWebServer。Apache做的事情非常簡單，它把用戶的請求解析以后，轉(zhuǎn)發(fā)給MongrelRailsSever，由Mongrel負責實際的處理。而Apache騰出手來，迎接下一位用戶。這樣就防止了在洪峰期間，用戶連接不上Twitter網(wǎng)站的為難局面。1/5/202429消息隊列(MessageQueue)雖然Apache的工作簡單，但是并不意味著Apache可以接待無限多的用戶。原因是Apache解析完用戶請求，并且轉(zhuǎn)發(fā)給MongrelServer以后，負責解析這個用戶請求的進程(process)，并沒有立刻釋放，而是進入空循環(huán)，等待MongrelServer返回結(jié)果。1/5/202430Apache內(nèi)部的進程機制Apache能夠容納的并發(fā)的連接數(shù)量(concurrentconnections)，實際上受制于Apache能夠容納的進程數(shù)量。圖中每個Worker代表一個進程。Apache能夠容納多少個并發(fā)連接呢？有實驗結(jié)果是4,000個。如何增加呢？1/5/202431消息隊列(MessageQueue)通過讓Apache進程空循環(huán)的方法，迅速接納用戶的訪問，推遲效勞，說白了是個緩兵之計，目的是讓用戶不至于收到“HTTP503〞錯誤提示，“503錯誤〞是指“效勞不可用(ServiceUnavailable)〞，也就是網(wǎng)站拒絕訪問。1/5/202432Kestrel消息隊列對于Twitter系統(tǒng)來說，龐大的效勞器集群，尤其是以MemCached為主的眾多的緩存，表達了蓄洪的容量。引流的手段是Kestrel消息隊列，用于傳遞控制指令。渠道是機器與機器之間的數(shù)據(jù)傳輸通道，尤其是通往MemCached的數(shù)據(jù)通道。渠道的優(yōu)劣，在于是否通暢。Twitter系統(tǒng)的抗洪措施，表達在有效地控制數(shù)據(jù)流，保證在洪峰到達時，能夠及時把數(shù)據(jù)疏散到多個機器上去，從而防止壓力過度集中，造成整個系統(tǒng)的癱瘓。1/5/202433Twitter網(wǎng)站內(nèi)部流程假設有兩個作者，通過瀏覽器，在Twitter網(wǎng)站上發(fā)表短信。有一個讀者，也通過瀏覽器，訪問網(wǎng)站并閱讀他們寫的短信。1/5/202434Twitter網(wǎng)站內(nèi)部流程1.作者的瀏覽器與網(wǎng)站建立連接，ApacheWebServer分配一個進程(WorkerProcess)。作者登錄，Twitter查找作者的ID，并作為Cookie，記憶在HTTP郵包的頭屬性里。1/5/202435Twitter網(wǎng)站內(nèi)部流程2.瀏覽器上傳作者新寫的短信(Tweet)，Apache收到短信后，把短信連同作者ID，轉(zhuǎn)發(fā)給MongrelRailsServer。然后Apache進程進入空循環(huán)，等待Mongrel的回復，以便更新作者主頁，把新寫的短信添加上去。1/5/202436Twitter網(wǎng)站內(nèi)部流程3.Mongrel收到短信后，給短信分配一個ID，然后把短信ID與作者ID，緩存到VectorMemCached效勞器上去。1/5/202437Twitter網(wǎng)站內(nèi)部流程3.Mongrel收到短信后，給短信分配一個ID，然后把短信ID與作者ID，緩存到VectorMemCached效勞器上去。接著，Mongrel把短信ID與短信正文，緩存到RowMemCached效勞器上去。同時，Mongrel讓VectorMemCached查找，有哪些讀者“追〞這位作者。如果VectorMemCached沒有緩存這些信息，VectorMemCached自動去MySQL數(shù)據(jù)庫查找，得到結(jié)果后，緩存起來，以備日后所需。然后，把讀者IDs回復給Mongrel。1/5/202438Twitter網(wǎng)站內(nèi)部流程4.Mongrel通知Kestrel消息隊列效勞器，為每個作者及讀者開設一個隊列，隊列的名稱中隱含用戶ID。如果Kestrel效勞器中已經(jīng)存在這些隊列，那就延用以往的隊列。對應于每個短信，Mongrel已經(jīng)從VectorMemCached那里知道，有哪些讀者追這條短信的作者。Mongrel把這條短信的ID，逐個放進每位讀者的隊列，以及作者本人的隊列。

1/5/202439Twitter網(wǎng)站內(nèi)部流程5.同一臺MongrelServer，或者另一臺MongrelServer，在處理某個Kestrel隊列中的消息前，從這個隊列的名稱中解析出相應的用戶ID，這個用戶，既可能是讀者，也可能是作者。然后Mongrel從Kestrel隊列中，逐個提取消息，解析消息中包含的短信ID。并從RowMemCached緩存器中，查找對應于這個短信ID的短信正文。

這時，Mongrel既得到了用戶的ID，也得到了短信正文。接下去Mongrel就著手更新用戶的主頁，添加上這條短信的正文。1/5/202440Twitter網(wǎng)站內(nèi)部流程6.Mongrel把更新后的作者的主頁，傳遞給正在空循環(huán)的Apache的進程。該進程把作者主頁主動傳送(push)給作者的瀏覽器。如果讀者的瀏覽器事先已經(jīng)登錄Twitter網(wǎng)站，建立連接，那么Apache給該讀者也分配了一個進程，該進程也處于空循環(huán)狀態(tài)。Mongrel把更新后的讀者的主頁，傳遞給相應進程，該進程把讀者主頁主動傳遞給讀者的瀏覽器。。1/5/202441流量洪峰美國年度橄欖球決賽，綽號超級碗(SuperBowl)。SuperBowl在美國的收視率，相當于中國的央視春節(jié)晚會。對于Twitter來說，可以預料的是，比賽進行過程中，Twitter流量必然大漲。比賽越劇烈，流量越高漲。Twitter無法預料的是，流量究竟會漲到多少，尤其是洪峰時段，流量會到達多少。1/5/202442流量洪峰根據(jù)統(tǒng)計，在2021年SuperBowl比賽進行中，每分鐘的流量與當日平均流量相比，平均高出40%。在比賽最劇烈時，更高達150%以上。與一周前，2021年1月27日，一個平靜的星期天的同一時段相比，流量的波動從平均10%，上漲到40%，最高波動從35%，上漲到150%以上。1/5/202443流量洪峰由此可見，Twitter流量的波動十分可觀。對于Twitter公司來說，如果預先購置足夠的設備，以承受流量的變化，尤其是重大事件導致的洪峰流量，那么這些設備在大局部時間處于閑置狀態(tài)，非常不經(jīng)濟。但是如果缺乏足夠的設備，那么面對重大事件，Twitter系統(tǒng)有可能崩潰，造成的后果是用戶流失。怎么辦？方法是變買為租。Twitter公司自己購置的設備，其規(guī)模以應付無重大事件時的流量壓力為限。同時租賃云計算平臺公司的設備，以應付重大事件來臨時的洪峰流量。計算資源實時分配，自動分配計算資源。1/5/202444流量洪峰但是租來的計算資源怎么用？大局部用于增加ApacheWebServer。每個訪問Twitter網(wǎng)站的瀏覽器，都與網(wǎng)站保持長連接。目的是一旦有人發(fā)表新的短信，Twitter網(wǎng)站在500ms以內(nèi)，把新短信push給他的讀者。問題是在沒有更新的時候，每個長連接占用一個Apache的進程，而這個進程處于空循環(huán)。所以，絕大多數(shù)Apache進程，在絕大多數(shù)時間里，處于空循環(huán)，因此占用了大量資源。事實上，通過ApacheWebServers的流量，雖然只占Twitter總流量的10%-20%，但是Apache卻占用了Twitter整個效勞器集群的50%的資源1/5/202445洪峰流量當一個來自瀏覽器的用戶請求到達Twitter后臺系統(tǒng)的時候，第一個迎接它的，是ApacheWebServer。第二個是MongrelRailsServer。Mongrel既負責處理上傳的請求，也負責處理下載的請求。Mongrel處理上傳和下載的業(yè)務邏輯非常簡潔，但是簡潔的表象之下，卻蘊含著反常規(guī)的設計1/5/202446洪峰流量當Mongrel收到新短信后，分配一個新的短信ID。然后把新短信的ID，連同作者ID，緩存進VectorMemCached效勞器。接著，把短信ID以及正文，緩存進RowMemCached效勞器。接著，Mongrel把新短信的ID，逐個放進“追〞這位作者的所