10倍億級爆量發文也不怕！微博服務架構超高可用性的秘密

今年6月6日晚上7點06分，一則林志玲微博上的閃婚消息，震撼了娛樂圈，更在微博社群引起轟動。這則婚訊發布不到3小時，經過網友瘋狂轉貼、評論，相關的討論文章，在不到3小時內達到了45萬則，瀏覽量更超過6億次，立刻登上熱搜榜第1位，尖峰時間甚至一度造成微博服務短暫癱瘓，之後幾天，瀏覽人次更達到25億次、89萬則評論。就連原帖轉發、評論也都超過數十萬則以及數百萬個讚。這一則短短不到50字的貼文，成為了微博IT團隊維運的突發大挑戰。

新浪微博研發總監李慶豐點出技術關鍵，在於打造一套高可用的微服務（Microservices）架構體系，並且搭配容器（Container）技術、分散式儲存架構與混合雲，才能做到支撐上億用戶每天內容發布需求，甚至遇到突發尖峰流量也不怕。李慶豐在近日來臺參加Modern Web 2019大會時，也揭露了更多技術細節。

微博目前自建一套大型網路服務高可用架構體系，來提供上百服務、數億用戶訊息發布的使用。該體系主要是由幾大核心元件組成，並分4層，最上層是海量數據儲存架構、接下來一層則是分散式快取架構，微服務與容器化則是第3層，最底層則是備援用的多機房架構。整個架構外圍還有搭配監控、服務治理、服務水準協議（SLA），來分別解決4大高可用性的挑戰，也就是容量、性能、服務依賴，以及容災問題。攝影／余至浩

微博是目前中國最大的微網誌的服務平臺，用戶只要透過訂閱「關注」別人，就能看到對方發布的簡短評論或內容，也可以說是中國版的推特（Twitter）；而且不只能訂閱內容，後來，該服務也加入了許多新功能，例如興趣推送，或熱搜功能等，持續增加用戶黏著度，使得該服務使用人數逐年增長，光是最近短短4年，每月活躍用戶就有翻倍成長，從2016年的2.82億戶，到了2019年第2季，成長更達到4.86億戶。

如今，微博全球多達2.1億日活躍用戶，單日評論、轉發量超過數億條，平均每日新增「關注」訂閱數更達到上千萬，更有上百個服務、多套系統同時運作，也成為微博IT團隊首要面對的龐大IT考驗。

微博目前自建一套超大型網路服務高可用架構體系，來提供每日數億用戶訊息發布，與上百服務功能的使用。該體系主要是由多個重要核心元件組成，並分4層，最上層是海量數據儲存架構，接下來一層則是分散式快取架構，前2層都是用於資料儲存與請求之用，微服務與容器化則是第3層，負責建構一個可靈活伸縮的彈性網路服務，還有最底層則是備援用的多機房架構。整個架構外圍還有搭配監控、服務治理、服務水準協議（SLA），來分別解決4大高可用性的挑戰，也就是容量、性能、服務依賴，以及容災問題。

靠建置超高可用性的微服務架構，來迎戰爆量用戶增長挑戰

首先，是服務依賴的挑戰。李慶豐表示，微博內容，從原本最簡單的訂閱發布模式，最近幾年變得越來越複雜，因應用戶數快速增，不只有各式各樣的資訊流模式，還有越來越多服務與新功能加入，累計至今已有上百個服務推出，例如發現、搜尋、Feed流、串流直播等，這麼多新服務，也導致服務相互之間依賴關係更複雜，需要有一個非常高度的服務治理能力，這也成為了微博IT所要面對的第一個技術挑戰。

「我們解決服務依賴問題的關鍵，就是微服務與容器化。」他表示，微博服務之間容易存在高度依賴的原因，在於不論核心業務或非核心業務提供的Web服務，以往都放在同一個解析Java程式的Tomcat容器執行環境裡，用來執行Web應用，尤其，早期的任務分組，每個核心團隊同時要負責核心與非核心服務，並將這些服務執行程式部署在Web伺服器裡，所以，服務之間彼此相互關聯非常緊密，只要這裡面的其中一個非核心服務發生故障，也容易連帶影響到另一個核心服務的正常運作。

不只同一團隊裡的各別服務，會有依賴問題，不同團隊之間也會有相同問題。例如，當A團隊負責的其中一個非核心服務發生異常，另一個B團隊的核心服務，也容易受到牽連，因為透過http調用而向另一邊A團隊服務發送請求而產生間接依賴，嚴重甚至造成整個服務的中斷，因此，就會產生很高的風險。

