企業IT架構轉型之道阿里中臺戰略思想與架構實戰打造平臺穩定性能力構建業務中臺基礎數據拆分實現數據庫能力線性拓展共享服務體系搭建打造數字化運營能力共享服務中心建設原則異步化與緩存原則構建業務中臺基礎成功啟示：口保持精簡團隊，

Cell細胞開發團隊：

一般2個-5個員工，最多不超過7個員工組成獨立的開發團隊，稱之為Cell(

細

胞

)口顛覆組織結構，決策交給團隊：團隊自己決定做什么樣的產品，然后最快時間推出產品的公測版，

沒有管理角色的介入口不懼失敗，為失敗慶祝：團隊研發產品失敗后，不會受到懲罰，甚至會舉辦慶祝儀式，從失敗中

學到了東西口厚平臺，薄應用：公司所構建的“中臺”能力，才是支撐小團隊研發的核心口

阿里中臺戰略：2015年馬云帶領阿里高管拜訪公司之后，啟動了阿里巴巴的2018年中臺戰略。Supercell

的研發核心思維

Think

Small小團隊模式Supercell(超級細胞),芬蘭移動游戲巨頭。擁有《部落沖突》、《卡通農場》、《海島奇兵》和《皇室戰爭》等全球熱門

游戲。2016年6月，騰訊收購Supercell84.3%

的股份，作價86億美元，整個公司估值102億美元。這不僅是騰訊歷史上，也

是近年全球手機游戲行業最大金額的并購。根據騰訊的公告，這家總部位于芬蘭的公司，目前員工總數僅有190人。按照102

億美元的估值，平均每個員工對應的估值折合約3

.5億人民幣。SupercellCEO

IlkkaPaananen我的職責就是讓員工——所有資深游戲開發者在一個“小團隊”

或內部叫"Cells(細

胞

)"內

工作，他們有權做決定，尤其是

擁有是否砍掉游戲項目的權利。淘寶天

貓大淘寶雖然組織架構上共享業務事業部和淘

寶、天貓平級，但從對業務的理解和

業務貢獻的體現來說，淘寶和天貓相

對共享業務事業部擁有著更多的話語

權，結果就是共享業務事業部在兩大

業務部門的業務需求下艱難生存著。阿里巴巴共享業務事業部的發展史2008年時集團成立了天貓4、然后集團希望是這樣的共享業務事業部2003年時成立了淘寶事業部3、后來好像是這樣的天貓淘寶成立天貓事業部淘寶的技術團隊同時支持著淘寶和

天貓的業務淘寶

天貓在2009年，共享業務事業部應運而生共享業務事業部5、結局可能是這樣的2、后來是這樣的1、最初始這樣的阿里巴巴集團業務Ali

Express

1688

淘寶天貓聚

劃

算阿里去啊口碑阿里媽媽菜鳥物流支撐恭亳業務事業部_i業務共享單元用戶中心

商品中心交易中心評價中心店鋪中心

搜索中心數據服務中心

營銷中心阿里巴巴共享業務事業部在業務架構中的重要地位目前阿里巴巴集團前端超過25個業務單元(如淘寶、天貓、聚劃算、去啊等大家熟知的業務)均不是獨立地構建在阿里云的云平臺之上，在后端阿里云技術平臺和前

端業務間有了一個"共享業務事業部",將阿里巴巴集團前端業務中公共、通用的業務沉淀到了這個事業部，包含了用戶中心、商品中心、交易中心、評價等十幾個

中心，而共享業務事業部正是“厚平臺”的真實體現，為阿里巴巴各種前端業務提供著相應服務中心領域內最為專業、穩定的業務服務。監控報警故障處理系統升級應用發布安全防控業務監控運維保障部真正的轉折來自2010年聚劃算的出現，由于它強大的流量吸引威力，淘寶和天貓都競相與其業務對接。

集團要求三大電商平臺與聚劃算平臺進行業務對接，必須通過共享事業部!支撐分布式應用服務平臺EDAS彈性計算服

關系型數據庫服務

開放存儲服務ECS

RDS/DRDS

務OSS分布式文件系統(盤古)任務調度(伏羲)大禹集群布署阿里云平遠程過程調用(夸父)分布協同服務(

女

媧

)開放緩存服務

OCS安全管理(鐘馗)開放數據處理服務

ODPS神農集群監控資源管理(伏羲)開源

用戶消息服務MQ臺回歸SOA

的本質-服務重服務需要不斷的業務滋養共享服務體系是培育業務創新的土壤賦予業務快速創新和試錯能力為真正發揮大數據威力做好儲備改變組織陣型會帶來組織效能的提升構建業務中臺的基礎

共享服務體系共享服務架構的建設使得阿里巴巴擺脫了因為“"煙囪式”系統建設方式所帶來的種種發展桎梏，最終成為阿里巴巴業務中臺戰略的核心組成。基于共享服務體系建設的服務中心，原生就將相關業務領域的業務功能和數據做了很好的統一，阿里超過2000多個應用，在核心業務層已經

