中文字幕免费精品_亚洲视频自拍_亚洲综合国产激情另类一区_色综合咪咪久久

這篇文章主要介紹了新浪微博的集群技術(shù)利用及網(wǎng)站業(yè)務(wù)架構(gòu),講到了緩存和消息隊列等微博的負載解決方案,需要的朋友可以參考下

據(jù)了解，隨著用戶數(shù)量的不斷擴增，在高峰期，新浪微博的服務(wù)器每秒要接受100萬以上的響應(yīng)請求，壓力可謂空前。童劍表示，面對如此高的并發(fā)訪問量，新浪在技術(shù)上所遇到的挑戰(zhàn)也相當大。比如整體的技術(shù)平臺如何做性能擴展?局部技術(shù)單元如何做性能擴展?并設(shè)計系統(tǒng)使能通過增加服務(wù)器即可實現(xiàn)服務(wù)能力擴容。不過，服務(wù)器數(shù)量的增加，會帶來服務(wù)器采購成本的激增，而大量服務(wù)器快速部署上線又會對效率提出新的挑戰(zhàn)，新困難層出不窮。

對此，新浪也在不斷地尋找更完善的解決方案來滿足他們的需求。新浪網(wǎng)研發(fā)中心平臺架構(gòu)部的思路是：

1、先規(guī)劃整體，從大的技術(shù)體系上來保證能有效解決性能問題、成本問題、效率問題、可靠性問題;

2、然后再從局部著手，保證每個技術(shù)單元都能夠從性能、可靠性方面滿足需求;

3、同時在應(yīng)用和系統(tǒng)的設(shè)計上，增加對故障容錯的處理能力;

4、在產(chǎn)品運維上，加強風(fēng)險控制，提高監(jiān)控的有效性。

而在海量數(shù)據(jù)的處理方面，新浪則分別利用Hadoop的HDFS實現(xiàn)海量數(shù)據(jù)存儲、用MapReduce實現(xiàn)分布式計算，有些數(shù)據(jù)還使用了HBase進行存儲和查詢。除此之外，也大量采用了Hive、Zookeepr等技術(shù)。

集群的運維管理和交互仍是Hadoop應(yīng)用瓶頸

Hadoop源于互聯(lián)網(wǎng)，也回饋于互聯(lián)網(wǎng)，互聯(lián)網(wǎng)企業(yè)可以說是當前Hadoop技術(shù)應(yīng)用最廣泛、最深入的領(lǐng)域。如今大多數(shù)機構(gòu)都已經(jīng)部署了各自的IT業(yè)務(wù)系統(tǒng)，Hadoop技術(shù)與現(xiàn)有IT架構(gòu)如何實現(xiàn)無縫整合，成為了許多用戶非常關(guān)心的話題。在童劍看來，目前互聯(lián)網(wǎng)領(lǐng)域的Hadoop應(yīng)用在大規(guī)模的使用情況下，瓶頸還是比較多的。一方面是集群的運維管理和監(jiān)控，這方面的工具現(xiàn)在還不夠成熟，需要運維工程師有較為豐富的經(jīng)驗。運維工程師除了要掌握硬件的資源使用情況，還需要部署一些管理軟件來實現(xiàn)管理。另一方面則是由于集群中各組件之間的交互響應(yīng)性能較差，在集群達到一定規(guī)模后，要有針對性的對其進行改進和優(yōu)化。

微博平臺的技術(shù)體系，使用正交分解法建立模型：在水平方向，采用典型的三級分層模型，即接口層、服務(wù)層與資源層；在垂直方向，進一步細分為業(yè)務(wù)架構(gòu)、技術(shù)架構(gòu)、監(jiān)控平臺與服務(wù)治理平臺。下面是平臺的整體架構(gòu)圖：

如上圖所示，正交分解法將整個圖分解為3*4=12個區(qū)域，每個區(qū)域代表一個水平維度與一個垂直維度的交點，相應(yīng)的定義這個區(qū)域的核心功能點，比如區(qū)域5主要完成服務(wù)層的技術(shù)架構(gòu)。

下面詳細介紹水平方向與垂直方向的設(shè)計原則，尤其會重點介紹4、5、6中的技術(shù)組件及其在整個架構(gòu)體系中的作用。

水平分層

水平維度的劃分，在大中型互聯(lián)網(wǎng)后臺業(yè)務(wù)系統(tǒng)的設(shè)計中非常基礎(chǔ)，在平臺的每一代技術(shù)體系中都有體現(xiàn)。這里還是簡單介紹一下，為后續(xù)垂直維度的延伸講解做鋪墊：

接口層主要實現(xiàn)與Web頁面、移動客戶端的接口交互，定義統(tǒng)一的接口規(guī)范，平臺最核心的三個接口服務(wù)分別是內(nèi)容（Feed）服務(wù)、用戶關(guān)系服務(wù)及通訊服務(wù)（單發(fā)私信、群發(fā)、群聊）。