為了讓各服務之間能夠遵行高內聚，低耦合（high cohesion、low coupling）的原則，李慶豐表示，他們先是導入微服務架構，先將原本同一Tomcat容器裡的不同服務拆分到各自獨立的容器裡，讓不同服務都用各別容器來承接，以改善服務依賴情形。

不過，這樣子的作法，也使得原先服務因為拆分造成架構變得更為複雜且龐大，進而衍伸出各服務調用效率及性能變差的情形。最後，他們是靠採用遠端程式呼叫（Remote Procedure Call，RPC）機制來解決這個問題。

因為RPC的連線反應速度更快、調度、管理能力與自動化程度較高，李慶豐說明，比起一般http發送請求方式，更適合用於網路上不同服務之間的調用，甚至他們還因此開發出一個跨語言的RPC服務化框架，稱為Motan，能通過RPC的方式，讓服務之間的調用實現低延遲與改善性能問題。「這也是微服務化帶來的問題之一，我們用RPC的方式來解決。」他說。

新浪微博研發總監李慶豐表示，微博服務背後的技術架構，在於打造一套高可用的微服務架構體系，及搭配容器、分散式儲存架構與混合雲，才能做到支撐上億用戶每天內容發布需求，甚至遇到突發尖峰流量也不怕。

採用容器解決大量微服務不易管理難題

另一個微服務帶來的新挑戰則是管理難題。李慶豐指出，微服務雖然解決了服務依賴耦合的問題，但也帶來了維運複雜度的急遽增大，例如原先系統可能就只有4到5個服務之間存有依賴，維運管理相較簡單，但是當單一應用服務拆成多個小型獨立服務，服務拆分成越來越細，一次同時可能要維護管理上百個服務時，管理變得極為複雜，「甚至成為微博IT團隊在服務維運上的一大惡夢，」他坦言，直到更輕量化的Docker容器的問世，才替他們解決了這個難題。

李慶豐說明，Docker容器的好處，不只在服務開發、維運兩端可進行統一管理，也很容易隔離容器環境，還能協助IT團隊縮短服務開發及上線時間，例如，原來100臺傳統伺服器要部署完成並且推出上線得要花一整天，改採用容器後，平均每5分鐘就能布建百臺虛擬機器，從24小時縮短到5分鐘，足足快了將近290倍。

也因為採用了Docker部署方式，李慶豐指出，後來他們在打造混合雲架構時，也更加容易許多，甚至當遇到重大政治、娛樂事件或重大節日帶來的突發流量，無法單靠本地機房支撐時，就可通過這個架構迅速把流量導入到雲端。例如林志玲的結婚喜訊，短時間所帶來的數億級爆量發文，就需要採用這樣的作法。

又如今年2月4日的央視春晚節目剛播出，不到幾小時，微博貼文出現跟「春晚」有關的熱門討論，就超過一億條、瀏覽人次更多達63.44億次，以及50億次短片播放，「對我們來說，這些不可預測的流量，需要做非常好的控制，但又要節省成本，」他指出，靠的就是利用Docker來打造一套彈性擴容系統，通過容器化方式快速部署，幫助他們更容易把容器化應用打包，放到公有雲環境執行，使得在本地端和雲端之間調度服務變得更加彈性可伸縮，並且可以做到自動擴容的能力，來支撐微博春晚爆量訊息發布的使用。「甚至，也幫助我們加快機器部署的準備時間，從原本1個月，現在只要3分鐘就能完成。」他說。

他進一步歸納：「以微服務方式解決大量服務之間的耦合，並以容器化的方式改善微服務帶來維運複雜度的問題，現在，更利用混合雲架構降低營運成本，就是我們維持高可用性的解方。」這也是為何今年微博春晚出現尖峰流量，微博也能撐得住的關鍵，他補充說，這些都是建立在一定程度的資源監控體系之上，來打造一個可伸縮的彈性服務。

今年2月4日的央視春晚節目剛播出，不到幾小時，微博上出現跟「春晚」有關的熱門討論，就超過一億條、瀏覽人次更多達60億次，但是微博IT團隊卻一點也不擔心，靠的就是利用Docker容器與微服務來打造一套彈性擴容系統，使得在本地端和雲端之間資源調度變得更加彈性可伸縮，來支撐微博春晚爆量訊息發布之用，甚至，也加快機器部署的準備時間，從原本1個月，縮短到3分鐘完成。攝影／余至浩