通過共享服務體系實現了統一和暢通，所以沒有類似ESB

的組件，避免了打通不同系統間實現業務交互帶來的集成和協作成本。訂單創建流程1交易中心交易管理前端$交易服務訂單創建流程1商品中心商品管理前端$商品服務支付中心支付管理前端$支付服務支付數據會員中心會員管理前端會員服務會員數據價值1:

回歸SOA的本質-服務重淘寶網T服務交互個

個聚劃算-juhuasuan,com-

com全球最大的采的批發市場團購

訂單

檢查共享服務訂單創建流程訂單創建流程數據層交易

日志交易

創建交易

創建交易

創建其他

服務交易

創建庫存

檢查其他

服務其他

服務用戶

檢查其

他

服

務交易數據用商品數據服務交互服務交互服務交互價值2:

服務需要不斷的業務滋養服務不需要“業務穩定”,而需要不停的滋養，只有在滋養中才能從最初僅提供單薄業務功能的服務逐漸成

長為企業最為寶貴的IT資產，而服務所需的滋養正是來自新的業務不斷進行服務的接入。專業帶來穩定穩定

數據線下線上數據

產品創新服務能力不斷能提升服務業務滋養開放實現對內對

外的開放開放平臺支付平臺電商業務物流系統020服務滋養淘寶網T點共享業務事業部交易中心(TP)自動

發貨數據完整性價值3:

共享服務體系是培育業務創新的土壤各業務交易流程架構師->交易中心中的業務人員及架構師從來自不同業務的"點"->擴展到線和面的維度全面掌控交易的業務(領域業務專家)閑

魚以印的gmae

率!點天貓TnALLcon點聚劃算-juhusancom刪除

訂單訂單

拆分關閉訂單確認

收貨訂單

查詢修改

價格創建

訂單全網規則安全校驗金培大的的批家Notify付款點點2com小前端團隊具備的特征：團隊協同效率最高

對戰機(商機)的把握更加敏銳

調整方向更加快捷一旦發現正確目標，全力投入擴大戰果戰場中的中臺陣型價值4:

賦予業務快速創新和試錯能力打造好的業務中臺，降低企業創新試錯成本，快速推向市場，市場的反饋決定業務投入。因

為

美軍擁有強大的導彈指揮系統，強大的中后臺能力，支持小團隊快速判斷，引領進攻完成。二戰

美軍以軍為單位作戰越戰

美軍以營為單位作戰中東美軍以7人-11人極小班排作戰>用戶、商品、交易等在業務和

數據層融合>業務數據歸整和沉淀>高質量的業務數據>優秀數據科學家，可遇不可求

>靠企業自我培養，共享服務體系培育懂業務的專家價值5:

為真正發揮數據威力做好儲備大數據項目的兩個凸顯問題共享服務體系的解決之道缺少能基于數據有業務建模能力的專家數據分布廣、格式不統一、不標準價值6:

改變組織陣型會帶來組織效能的提升·

針對每一個建設的服務中心，從組織架構的形態上調整，不同角色人員(架構師、

開發人員、

UED工程師等)組建了一個新的組織，每個組織對某一服務中心提供持

續的服務能力開發及運維。·

業務架構師成為團隊最核心的角色，也是業務負責人，懂技術和業務。成為服務中

心業務發展的領路者，也是保障服務中心核心業務保持業務通用性和公共性的最重

要的捍衛者。共享服務體系搭建一

個服務中心不單單是在企業的幾個應用中發揮作用，它可能會給企業上百個不

同的應用提供專業服務，

一

旦這個服務中心出了問題，將會對企業的運營產生難

以估量的損失和影響，這樣就對這些服務中心的服務穩定性、服務能力的擴展性、

服務需求的快速響應能力提出了前所未有的更高要求。這就需要有

一套成熟、完

善的技術體系來支撐整個共享服務體系，使得企業在業務發展的過程中，對這些

共享服務的支撐能力不會有任何后顧之憂。項目團隊間協同成本高，業務響應越來越慢業務復雜度已超出人的認知負載錯誤難以隔離數據庫連接能力很難擴展應用擴展成本高分布式服務框架的選擇構建共享服務體系，必然需要采用一套服務化框架來支撐整個服務體系的運轉。淘寶從單一系統模式轉

變為服務化架構的過程，“去中心化”服務架構成為今天絕大多數互聯網平臺所采用的服務框架。2007年的淘寶500人技術團隊，淘寶網站幾百兆字節的WAR

包，功能模塊超過200個傳統架構的弊端業務模用戶服務中心交易中心類目中心剝離商品中心店鋪中心淘寶平臺的服務化改造(

SOA+業務模塊逐步遷移

)2007年10月開始一系列基于SOA理念新一代服務化框架研發以及采用業務模塊逐步遷移的方式進行應用框