服務(wù)層主要把核心業(yè)務(wù)模塊化、服務(wù)化，這里又分為兩類服務(wù)，一類為原子服務(wù)，其定義是不依賴任何其他服務(wù)的服務(wù)模塊，比如常用的短鏈服務(wù)、發(fā)號器服務(wù)都屬于這一類。圖中使用泳道隔離，表示它們的獨立性。另外一類為組合服務(wù)，通過各種原子服務(wù)和業(yè)務(wù)邏輯的組合來完成服務(wù)，比如Feed服務(wù)、通訊服務(wù)，它們除了本身的業(yè)務(wù)邏輯，還依賴短鏈、用戶及發(fā)號器服務(wù)。

資源層主要是數(shù)據(jù)模型的存儲，包含通用的緩存資源Redis和Memcached，以及持久化數(shù)據(jù)庫存儲MySQL、HBase，或者分布式文件系統(tǒng)TFS以及Sina S3服務(wù)。

水平分層有一個特點，依賴關(guān)系都是從上往下，上層的服務(wù)依賴下層，下層的服務(wù)不會依賴上層，構(gòu)建了一種簡單直接的依賴關(guān)系。

與分層模型相對應(yīng)，微博系統(tǒng)中的服務(wù)器主要包括三種類型：前端機（提供 API 接口服務(wù)）、隊列機（處理上行業(yè)務(wù)邏輯，主要是數(shù)據(jù)寫入）和存儲（mc、mysql、mcq、redis 、HBase等）。

垂直延伸技術(shù)架構(gòu)

隨著業(yè)務(wù)架構(gòu)的發(fā)展和優(yōu)化，平臺研發(fā)實現(xiàn)了許多卓越的中間件產(chǎn)品，用來支撐核心業(yè)務(wù)，這些中間件由業(yè)務(wù)驅(qū)動產(chǎn)生，隨著技術(shù)組件越來越豐富，形成完備的平臺技術(shù)框架，大大提升了平臺的產(chǎn)品研發(fā)效率和業(yè)務(wù)運行穩(wěn)定性。

區(qū)別于水平方向上層依賴下層的關(guān)系，垂直方向以技術(shù)框架為地基支撐點，向兩側(cè)驅(qū)動影響業(yè)務(wù)架構(gòu)、監(jiān)控平臺、服務(wù)治理平臺，下面介紹一下其中的核心組件。

接口層Web V4框架

接口框架簡化和規(guī)范了業(yè)務(wù)接口開發(fā)工作，將通用的接口層功能打包到框架中，采用了Spring的面向切面（AOP）設(shè)計理念。接口框架基于Jersey 進行二次開發(fā)，基于annotation定義接口(url, 參數(shù))，內(nèi)置Auth、頻次控制、訪問日志、降級功能，支撐接口層監(jiān)控平臺與服務(wù)治理，同時還有自動化的Bean-json/xml序列化。

服務(wù)層框架

服務(wù)層主要涉及RPC遠程調(diào)用框架以及消息隊列框架，這是微博平臺在服務(wù)層使用最為廣泛的兩個框架。

MCQ消息隊列

消息隊列提供一種先入先出的通訊機制，在平臺內(nèi)部，最常見的場景是將數(shù)據(jù)的落地操作異步寫入隊列，隊列處理程序批量讀取并寫入DB，消息隊列提供的異步機制加快了前端機的響應(yīng)時間，其次，批量的DB操作也間接提高了DB操作性能，另外一個應(yīng)用場景，平臺通過消息隊列，向搜索、大數(shù)據(jù)、商業(yè)運營部門提供實時數(shù)據(jù)。

微博平臺內(nèi)部大量使用的MCQ(SimpleQueue Service Over Memcache)消息隊列服務(wù)，基于MemCache協(xié)議，消息數(shù)據(jù)持久化寫入BerkeleyDB，只有g(shù)et/set兩個命令，同時也非常容易做監(jiān)控（stats queue），有豐富的client library，線上運行多年，性能比通用的MQ高很多倍。

Motan RPC框架

微博的Motan RPC服務(wù)，底層通訊引擎采用了Netty網(wǎng)絡(luò)框架，序列化協(xié)議支持Hessian和Java序列化，通訊協(xié)議支持Motan、http、tcp、mc等，Motan框架在內(nèi)部大量使用，在系統(tǒng)的健壯性和服務(wù)治理方面，有較為成熟的技術(shù)解決方案，健壯性上，基于Config配置管理服務(wù)實現(xiàn)了High Availability與Load Balance策略（支持靈活的FailOver和FailFast HA策略，以及Round Robin、LRU、Consistent Hash等Load Balance策略），服務(wù)治理方面，生成完整的服務(wù)調(diào)用鏈數(shù)據(jù)，服務(wù)請求性能數(shù)據(jù)，響應(yīng)時間（Response Time）、QPS以及標準化Error、Exception日志信息。

資源層框架