面對海量數據儲存挑戰，採用分散式儲存與快取架構是關鍵

除了超高尖峰流量的挑戰，面對海量數據儲存，對於微博現有的儲存架構的考驗同樣不小，最直接反應在儲存容量不夠用，以致於數據存不下，請求扛不住，這也是第2大挑戰。

但是想要儲存更多數據，滿足更大量請求，並不是增加儲存容量就好，李慶豐特別強調事前準備的重要性，不論是從資料庫選用，到實際測試，以及對於未來容量擴充的預測，都要事先做好完整規畫，以決定最後該用哪一類型資料庫，以及搭配多少臺伺服器。

以MySQL為例，他表示，在選用資料庫前，會先考慮它的寫入／讀取性能，以及成本特性，做為選擇儲存元件的依據，還會實際在微博服務場景下通過測試看它在不同SSD、SAS硬碟上讀寫性能，避免一旦儲存量用到極限，引起諸多安全問題。他也說，如果遇到的應用場景，需要儲存量比較小，請求量較大時，就適用NoSQL資料庫，如Redis等

選好儲存元件，接下來，就進到容量規畫，李慶豐指出，一般來說，容量規畫會考慮幾個問題，比如需要用多少臺伺服器，資料存取規模多大，儲存容量才足夠用。以微博的作法，還會將3個月後的用戶使用情況、數據用量，以及1年後的服務成長規模納入考量，同時，也會考慮儲存成本、使用服務場景，以及在架構設計上，如何做到可擴展以及容錯程度，他說，這些都是打造可擴展的數據儲存架構必須考慮的事。

他也提到在實務上可能遇到的一些儲存挑戰，包括，讀寫比例的嚴重失調，單機容量瓶頸以及業務快速增長帶來的容量問題。他指出，針對資料讀多寫少的情況，可以採用讀寫分離到不同的伺服器分擔，而要解決單機容量瓶頸，則是可採用水平拆分，將用戶不同數據，以主／從的數據儲存方式分別用不同伺服器來儲存，或是以垂直拆分方式，按時間維度進行拆分，存放在不同性能的伺服器裡。「尤其，微博的服務特性，讓它更需要採用這樣的作法。」李慶豐表示。

舉例，微博一周以內發表的新內容，通常占所有服務讀取請求的8成以上，但是一個月以前的內容，只占總請求的1成，因此，他表示，在這樣情況下，就需要把老舊內容用更少的儲存空間，搭配一般普通機器來承接，對於新的或比較熱門資料，就可以放在新添購或性能更強的機器裡，如此一來，用戶的體驗才會好。甚至，不只把這些內容依時間來做拆分，他補充說，還會將這些內容按月來區分，製作成分布分表，就能把一個月後請求量沒那麼大的內容，將它遷移到一些性能比較差的機器上，這也是微博打造海量數據儲存的重要關鍵。

他提到第3個挑戰則是性能問題。尤其是需要儲存海量資料時，為了加快存取性能，微博還會搭配速度更快的快取記憶體儲存，建置一個分散式快取架構，來打造一個可以提供高速存取的Web服務架構，李慶豐表示，這可以用來改善傳統儲存效能不夠高的問題，並且透過建立分散式快取架構，可以把這些快取記憶體，依不同用戶的請求指引到不同機器上，作法就跟分散式儲存相似，比較不同的地方是，當一次要請求百人以上數據時，也容易因為拆分得太細而影響快取性能。

因此，他們還進一步採用線性擴展方式，在資料快取層的前面，額外加了一層快取，稱作L1快取層，也就是針對多個請求量拆分時，不是按每一個數據模組來拆，而是以整組拆分的方式解決多人同時請求無法細拆數據分開儲存的問題。

但李慶豐也直言，採用快取比例越高，也容易加大系統複雜度與產生數據一致性問題，尤其，快取是容量有限的記憶體，想要直接將資料儲存在快取中，雖然可以加快資料存取速度，但也將大幅提高成本，所以一般是將快取存放一些最頻繁使用的數據，又稱為熱數據（Hot Data），將這些存放在快取裡的熱數據，拆成多分，並採用水平拆分方式，儲存到不同機器上，藉此解決了熱數據存不下的問題；至於老舊資料或較沒人看的冷數據（Cold Data），則放在一般硬碟裡，以便於將有限快取容量用在儲存最熱的內容。