架的改造工作。幾百兆字節WAR包

飛行中的飛機換發動機

上百個WAR包獨立部署的服務化架

構千島湖項目五彩石項目歷時14個月拆分淘寶平臺塊淘寶平臺的服務化改造后的效果降低不同模塊開發團隊間的協同成本業務拆分后解放了對單數據庫集群連接數的能力依賴數據層也做了拆分，每一個核心服務中

心都擁有各自獨立的數據庫(分布式數據庫技術)避免了個別模塊的錯誤給整體帶來的影響各個服務中心之間完全獨立部署大大降低系統間的耦合度以及整體復雜度

各個開發團隊可專注于各自的業務模塊做到針對性的業務能力擴容

減少不必要的資源浪費業務響應更迅捷SOA

的主要特性：中心化與去中心化服務框架對比傳統軟件廠商提出的以ESB

(企業服務總線)實現SOA的方案是中心化服務框架；互聯網架構和技術下，流行去中心化的服務框架。有一部分人認為去中心化不是SOA架構。中心化與去中心化是同一套體系SOA并沒有定義一定是基于ESB總線方式>

去中心化分布式服務框架同樣遵循SOA

架構的特征定義去中心化是中心化服務框架的升級版本，兩套

系統解決企業根本訴求完全不同。ESB

模式中心化解決企業實現異構系統之間的

交互。核心目的是讓企業客戶能基于這些SOA

的產品實現系統間的互聯互通。去中心化解決的問題是系統擴展性問題。口面向服務的分布式計算

口服務間松散耦合口支持服務的組裝服務注冊和自動發現以服務契約方式定義服務交互方式服務調用者服務提供者服務提供者服務調用者服務調用者服務提供者中心化與去中心化服務框架對比服務調用方式的不同帶來業務的響應和擴展成本在淘寶上點擊"立即下單"或“結算”按鈕進行下訂單的請求，后端調用了200多個服務。服務調用者服務調用者企業服務總線(ESB)服務提供者服務提供者分布式服務架構中的服務交互方式經過服務總線路由過的服務交互，共出現4次網絡會話創建和數據

傳輸，而去中心化服務架構中服務交互，

一次服務的調用只有兩

次網絡會話創建和數據傳輸，在網絡上的開銷整整減少了一半。傳統企業服務總線下的服務交互方式(1)服務調用者->(2)ESB接受服務請求->(3)服務

提供者(服務處理)->(4)ESB

服務提供返回結果-

>(5)服務調用者(服務返回)中心化與去中心化服務框架對比雪崩效應束縛了中心化服務框架的擴展能力當10臺中一臺實例出現故障,服務壓力落到剩余

9

臺ESB

服務器，每臺負載水位將超過88%,出

問題的概率會大增。如果9臺中有一臺不堪重負

而罷工，瞬間被訪問洪流沖垮，雪崩效應導致全

軍

覆

沒

。服務器集群(假設10臺)企業服務總線

ESB

服務器企業服務總線

ESB

服務器去中心化服務框架則可以避免因為個別問題波及整個平

臺的業務受到影響，最多也只是部分服務出現問題，就

算出現問題也更容易定位問題和故障恢復。企業服務總線ESB服務器企業服務總線ESB

服務器企業服務總線

ESB

服務器企業服務總線

ESB

服務器企業服務總線

ESB

服務器ConfgServerCientlpocontosever

ServerPFap阿里巴巴分布式服務框架HSF(

HighSpeed

Framework

)HSF旨在為淘系的應用提供一個分布式的服務框架，

HSF從分布式應用層面以及統一的發布/調用方式層面為大

家提供支持，從而可以很容易的開發分布式的應用以及提供或使用公用功能模塊，而不用考慮分布式領域中的

各種細節技術，例如遠程通訊、性能損耗、調用的透明化、同步/異步調用方式的實現等等問題。服務提供者HSF

應

用HSF應

用HSF應

用1.獲取服務器列表4.服務訂閱2.返

回

服務器列表地址服務器HSF應HSF

應HSF應1.獲取服務器列表MYSQL

服務器6.

規則推送Diamond

服務器5.返回服務提供服務器列表配置服務器3.服務注冊用用用7服務交互服務調用者2.

返回服務器列表規

則

推

送CientDiamondServer①服務調用②調用失敗③自動重試其他服務提供者HSF應

用配置服務器(基于內存配置管理)阿里巴巴分布式服務框架HSF(High

Speed

Framework)按照服務注冊發布、服務訂閱、服務規則推送、最終服務提供者和服務調用者間的服務交互的順序說明了HSF

服務框架中每個組件在整個框架中所扮演的角色。HSF

服務框架實現服務高可用性原理示意圖服窮提供者服務調用者應用應用HSFHSF阿里巴巴分布式服務框架HSF(High

Speed

Framework)HSF