資源層的框架非常多，有封裝MySQL與HBase的Key-List DAL中間件、有定制化的計數(shù)組件，有支持分布式MC與Redis的Proxy，在這些方面業(yè)界有較多的經(jīng)驗分享，我在這里分享一下平臺架構(gòu)的對象庫與SSD Cache組件。

對象庫

對象庫支持便捷的序列化與反序列化微博中的對象數(shù)據(jù)：序列化時，將JVM內(nèi)存中的對象序列化寫入在HBase中并生成唯一的ObjectID，當需要訪問該對象時，通過ObjectID讀取，對象庫支持任意類型的對象，支持PB、JSON、二進制序列化協(xié)議，微博中最大的應(yīng)用場景將微博中引用的視頻、圖片、文章統(tǒng)一定義為對象，一共定義了幾十種對象類型，并抽象出標準的對象元數(shù)據(jù)Schema，對象的內(nèi)容上傳到對象存儲系統(tǒng)（Sina S3）中，對象元數(shù)據(jù)中保存Sina S3的下載地址。

SSDCache

隨著SSD硬盤的普及，優(yōu)越的IO性能使其被越來越多地用于替換傳統(tǒng)的SATA和SAS磁盤，常見的應(yīng)用場景有三種：1）替換MySQL數(shù)據(jù)庫的硬盤，目前社區(qū)還沒有針對SSD優(yōu)化的MySQL版本，即使這樣，直接升級SSD硬盤也能帶來8倍左右的IOPS提升；2）替換Redis的硬盤，提升其性能；3）用在CDN中，加快靜態(tài)資源加載速度。

微博平臺將SSD應(yīng)用在分布式緩存場景中，將傳統(tǒng)的Redis/MC + Mysql方式，擴展為 Redis/MC + SSD Cache + Mysql方式，SSD Cache作為L2緩存使用，第一降低了MC/Redis成本過高，容量小的問題，也解決了穿透DB帶來的數(shù)據(jù)庫訪問壓力。

垂直的監(jiān)控與服務(wù)治理

隨著服務(wù)規(guī)模和業(yè)務(wù)變得越來越復(fù)雜，即使業(yè)務(wù)架構(gòu)師也很難準確地描述服務(wù)之間的依賴關(guān)系，服務(wù)的管理運維變得越來難，在這個背景下，參考google的dapper和twitter的zipkin，平臺實現(xiàn)了自己的大型分布式追蹤系統(tǒng)WatchMan。

WatchMan大型分布式追蹤系統(tǒng)

如其他大中型互聯(lián)網(wǎng)應(yīng)用一樣，微博平臺由眾多的分布式組件構(gòu)成，用戶通過瀏覽器或移動客戶端的每一個HTTP請求到達應(yīng)用服務(wù)器后，會經(jīng)過很多個業(yè)務(wù)系統(tǒng)或系統(tǒng)組件，并留下足跡（footprint）。但是這些分散的數(shù)據(jù)對于問題排查，或是流程優(yōu)化都幫助有限。對于這樣一種典型的跨進程/跨線程的場景，匯總收集并分析這類日志就顯得尤為重要。另一方面，收集每一處足跡的性能數(shù)據(jù)，并根據(jù)策略對各子系統(tǒng)做流控或降級，也是確保微博平臺高可用的重要因素。要能做到追蹤每個請求的完整調(diào)用鏈路；收集調(diào)用鏈路上每個服務(wù)的性能數(shù)據(jù)；能追蹤系統(tǒng)中所有的Error和Exception；通過計算性能數(shù)據(jù)和比對性能指標（SLA）再回饋到控制流程（control flow）中，基于這些目標就誕生了微博的Watchman系統(tǒng)。

該系統(tǒng)設(shè)計的一個核心原則就是低侵入性（non-invasivenss）：作為非業(yè)務(wù)組件，應(yīng)當盡可能少侵入或者不侵入其他業(yè)務(wù)系統(tǒng)，保持對使用方的透明性，可以大大減少開發(fā)人員的負擔和接入門檻。基于此考慮，所有的日志采集點都分布在技術(shù)框架中間件中，包括接口框架、RPC框架以及其他資源中間件。

WatchMan由技術(shù)團隊搭建框架，應(yīng)用在所有業(yè)務(wù)場景中，運維基于此系統(tǒng)完善監(jiān)控平臺，業(yè)務(wù)和運維共同使用此系統(tǒng)，完成分布式服務(wù)治理，包括服務(wù)擴容與縮容、服務(wù)降級、流量切換、服務(wù)發(fā)布與灰度。

結(jié)尾

現(xiàn)在，技術(shù)框架在平臺發(fā)揮著越來越重要的作用，驅(qū)動著平臺的技術(shù)升級、業(yè)務(wù)開發(fā)、系統(tǒng)運維服務(wù)，本文限于篇幅限制，沒有展開介紹，后續(xù)會不斷地介紹核心中間件的設(shè)計原則和系統(tǒng)架構(gòu)。