另外，他也提醒，快取用越多，一旦出現問題，也容易造成底層資料庫的使用瓶頸，嚴重更會引起整個系統的當機，因此，他建議在使用快取架構時，必須建立一套主／備援（HA）機制，至少要能夠設計成兩層快取，以便於當一個快取層出現問題，備用的快取層還可以快速接手，支撐這些服務請求，以避免大量請求直接穿過快取進到資料庫，一旦資料庫撐不住，就容易導致整個系統大當機。

最後一個挑戰，則是確保服務維持不中斷，李慶豐表示，關鍵在於採用多機房架構，以打造出容災能力更強的IT營運架構。他指出，目前微博採行資訊系統雙活中心（multi-datacenter），將現有主要機房和異地備援用的機房，打造成一個同時並行的雙主要機房，讓同一套資訊系統同時可以在兩地運作，提供相同的服務，並且兩邊資料可以保持一致。一旦任一機房出問題，另一機房能馬上接手提供原有的服務，也就達到了數據容災的多機房。

不過，兩地機房的數據同步，也會帶來影響工作執行、同步延遲，以及數據丟失等問題。他表示，通常解決的方式，則是依據分散式系統的CAP理論，視業務場景不同，來決定要滿足數據一致性（Consistency）、數據可用性（Availability），以及非區容忍性（Partition tolerance） 三項中的哪兩項要求。

不像電商、金融應用場景，對於數據一致性採取高標準，只要一有數據更新，所有節點上的數據在同一時間都要保持一致，李慶豐說，在微博社交場景下，對於數據一致性的要求就沒有這麼高，只需要確保兩地數據最終保持一致就行，並通過MCQ這個數據同步元件，讓異動數據與另一個機房對應的數據同步，來解決資料一致性的問題，發送請求也是相似作法。

面對4大高可用問題處理的3大前提

除了採用更先進的技術架構，李慶豐也提出3個前提，來因應發生容量、性能、服務依賴，以及容災4大問題的處理方式，首先是，「提前發現問題」，他指出，發現問題的方法有很多，可以通過事件監控，包含日誌、監控儀表板、閥值報警、以及自動應變機制來完成；其次是「提前做好應對計畫」，這些計畫項目包含對於容錯策略、服務擴容以及服務降級的緊急處置方案，以便於當有機器設備故障，可迅速找到問題機器將故障排除。當服務發生異常問題時，還需要仰賴「上下游團隊建立良好默契」的配合，這即是第3個前提，他說，這可以透過SLA服務協議建立一套指導原則的標準，例如機器性能達到什麼情況下，會出現哪些問題，以及該如何解決等，並透過監控體系來支撐，還要能做到模擬演練，這也是建構高可用架構不可缺少的一環。

微博下一代高可用架構將整合新興的服務網格技術

為了迎接更多新業務的挑戰，微博近來也開始引進了近兩年迅速竄紅的Service Mesh （服務網格）技術，用來打造新一代高可用架構。並且一開始先用於建立標準化的服務治理，以及解決跨程式語言調用的問題。以服務治理來說，他表示，這樣做的目的，是要將現有的服務基礎治理架構，自業務邏輯層抽離放到基礎設施裡，形成Mesh形式的網格，讓使用者請求遠端服務，都能像請求本地服務一樣容易。

又如想要通過具有基礎設施級別的本地Agent方式，如Motan、Restful、Yar、gRPC等來轉換各程式語言之間調用的協議，以產生這種更方便調用的方式，他發現同樣適合採行服務網格來達成，所以也用它來實作。

不論是服務治理或語言協議的轉換，微博都已導入服務網格，「接下來，更要把服務調用，甚至快取、儲存、對鏈調用，都用這種網格架構來完成，讓以後請求資源、服務就像請求本地的水和電一樣簡單。」李慶豐說。

為了迎接更多新業務的挑戰，微博近來也開始引進了近兩年迅速竄紅的Service Mesh （服務網格）架構，打造新一代高可用架構。一開始先用於建立標準化的服務治理，以及解決跨程式語言調用的問題。接下來，更要把服務調用，甚至快取、儲存、對鏈調用，都用這種網格架構來完成，讓以後請求資源、服務就像請求本地的水和電一樣簡單。攝影／余至浩