服務框架對服務能力線性擴展支持作為HSF

框

架

設

計

之

初

，最為重要的一個特性就是服務能力的可擴展性。也就是真正的做到某個服務的業務

處理能力能隨著服務器資源的增加得到線性的增長。當服務面對較大的服務調用壓力或將要面臨如天貓雙11大促、秒殺等活動前，已有的服務提供者各服務器水位(CPU

、

內

存、10等)處于比較高的情況或現有服務能力滿足不了業務訪問量的要求時，則需要通過增加服務節點數量的方式提升該服務的

服務處理能力。基于

HSF

框架的運行機制，新增加的服務提供者實例一旦應用啟動完成后，可在幾秒內開始進行服務請求的

處理(主要完成服務注冊發布、更新后服務列表推送到服務調用者端),從而達到分擔其他服務器實例壓力的作用，實現服務

能力整體水位恢復到正常的狀態微服務架構典型特征·

分布式服務組成的系統·按照業務而不是技術來劃分組織·

做有生命的產品而不是項目·

智能化服務端點與傻瓜式服務編排·

自動化運維·

系統容錯·

服務快速演化微服務從本質上來說，微服務是SOA的一種演變后的形態，與SOA的方法和原則沒有本質的差別。特征傳統SOA微服務分布式服務組成的系統中心化構建服務架構；采用系統提供服務的方式多個分布式的服務組成按照業務而不是技術來劃分組

織以及做有生命的產品而不是

項目項目方式實施產品方式讓服務在業務發展過

程中快速演化智能化服務端點與傻瓜式服務編排所有核心能力都運行在ESB上更加強調能力向服務端的遷移自動化運維和系統容錯運維管控和平臺高可用性和穩

定性提出更高要求微服務與傳統SOA特征差異共享服務中心建設原則用戶中心商品中心平臺交易中心平臺營銷中心平臺店鋪中心庫存中心庫存中心進入平臺化階段淘寶共享服務中心建設歷程服務和服務中心都是伴隨業務發展變化的，淘寶共享服務體系的發展從服務化到平臺化。用戶中心商品中心交易中心評價中心營銷中心店鋪中心庫存中心全面服務化階段用戶中心商品中心交易中心店鋪中心嘗試服務化階段服務中心中的服務形態多樣性有些人理解的服務中心是狹義的接口服務，這比較片面化，接口是服務最主要的形式。

如果服務中心的服務完全拘泥于接口這種形式，那又大大局限了服務中心的服務能力。依賴于數據的服務對大數據的分析能力實時交易型的數據能力一定是通過接口服務對外暴露依賴于接口的服務上層應用提供編程接口

RPC或WebAPI依賴于工具的服務一類用于提供定制的配置服務

一類是運營管理類的工具一個服務中心可以進一步劃分嗎?服務中心是根據業務和數據的完整性與獨立性來設立的，并不需要——對應。往往需要多個子服務模

塊協作配合才能更好地實現服務中心對外服務效率的最大化。交易中心訂單服務

購物車服務會員數據

交易數據會員中心會員服務單個服務模塊

多個服務層替

霧數據基于分布式架構，要綜合評估業務層對服務中心在數據庫、業務以及運營方面的需求和技術上需要的投入。完整的業務模型，要有數據運營和業

務整合的價值。服務中心劃分原則-考量方面遵循面向對象的分析和設計方法高內聚、低耦合原則數據完整性原則業務可運營性原則漸進性的建設原則服務中心劃分原則數據拆分實現數據庫能力線性擴展數據庫瓶頸阻礙業務的持續發展采用讀寫分離的方式，拓展了數據庫對數據讀的處理能力，主數據庫的寫入能力依然沒法擴展。單表數據量是有限的，當達到一定數量后數據庫性能會出現顯著下降。寫數據復制主數據庫讀從數據庫從數據庫從數據庫…

…采用讀寫分離方式擴展數據庫讀寫能力用戶中心應用UserlD%8=0水平分區用戶中心數據庫UserlD

%8=3用戶數據按用戶ID取模機型數據均衡拆分數據庫水平分區實現數據拆分將同一個表中的不同數據才拆分到不同的數據庫中。以用戶中心為例，淘寶平臺用戶量接近6億，存到一個數據庫的單表是不可能的。UserlD%8=1UserlD%8=2數據庫分庫分表的實踐-Cobar分布式處理系統2006年阿里巴巴B2B團隊以開源方式研發了Cobar

關系型數據的分布式處理系統。解決了Oracle數據庫因為存儲數據變得越來越大帶來的擴展性問題。不支持跨庫情況下的連接、分頁、排序、子查詢操作SET

語句執行會被忽略，處理事務和字符集設置除外>

分庫情況下，

insert語句必須包含拆分字段列名>

分庫情況下，

update語句不能更新拆分字段的值不支持SAVEPOINT操作>使用JDBC時，不支持rewriteBatchedStatements=true參數設置(默認false)使用JDBC時，不支持useServerPrepStmts=true參數設置(默認為false)使用JDBC時，BLOB、BINARY、VARBINARY字段不能使用setBlob()或setBinaryStream()方法設置參

數TDDL

其實主要可以劃分為3層架構，分別是Matrix層、Group層和Atom層。>Matrix

層用于實現分庫分表邏輯，底層持有多個Group實例。而Group層和Atom共同組成了動態數據

源>Group

層實現了數據庫的Master/Salve

模式的寫分離邏輯，底層持有多個Atom

實例。>Atom

層(TAtomDataSource)實現數據庫ip,port,password,connectionProperties等

信

息

的

動態推送，以及持有原子的數據源分離的JBOSS

數據源)Ibatis

SpringjdbctemplateTDDL

matrixds(TDataSource

)TDDLgroup

dsTDDLatomds(withjboss

ds

)JDBC

Driver數據庫分庫分表的實踐-TDDL2008年阿里巴巴內部基于淘寶業務發展的需要，在Cobar的基礎上重新研發了分布式數據層框架TDDL(Taobao

DistributedDataLayer),針對分庫分表場景，提供了對各種業務場景的支持更加完善，開發人員體驗更好，

管控能力大幅提升。TDDL

架構示意圖MySQLOracleSQL

和參數表名替換根據權重選AtomDS讀寫數控制、線程并發數控制數據庫分庫分表的實踐-TDDLTDDL

針對一次SQL

請求完整處理流程選

擇groupDS

執行SQL合并處理多個結果集執行SQL,

返

回結果集具有重試策略地在

AtomDS執行SQL查詢或更新結果規則計算SQL解析ID

mo8/2=13IDmo8/2=25ID

met8/2=31I0

mo8/2=4淘寶人自定的TDDL優點：1、

數據庫主備和動態切換；2、

帶權重的讀寫分離；3、

單線程讀重試；4、

集中式數據源信息管理和動態變更；5、

剝離的穩定jboss

數據源；6

、

支持mysql

和oracle

數據庫；7

、

基于jdbc規范，很容易擴展支持實現jdbc規范的數據源；8、

無server,client-jar形式存在，應用直連數據庫；9、

讀寫次數，并發度流程控制，動態變更；10、

可分析的日志打印，日志流控，動態變更。數據庫分庫分表的實踐-TDDLselect.

….wherei

in[1,3,7]TDDL分庫分表查詢策略TAB3TAB4TAB_5

TAB_6TAB1TAB2TAB_7TAB_812468異步化與緩存原則庫存預減流水其它服務訂單日志支付生成業務流程異步化平臺進行服務化后，在平臺頁面上發起的業務請求勢必需要將后端不同的服務進行組合調用來實現業務請求的

處理。以淘寶的交易訂單為例，目前淘寶的訂單創建流程需要調用200個服務。如果按照順序執行，需要超過4s淘寶交易流程按服務線性處理的示意圖缺點：從資源占用角度來說，順序調用方式會造成系統處理一次前端請求所花的時間較長，對服務器整體的系統吞吐量帶來巨大影響。淘寶交易流程異步化后的處理的示意圖平均時間控制在300ms,

體驗好，吞吐量幾何倍數提升消息中間件消息中間件交易

日志庫存

預減支付

生成其它100

多個服務訂單

生成庫存

檢查訂單生成庫存預減計算還款詳單扣占款給詳單對應借款人賬號轉入錢更新還款詳單表發起還款請求計算還款金額借款人賬號占款解決平臺性能問題的核心是數據庫

事務的異步化。將大事務拆分成小

事務，降低數據庫的資源被長時間

事務鎖占用而造成的數據庫瓶頸，

就能大大提升平臺的處理吞吐量和

事務操作的響應時間。基于消息服務提供

的異步機制，將整

個還款流程進行異

步化的處理。整個平臺對還款的

處理能力相比之前

提升了20倍以上。數據庫事務異步化還款計劃處理(循環)用戶還款流程HSF調用HSF提供者SocketSQLSocket

TDDL/TXCDS&RMTDDL/TXCDS&RM(TM)分庫分表saMySQL1

MySQL2MySQL3SocketTXC

也是阿里基于兩階段提交理論實現的分布式事務框架，支持分布式數據庫事務、多庫事務、消息事務、

服務鏈路調用事務及各種其他事務。和支付寶XTS

框架相比，主要區別有兩個：

一

是主事務和分支事務都是

維

護

在

同

一

臺TXC

服務器上的；二是事務回滾或補償代碼不需要開發人員編寫，平臺支持自動生成。阿里巴巴AliWareTXC事務服務事務發起者(Client)TXC

ServerHSF提供者TDDL/TXCDS&RM本地SQLMySQL4SQLsaGTS

是一款分布式事務中間件，由阿里巴巴中間件部門研發，可以為微服務架

構中的分布

式事務

提

供一

站式

解

決方

案。GTS包括客戶端

(GTSClient)

、資源管理器(GTSRM)和事

務

協

調

器(GTSServer)三個部分。GTSClient主

要用來

界

定事務

邊

界，

完

成事務的發起

與結

束。GTSRM完成事務分支的創建、提交、回滾等操作。GTSServer主

要負責分

布式事務的

整

體

推

進，事務

生命周

期的管

理

。GTSClient微服務BGTS

RM數據庫微服務AGTS

RM數據庫微服務CGTS

RM數據庫GTS服務(事務協調器)s253業務應用大促秒殺活動催生緩存技術的高度使用tair

是淘寶自己開發的一個分布式key/value

存

儲

引

擎

，tair

分為持久化和非持久化兩種使用方式，非持久化的tair

可以看成

是一個分布式緩存。持久化的

tair將數據存放于磁盤中，為了解決磁盤損壞導致數據丟失，tair

可以配置數據的備份數目，

tair自動將一份數據的不同備份放到不同的主機上，當有主機發生異常，無法正常提供服務的時候，其余的備份會繼續提供服務。tair作為一個分布式系統，是由一個中

心控制節點和一系列的服務節點組成.我們稱中心控制節點為config

server.

服務節點是data

server。·

configserver負責管理所有的dataserver,維護dataserver的

狀

態信息。·

dataserver

對外提供各種數據服

務，并以心跳的形式將自身狀況匯

報

給configserver。·configserver是控制點，而且是單

點，目前采用一主一備的形式來保

證其可靠性.所有的

data

server地位都是等價的。ClientData

ServerClientData

ServerClientData

ServerClient交換機Master

、Config

Server!SlaveData

Server本地緩存Detail庫存.IC庫存秒殺ICICDB比如庫存為10個，秒殺價格為1元的

手機則是典型的小庫存商品秒殺活動。因為商品會在極短的瞬間庫存會降到0

,所以只要處理好商品的庫存的扣減

,不要出現商品超賣的情況就能平穩

地度過這次秒殺活動。小庫存商品秒殺典型架構Tair消除

庫存普通商品Buy0.1加載初始庫存--

1

.

查看

·

米

2.購買用戶

IC

3.確

認購買查詢秒殺商品/初始庫存信息ICDBTair秒殺商品實時庫存1.1獲取庫存一Detail緩存商品基本信息-3.1獲取庫存-

-2.1獲取庫存3.2更新庫存Buy

緩存商品基本信息將訂單交易創建環節中對于原本

商品數據庫的庫存信息操作替換

為緩存服務器中運行，充分展現

了緩存服務相比于傳統數據庫在

性能上的巨大優勢。從趨勢來看

,緩存技術將會在互聯網應用場

景中將扮演越來越重要角色。大庫存商品大促架構打造數字化運營能力消息服務器發消息收

消息收消息

收

消

息商品優惠服

務

調

用

服

務

調

用

服務調用

服務調用

服務調用庫存檢查存取DBC

JDBC數據庫

分布式緩存

分布式文件系

統業務服務帶來的問題復雜的服務調用關系以及每天海量的服務調用，而且所有服務都是以點對點的方式進行交互，導致出現問題時很

難定位，甚至出現問題沒人承認。服務開發人員和業務架構師對于分布式服務調用跟蹤方面的需求。淘寶平臺服務化后錯綜復雜的服務調用關系圖

圖淘寶訂單創建服務調用流程示意用戶信息讀緩

存無城客戶罐請

宗開致平食API

請求腳

頁請

本田務網用優惠信息快遞優惑用戶校驗訂單檢查訂單創建服務測行鷹眼平臺的架構-核心實現思路如果把淘寶的分布式服務架構比喻為遍布全國的高速公路網絡，每一次的頁面請求可以認為是一輛汽車在這個

高速公路網絡中穿行把高速上每一個收費站比喻為處理請求的服務。那么我們希望查看一輛汽車在高速上的行

走軌跡，如何實現?最簡單的方法就是在這輛車每次經過收費站的時候記錄下車輛通過的時間和相關信息，并

將這些信息統一發送到服務器端保存起來。鷹眼平臺的核心實現思路就是通過一套分布式日志平臺實現對服務調用鏈路的跟蹤。[2013-05-0112:23:34]魯A123BC,

平度2,516,濟南，$0[2013-05-0112:23:40]魯A987DE,

平度2,516,淄博，$10[2013-05-0112:43:15]魯A123BC,

濰坊1,520,濟南，$18[2013-05-0113:38:29]魯A123BC,

青州西1,G20,

濟南，$10[2013-05-0113:38:30]魯A567AB,

青州西2,G20,

廊坊，$10[2013-05-0114:39:27]魯A123BC,

淄博3,G20,濟南，$15[2013-05-0116:42:58]魯A123BC,

濟南3,G20,

濟南，$25-[2013-05-0112:23:34]平度2,旅途開始-[2013-05-0113:38:29]青州西1,耗時75分鐘，路費10元-[2013-05-0114:39:27]淄博3,耗時61分鐘，路費15元-[2013-05-0116:42:58]濟南3,耗時123分鐘，路費$10元汽車通過高速收費口日志記錄信息某輛車經過不同高速收費口日志記錄信息應用集群追實時收取日志讀取鷹眼Storm

集群全量日志MapReduceHDFS計算結果讀取原始日志與分析結果數據輸出與展現鷹眼平臺是阿里巴巴中間件

團

隊

自

主

研

發的Jstorm

流式計算引擎

,

對應用集群接收到的

日志進行內容的解析拆

分，按照不同業務場景

的需求將拆分后的數據

保存到不同的存儲系統。的中間件日志文件鷹眼平臺的架構日志收集agentHadoop

集群寫入統

計數據心實時收取日志鷹眼服務器帶鷹眼埋點實時

數據實時日志HBase寫入埋點和輸出日志將實現服務調用、各種資源的訪問所需要生成服務鏈路日志，以及TraceID

傳遞等功能的代碼(稱為埋點)植入

到服務框架層和各資源的訪問驅動層，也就是在中間件層面上統一實現了鷹眼的上下文創建以及日志埋點功能。

前端應用請

求start一clientSendclientRecvclientSendclientRecv響

應endTrace后端應用1服務調用服務響應服務調用服務響應數據庫圖示創建

上下文清理

上下文clientSend數據訪問clientRecvserverSendserverRecvserverSendserverRecvclientRecvclientSend數據訪問后端應用2rpdd應用名類型狀態大小據務/方法時間軸0

Sbuy

TRACE

OK

1.20B

http://buy.t0030.com/aucton/order/unty_oxder_confmhtm0.1

delvery8.1K8590.20.30,40.50.60.70.80.8.10.90.100.110.120.130.13.1

0.140.15teeinventorypbtform

閑inventoryptatform

inventorypltforminventoryplitforminventorypbtforminventoryplatform(dbetmal_invent

detwerytradepLtformuppdolveryTtradepbtfor(notfyotrade)

tradepbtfontradepbitformSFHHTDOLHFSFHSFOTFY吳吳吳吳吳吳吳吳吳吳吳吳吳吳吳吳1.85.3K4.6B4.4.5KS4,5K34.588.3808

1.3N7.90

12.6K8

49.0K2.5083.288

1.3量有kIYxxxhrxà0.160.170.180.190.200.210.220.22.10.230.23.10.23.1.tradepbtformtradeplitformtradeputfarmtradepbtformtradeplatfortradepLtform田tradeplatfonm(notityotrade)S

tradeplatforms(notfyotrade)tradeloosNOTFYHFNOTFYNOTFYBL2ER1.701.3K82.1KB1.31.3K813.4KS8158

2.2014.2K0

2.38mm1+

1|9m22204m0.23.1.

hitaoerpNOTFY20.23.1.(taroitem)TAR

NOTEST618t0.23.1.0.23.1.0.23.1.0.23.1.0.23.1.(tar0comm)TA頂hitaotradefaceHOTFYtrade

sub2_noHOTFY(dbotradesut

TDOLs

trade

sub_notNOTFY吳吳吳吳吳5882.82.822m0.23.1.

(dbonotly

t

TDOL

OKns典型業務場景-調用鏈跟蹤ac189a7e13736980753842965調用鏈入口P:,開始時間：2013-07-1314:47:55.384,調用團總時長：609ms

·

日志原文

PpCID289條調用記錄，總耗時609ms禺著美吳美美言吳吳原重重重重重重壹吳二x層次名稱應用QPS焊值QPS調用

次數平均耗時本地耗時依賴度耗時比

例標記根118.13269.641.0435ms51ms100.0%11.88%1226.02483.121.94Bms8ms98.51%3.64%2282.74533964.060msOms58.94%0.02%274.41170.571.770ms0ms35.56%0.08%1183.31357.951.713ms2ms90.58%1.0%2182.59356.961.71Oms0ms90.28%0.32%1130.91244851.7119ms7ms64.79%1.98%2219.58412.812883ms3ms64.52%1.37%2219.55412.732.881ms1ms64.51%0.45%2131.28243.791.720ms0ms64.51%0.12%2125.25231.111.70ms0ms62.2%0.12%1124.27230.451.125ms19ms96.07%4.66%強低預2120.47223.521.075ms5ms95.48%9825%90.14%96.08%1.3%1116.05247.931.04ms4ms1.05%1114.76216.991.0843ms37ms8.28%強你檢1113.49214981.05ms5ms1.16%碎信賴111123236.021.033ms3ms91.82%0.68%彈

依1111.2208291.0513ms13ms8946%2.88%1110242131210214ms207ms9332%445%瓶通2116.92220.861.075ms5ms92.59%1.28%1106.5205.27103ms3ms90.16%0.81%1103.07194.451.054ms4ms83.05%0.94%158.47141.231.012ms12ms49.5%1.37%1489104221.4522ms2ms28.54%0.2%248.89104.221.4519ms7ms2853%0.75%典型業務場景-鏈路分析應用名類型狀態大小服務/方法時間軸曰

b

u

y田deliverytee國inventoryplatform國inventoryplatform田inventoryplatform田inventoryplatform

田deliverytradeplatformumpupp田delivery團tradeplatformtradeplatform田itemcenter國itemcenter田itemcenter國itemcenter田

umptradeplatform田tradeplatform田tradeplatformTRACEHSFHSFHSFHSFHSFHSFHSFHSFHSFHSFHSFHSFHSFHSFHSFHSFHSFHSFHSFHSFHSFOKOKTIMEOUTOKOKOKOKOKOKOKOKOKOKOKOKOKOKOKOKOKOKOK7.9KB1.9KB4.7KB4.8KB4.7KB4.8KB8.1KB1.3KB13.2KB6.2KB13.9KB40.8KB2.6KB2.0KB2.0KB2.0KB2.0KB8.7KB10.0KB

814B10.8KB618ms277ms典型業務場景-業務全息排查運維和開發人員通過業務軌跡的方式，在查看某一業務請求服務調用跟蹤的同時，也能看到服務中所產生的業

務事件以及相關業務主鍵。通過全息排查平臺，將鷹眼平臺從對跨系統調用跟蹤升級為跨業務領域追蹤，走出

了從運維平臺向運營平臺轉型的重要一步。/auction/order/unity_order_confirm.htm261條調用記錄，總耗時1s230ms12ms

2ms

10ms

3ms

6ms57ms

4ms

3ms

3ms

3ms5ms

23ms46ms|16ms10ms|14ms12ms53ms12ms9ms打造平臺穩定性能力限流和降級限流的作用相當于電路上的保險絲，當過載的時候掐掉一些流量，讓系統有能力集中資源以較快的速度處理平臺

處理能力范圍內的業務請求。比如在大促場景中，僅讓1000萬用戶中的100萬用戶進入后端的處理流程中，將其余900萬用戶通過隊列排隊或直接阻擋在平臺處理單元之外的方式，保障平臺能在處理能力范圍內對100萬的戶用請求進行處理。前端請求服務2集群

服務3數據庫集群

數據庫集群接入層是最佳限流點最合適的限流攔截點應用集群應用集群服務1集群

集

群數據庫集群Nginx

集群應用集群規則中心應用ADiamond規則推送Sentinel客戶端運行態監控控制邏輯數據接口應用D日志Tair我的應用Db限流平臺Sentinel(哨兵)架構限流平臺Sentinel的出現，為整個服務化體系的穩定運行行使著警戒任務，是對資源調用的控制平臺，主要涵蓋了授權、限

流、降級、調用統計監控四大功能模塊。控制臺規則配置應用B應用C監控系統授權

限流操作權限限流降級流量調度實現原理核心是通過妙級獲取服務器系統運行指標以及業務指標，通過流量調度平臺設置的決策算法以及規則，當發現滿足規則條件的指標

狀

態

發

生

時，

對

線

上

環

境

的

服

務

器

進

行

下

線

托

該

操

作，

以

屏

蔽

這

些

單

點

或

局

部

出

現

故

障

的

應

用

實

例

對

整

體

平臺

產

生

擴

展

式

的

影

響

。應用狀態監控obproxy監控機器指標監控業務狀態監控權重計算決策數據接口互斥因子日志

權限機器tomcaRestfulAPI機器tomcaRestfulAPI降權ConfigServer下線下線Hsf上線流量調度平臺服務狀態視圖

人工決策接口后端應用機器機器機器機器http

requestPC&

無線統一接入systemsystem前端應用機器機器降權VipServer下線hsfhsf規則中心決策算法執行模塊

恢復模塊妙級服務狀態探測收集通知告警報表面向分布式應用架構下應用系統容量壓測和評估的自動化平臺·

實用性：準確容量預測，系統性能回歸測試提供完整的測試場景、測

試方法、同時建立系統的性能基線，供后續的系統改造復用。·

準確性：模擬生產系統實時變化的復雜流量場景，壓測流量模擬具備

了業務的真實性、全面性、業務變化的連續性。·

高效性：所有的建模、壓測、分析、預測基于同一平臺，同一種監控

方式，同一種分析方法，

一切都是自動化，效率比常規方法倍增。傳統的互聯網應用系統的性能測試·

測試場景簡單·線下環境(測試環境)中測試出的結果與線上環境(生產環境)