先舉個例子感受一下千萬級到底是什么數(shù)量級泊藕？

之前很流行的優(yōu)步(Uber)田藐，從媒體公布的信息看，它每天接單量平均在百萬左右吱七， 假如每天有10個小時的服務(wù)時間汽久，平均QPS只有30左右。對于一個后臺服務(wù)器踊餐，單機的平均QPS可以到達800-1000景醇，單獨看寫的業(yè)務(wù)量很簡單 。

為什么我們又不能說輕視它吝岭？

第一三痰，我們看它的數(shù)據(jù)存儲，每天一百萬的話窜管，一年數(shù)據(jù)量的規(guī)模是多少散劫？

第二，剛才說的訂單量幕帆，每一個訂單要推送給附近的司機获搏、司機要并發(fā)搶單，后面業(yè)務(wù)場景的訪問量往往是前者的上百倍失乾，輕松就超過上億級別了常熙。

今天我想從架構(gòu)的本質(zhì)談起之后，希望大家理解在做一些建構(gòu)設(shè)計的時候碱茁，它的出發(fā)點以及它解決的問題是什么裸卫。

什么是架構(gòu)？

有人講纽竣， 說架構(gòu)并不是一 個很 懸 乎的 東西 墓贿， 實際 上就是一個架子 ， 放一些 業(yè)務(wù) 和算法蜓氨，跟我們的生活中的晾衣架很像聋袋。更抽象一點，說架構(gòu)其 實 是 對 我 們 重復性業(yè)務(wù) 的抽象和我 們 未來 業(yè)務(wù) 拓展的前瞻语盈，強調(diào)過去的經(jīng)驗和你對整個行業(yè)的預見舱馅。

我們要想做一個架構(gòu)的話需要哪些能力？

我覺得最重要的是架構(gòu)師一個最重要的能力就是你要有 戰(zhàn) 略分解能力刀荒。

這個怎么來看呢:

第一代嗤，你必須要有抽象的能力，抽象的能力最基本就是去重缠借，去重在整個架構(gòu)中體現(xiàn)在方方面面干毅，從定義一個函數(shù)，到定義一個類泼返，到提供的一個服務(wù)硝逢，以及模板，背后都是要去重提高可復用率。

第二渠鸽，分類能力叫乌。做軟件需要做對象的解耦，要定義對象的屬性和方法徽缚，做分布式系統(tǒng)的時候要做服務(wù)的拆分和模塊化憨奸，要定義服務(wù)的接口和規(guī)范。

第三凿试，?算法（性能）排宰，它的價值體現(xiàn)在提升系統(tǒng)的性能，所有性能的提升那婉，最終都會落到CPU板甘，內(nèi)存，IO和網(wǎng)絡(luò)這4大塊上详炬。

這一頁PPT舉了一些例子來更深入的理解常見技術(shù)背后的架構(gòu)理念盐类。

第一個例子，在分布式系統(tǒng)我們會做 MySQL分 庫 分表痕寓，我們要從不同的庫和表中讀取數(shù)據(jù)傲醉，這樣的抽象最直觀就是使用模板，因為絕大多數(shù)SQL語義是相同的呻率，除了路由到哪個庫哪個表硬毕，如果不使用Proxy中間件，模板就是性價比最高的方法礼仗。

第二看一下加速網(wǎng)絡(luò)的CDN吐咳，它是做速度方面的性能提升，剛才我們也提到從CPU元践、內(nèi)存韭脊、IO、網(wǎng)絡(luò)四個方面來考慮单旁，CDN本質(zhì)上一個是做網(wǎng)絡(luò)智能調(diào)度優(yōu)化沪羔，另一個是多級緩存優(yōu)化。

第三個看一下服務(wù)化象浑，剛才已經(jīng)提到了蔫饰，各個大網(wǎng)站轉(zhuǎn)型過程中一定會做服務(wù)化，其實它就是做抽象和做服務(wù)的拆分愉豺。第四個看一下消息隊列篓吁，本質(zhì)上還是做分類，只不過不是兩個邊際清晰的類蚪拦，而是把兩個邊際不清晰的子系統(tǒng)通過隊列解構(gòu)并且異步化杖剪。

新浪微博整體架構(gòu)是什么樣的

接下我們看一下微博整體架構(gòu)冻押，到一定量級的系統(tǒng)整個架構(gòu)都會變成三層，客戶端包括WEB、安卓和IOS，這里就不說了小染。

接著還都會有一個接口層， 有三個主要作用：

第一個作用狼渊，要做 安全隔離，因為前端節(jié)點都是直接和用戶交互类垦，需要防范各種惡意攻擊；

第二個還充當著一個 流量控制的作用城须，大家知道蚤认，在2014年春節(jié)的時候，微信紅包糕伐，每分鐘8億多次的請求砰琢，其實真正到它后臺的請求量，只有十萬左右的數(shù)量級（這里的數(shù)據(jù)可能不準）良瞧，剩余的流量在接口層就被擋住了陪汽；

第三，我們看對 PC 端和移 動 端的需求不一樣的褥蚯，所以我們可以進行拆分挚冤。接口層之后是后臺，可以看到微博后臺有三大塊：

一個是 平臺服 務(wù)赞庶，

第二训挡， 搜索，

第三歧强， 大數(shù)據(jù)澜薄。

到了后臺的各種服務(wù)其實都是處理的數(shù)據(jù)。 像平臺的業(yè)務(wù)部門摊册，做的就是 數(shù)據(jù)存儲和讀 取肤京，對搜索來說做的是 數(shù)據(jù)的 檢 索，對大數(shù)據(jù)來說是做的數(shù)據(jù)的 挖掘茅特。微博其實和淘寶是很類似

微博其實和淘寶是很類似的忘分。一般來說，第一代架構(gòu)温治，基本上能支撐到用戶到 百萬 級別饭庞，到第二代架構(gòu)基本能支撐到 千萬 級別都沒什么問題，當業(yè)務(wù)規(guī)模到 億級別時熬荆，需要第三代的架構(gòu)舟山。

從 LAMP 的架構(gòu)到面向服 務(wù) 的架構(gòu)，有幾個地方是非常難的，首先不可能在第一代基礎(chǔ)上通過簡單的修修補補滿足用戶量快速增長的累盗，同時線上業(yè)務(wù)又不能停寒矿， 這是我們常說的 在 飛 機上 換 引擎的 問題。前兩天我有一個朋友問我若债，說他在內(nèi)部推行服務(wù)化的時候符相，把一個模塊服務(wù)化做完了，其他部門就是不接蠢琳。我建議在做服務(wù)化的時候啊终，首先更多是偏向業(yè)務(wù)的梳理，同時要找準一個很好的切入點傲须，既有架構(gòu)和服務(wù)化上的提升蓝牲，業(yè)務(wù)方也要有收益，比如提升性能或者降低維護成本同時升級過程要平滑泰讽，建議開始從原子化服務(wù)切入例衍，比如基礎(chǔ)的用戶服務(wù)， 基礎(chǔ)的短消息服務(wù)已卸，基礎(chǔ)的推送服務(wù)佛玄。 第二，就是可 以做無狀 態(tài) 服 務(wù)累澡，后面會詳細講梦抢，還有數(shù)據(jù)量大了后需要做數(shù)據(jù)Sharding，后面會將永乌。 第三代 架構(gòu) 要解決的 問題惑申，就是用戶量和業(yè)務(wù)趨于穩(wěn)步增加（相對爆發(fā)期的指數(shù)級增長），更多考慮技術(shù)框架的穩(wěn)定性翅雏， 提升系統(tǒng)整體的性能圈驼，降低成本，還有對整個系統(tǒng)監(jiān)控的完善和升級望几。

大型網(wǎng)站的系統(tǒng)架構(gòu)是如何演變的

我們通過通過數(shù)據(jù)看一下它的挑戰(zhàn)绩脆，PV是在10億級別，QPS在百萬橄抹，數(shù)據(jù)量在千億級別靴迫。我們可用性，就是SLA要求4個9楼誓，接口響應最多不能超過150毫秒玉锌，線上所有的故障必須得在5分鐘內(nèi)解決完。如果說5分鐘沒處理呢疟羹？那會影響你年終的績效考核主守。2015年微博DAU已經(jīng)過億禀倔。我們系統(tǒng)有上百個微服務(wù)，每周會有兩次的常規(guī)上線和不限次數(shù)的緊急上線参淫。我們的挑戰(zhàn)都一樣救湖，就是數(shù)據(jù)量，bigger and bigger涎才，用戶體驗是faster and faster鞋既，業(yè)務(wù)是more and more∷Ｍ互聯(lián)網(wǎng)業(yè)務(wù)更多是產(chǎn)品體驗驅(qū)動邑闺， 技 術(shù) 在 產(chǎn) 品 體驗上最有效的貢獻 ， 就是你的性能 越來越好 业扒。 每次降低加載一個頁面的時間检吆，都可以間接的降低這個頁面上用戶的流失率。

微博的技術(shù)挑戰(zhàn)和正交分解法解析架構(gòu)

下面看一下 第三代的 架構(gòu) 圖 以及 我 們 怎么用正交分解法 闡 述程储。 我們可以看到我們從兩個維度，橫軸和縱軸可以看到臂寝。 一個 維 度 是 水平的 分層 拆分章鲤，第二從垂直的維度會做拆分。水平的維度從接口層咆贬、到服務(wù)層到數(shù)據(jù)存儲層败徊。垂直怎么拆分，會用業(yè)務(wù)架構(gòu)掏缎、技術(shù)架構(gòu)皱蹦、監(jiān)控平臺、服務(wù)治理等等來處理眷蜈。我相信到第二代的時候很多架構(gòu)已

經(jīng)有了業(yè)務(wù)架構(gòu)和技術(shù)架構(gòu)的拆分沪哺。我們看一下， 接口層有feed酌儒、用戶關(guān)系辜妓、通訊接口；服務(wù)層忌怎，SOA里有基層服務(wù)籍滴、原子服務(wù)和組合服務(wù)，在微博我們只有原子服務(wù)和組合服務(wù)榴啸。原子服務(wù)不依賴于任何其他服務(wù)孽惰，組合服務(wù)由幾個原子服務(wù)和自己的業(yè)務(wù)邏輯構(gòu)建而成 ，資源層負責海量數(shù)據(jù)的存儲（后面例子會詳細講）鸥印。技 術(shù)框架解決 獨立于 業(yè)務(wù) 的海量高并發(fā)場景下的技術(shù)難題勋功，由眾多的技術(shù)組件共同構(gòu)建而成 坦报。在接口層，微博使用JERSY框架酝润，幫助你做參數(shù)的解析燎竖，參數(shù)的驗證，序列化和反序列化要销；資源層构回，主要是緩存、DB相關(guān)的各類組件疏咐，比如Cache組件和對象庫組件纤掸。監(jiān) 控平臺和服 務(wù) 治理 ， 完成系統(tǒng)服務(wù)的像素級監(jiān)控浑塞，對分布式系統(tǒng)做提前診斷借跪、預警以及治理。包含了SLA規(guī)則的制定酌壕、服務(wù)監(jiān)控掏愁、服務(wù)調(diào)用鏈監(jiān)控、流量監(jiān)控卵牍、錯誤異常監(jiān)控果港、線上灰度發(fā)布上線系統(tǒng)、線上擴容縮容調(diào)度系統(tǒng)等糊昙。

下面我們講一下常見的設(shè)計原則辛掠。

第一個，首先是系統(tǒng)架構(gòu)三個利器：

一個释牺， 我 們 RPC 服 務(wù)組 件 （這里不講了）萝衩，

第二個，我們 消息中 間 件 没咙。消息中間件起的作用：可以把兩個模塊之間的交互異步化猩谊，其次可以把不均勻請求流量輸出為勻速的輸出流量，所以說消息中間件 異步化 解耦 和流量削峰的利器镜撩。

第三個是配置管理预柒，它是 代碼級灰度發(fā)布以及 保障系統(tǒng)降級的利器。

第二個 袁梗， 無狀態(tài) 宜鸯， 接口 層 最重要的就是無狀 態(tài)。我們在電商網(wǎng)站購物遮怜，在這個過程中很多情況下是有狀態(tài)的淋袖，比如我瀏覽了哪些商品，為什么大家又常說接口層是無狀態(tài)的锯梁，其實我們把狀態(tài)從接口層剝離到了數(shù)據(jù)層即碗。像用戶在電商網(wǎng)站購物焰情，選了幾件商品，到了哪一步剥懒，接口無狀態(tài)后内舟，狀態(tài)要么放在緩存中，要么放在數(shù)據(jù)庫中初橘， 其 實 它并不是沒有狀 態(tài) 验游， 只是在 這 個 過 程中我 們 要把一些有狀 態(tài) 的 東 西抽離出來 到了數(shù)據(jù)層。

第三個保檐， 數(shù)據(jù) 層 比服 務(wù)層 更需要 設(shè)計耕蝉，這是一條非常重要的經(jīng)驗。對于服務(wù)層來說夜只，可以拿PHP寫垒在，明天你可以拿JAVA來寫，但是如果你的數(shù)據(jù)結(jié)構(gòu)開始設(shè)計不合理扔亥，將來數(shù)據(jù)結(jié)構(gòu)的改變會花費你數(shù)倍的代價场躯，老的數(shù)據(jù)格式向新的數(shù)據(jù)格式遷移會讓你痛不欲生，既有工作量上的旅挤，又有數(shù)據(jù)遷移跨越的時間周期推盛，有一些甚至需要半年以上。

第四谦铃，物理結(jié)構(gòu)與邏輯結(jié)構(gòu)的映射，上一張圖看到兩個維度切成十二個區(qū)間榔昔，每個區(qū)間代表一個技術(shù)領(lǐng)域驹闰，這個可以看做我們的邏輯結(jié)構(gòu)。另外撒会，不論后臺還是應用層的開發(fā)團隊嘹朗，一般都會分幾個垂直的業(yè)務(wù)組加上一個基礎(chǔ)技術(shù)架構(gòu)組，這就是從物理組織架構(gòu)到邏輯的技術(shù)架構(gòu)的完美的映射诵肛，精細化團隊分工屹培，有利于提高溝通協(xié)作的效率 。

第五怔檩， www .sanhao.com 的訪問過程褪秀，我們這個架構(gòu)圖里沒有涉及到的，舉個例子薛训，比如當你在瀏覽器輸入www.sanhao網(wǎng)址的時候媒吗，這個請求在接口層之前發(fā)生了什么？首先會查看你本機DNS以及DNS服務(wù)乙埃，查找域名對應的IP地址闸英，然后發(fā)送HTTP請求過去锯岖。這個請求首先會到前端的VIP地址（公網(wǎng)服務(wù)IP地址），VIP之后還要經(jīng)過負載均衡器（Nginx服務(wù)器）甫何，之后才到你的應用接口層出吹。在接口層之前發(fā)生了這么多事，可能有用戶報一個問題的時候辙喂，你通過在接口層查日志根本發(fā)現(xiàn)不了問題捶牢，原因就是問題可能發(fā)生在到達接口層之前了。

第六加派，我們說分布式系統(tǒng)叫确，它最終的瓶頸會落在哪里呢芍锦？前端時間有一個網(wǎng)友跟我討論的時候娄琉，說他們的系統(tǒng)遇到了一個瓶頸， 查遍了CPU票腰，內(nèi)存杏慰，網(wǎng)絡(luò)炼鞠，存儲谒主，都沒有問題霎肯。我說你再查一遍，因為最終你不論用上千臺服務(wù)器還是上萬臺服務(wù)器搂捧，最終系統(tǒng)出瓶頸的一定會落在某一臺機（可能是葉子節(jié)點也可能是核心的節(jié)點）异旧，一定落在CPU提佣、內(nèi)存、存儲和網(wǎng)絡(luò)上术荤，最后查出來問題出在一臺服務(wù)器的網(wǎng)卡帶寬上每篷。詳細的內(nèi)容可以加Java架構(gòu)交流群：760940986了解

微博多級雙機房緩存架構(gòu)

接下來我們看一下微博的Feed多級緩存焦读。我們做業(yè)務(wù)的時候矗晃，經(jīng)常很少做業(yè)務(wù)分析，技術(shù)大會上的分享又都偏向技術(shù)架構(gòu)仓技。其實大家更多的日常工作是需要花費更多時間在業(yè)務(wù)優(yōu)化上脖捻。這張圖是統(tǒng)計微博的信息流前幾頁的訪問比例地沮，像前三頁占了97%羡亩，在做緩存設(shè)計的時候夕春，我們最多只存最近的M條數(shù)據(jù)及志。 這里強調(diào)的就是做系統(tǒng)設(shè)計 要基于用 戶 的 場 景 寨腔， 越細致越好 迫卢。舉了一個例子乾蛤，大家都會用電商，電商在雙十一會做全國范圍內(nèi)的活動眨层，他們做設(shè)計的時候也會考慮場景的趴樱，一個就是購物車叁征，我曾經(jīng)跟相關(guān)開發(fā)討論過捺疼，購物車是在雙十一之前用戶的訪問量非常大，就是不停地往里加商品议薪。在真正到雙十一那天他不會往購物車加東西了斯议，但是他會頻繁的瀏覽購物車哼御。針對這個場景恋昼，活動之前重點設(shè)計優(yōu)化購物車的寫場景液肌， 活動開始后優(yōu)化購物車的讀場景嗦哆。

你看到的微博是由哪些部分聚合而成的呢老速？最右邊的是Feed橘券，就是微博所有關(guān)注的人旁舰，他們的微博所組成的鬓梅。微博我們會按照時間順序把所有關(guān)注人的順序做一個排序绽快。隨著業(yè)務(wù)的發(fā)展坊罢，除了跟時間序相關(guān)的微博還有非時間序的微博活孩，就是會有廣告的要求憾儒，增加一些廣告起趾，還有粉絲頭條，就是拿錢買的眶根，熱門微博属百，都會插在其中族扰。分發(fā)控制定欧，就是說和一些推薦相關(guān)的忧额，我推薦一些相關(guān)的好友的微博，我推薦一些你可能沒有讀過的微博托嚣，我推薦一些其他類型的微博示启。 當然對非時序的微博和分發(fā)控制微博夫嗓，實際會起多個并行的程序來讀取矩父，最后同步做統(tǒng)一的聚合窍株。這里稍微分享一下球订， 從SNS社交領(lǐng)域來看瑰钮，國內(nèi)現(xiàn)在做的比較好的三個信息流：

微博 是 基于弱關(guān)系的媒體信息流 飞涂；

朋友圈是基于 強 關(guān)系的信息流 旦部；

另外一個做的比 較 好的就是今日 頭 條 ， 它并不是基于關(guān)系來構(gòu)建信息流 婚度， 而是基于 興趣和相關(guān)性的個性化推薦 信息流 。

信息流的聚合哮翘，體現(xiàn)在很多很多的產(chǎn)品之中阻课，除了SNS限煞，電商里也有信息流的聚合的影子署驻。比如搜索一個商品后出來的列表頁，它的信息流基本由幾部分組成：第一，打廣告的凌节；第二個，做一些推薦卒煞，熱門的商品乖订，其次乍构，才是關(guān)鍵字相關(guān)的搜索結(jié)果岂丘。 信息流 開始的時候 很 簡單 ， 但是到后期會 發(fā)現(xiàn) 寨蹋， 你的 這 個流 如何做控制分發(fā) ， 非常復雜， 微博在最近一兩年一直在做 這樣 的工作吐句。

剛才我們是從業(yè)務(wù)上分析屯断，那么技術(shù)上怎么解決高并發(fā)氧秘，高性能的問題？微博訪問量很大的時候灭忠，底層存儲是用MySQL數(shù)據(jù)庫坎吻，當然也會有其他的刊头。對于查詢請求量大的時候，大家知道一定有緩存穿肄，可以復用可重用的計算結(jié)果〗├剩可以看到社牲，發(fā)一條微博违寿，我有很多粉絲，他們都會來看我發(fā)的內(nèi)容，所以 微博是最適合使用 緩 存 的系統(tǒng)，微博的讀寫比例基本在幾十比一。微博使用了 雙 層緩 存，上面是L1，每個L1上都是一組（包含4-6臺機器）窍帝，左邊的框相當于一個機房，右邊又是一個機房。在這個系統(tǒng)中L1緩存所起的作用是什么？ 首先诫舅，L1 緩 存增加整個系 統(tǒng) 的 QPS这弧， 其次 以低成本靈活擴容的方式 增加 系統(tǒng) 的 帶寬 卷哩。想象一個極端場景，只有一篇博文，但是它的訪問量無限增長，其實我們不需要影響L2緩存，因為它的內(nèi)容存儲的量小，但它就是訪問量大鹅龄。這種場景下拴鸵，你就需要使用L1來擴容提升QPS和帶寬瓶頸聘芜。另外一個場景，就是L2級緩存發(fā)生作用，比如我有一千萬個用戶，去訪問的是一百萬個用戶的微博 ，這個時候，他不只是說你的吞吐量和訪問帶寬旨椒，就是你要緩存的博文的內(nèi)容也很多了，這個時候你要考慮緩存的容量愉镰， 第二 級緩 存更多的是從容量上來 規(guī)劃碗降，保證請求以較小的比例 穿透到 后端的 數(shù)據(jù) 庫 中 ，根據(jù)你的用戶模型你可以估出來，到底有百分之多少的請求不能穿透到DB， 評估這個容量之后船庇，才能更好的評估DB需要多少庫臣淤，需要承擔多大的訪問的壓力。另外窃爷，我們看雙機房的話邑蒋，左邊一個，右邊一個按厘。 兩個機房是互 為 主 備 医吊， 或者互 為熱備 。如果兩個用戶在不

同地域逮京，他們訪問兩個不同機房的時候卿堂，假設(shè)用戶從IDC1過來，因為就近原理懒棉，他會訪問L1草描，沒有的話才會跑到Master览绿，當在IDC1沒找到的時候才會跑到IDC2來找。同時有用戶從IDC2訪問陶珠，也會有請求從L1和Master返回或者到IDC1去查找挟裂。 IDC1 和 IDC2 ，兩個機房都有全量的用戶數(shù)據(jù)揍诽，同時在線提供服務(wù)诀蓉，但是緩存查詢又遵循最近訪問原理。

還有哪些多級緩存的例子呢暑脆？CDN是典型的多級緩存渠啤。CDN在國內(nèi)各個地區(qū)做了很多節(jié)點，比如在杭州市部署一個節(jié)點時添吗，在機房里肯定不止一臺機器沥曹，那么對于一個地區(qū)來說，只有幾臺服務(wù)器到源站回源碟联，其他節(jié)點都到這幾臺服務(wù)器回源即可妓美，這么看CDN至少也有兩級。Local Cache+ 分布式 緩 存鲤孵，這也是常見的一種策略壶栋。有一種場景，分布式緩存并不適用普监， 比如 單 點 資 源 的爆發(fā)性峰值流量贵试，這個時候使用Local Cache + 分布式緩存，Local Cache 在 應用 服 務(wù) 器 上用很小的 內(nèi)存資源 擋住少量的 極端峰值流量凯正，長尾的流量仍然訪問分布式緩存毙玻，這樣的Hybrid緩存架構(gòu)通過復用眾多的應用服務(wù)器節(jié)點，降低了系統(tǒng)的整體成本廊散。

我們來看一下 Feed 的存 儲 架構(gòu)桑滩，微博的博文主要存在MySQL中。首先來看內(nèi)容表允睹，這個比較簡單施符，每條內(nèi)容一個索引，每天建一張表擂找，其次看索引表戳吝，一共建了兩級索引。首先想象一下用戶場景贯涎，大部分用戶刷微博的時候听哭，看的是他關(guān)注所有人的微博，然后按時間來排序。仔細分析發(fā)現(xiàn)在這個場景下陆盘， 跟一個用戶的自己的相關(guān)性很小了普筹。所以在一級索引的時候會先根據(jù)關(guān)注的用戶，取他們的前條微博ID隘马，然后聚合排序太防。我們在做哈希（分庫分表）的時候，同時考慮了按照UID哈希和按照時間維度酸员。很業(yè)務(wù)和時間相關(guān)性很高的蜒车，今天的熱點新聞，明天就沒熱度了幔嗦，數(shù)據(jù)的冷熱非常明顯酿愧，這種場景就需要按照時間維度做分表，首先冷熱數(shù)據(jù)做了分離（可以對冷熱數(shù)據(jù)采用不同的存儲方案來降低成本）邀泉，其次嬉挡， 很容止控制我數(shù)據(jù)庫表的爆炸。像微博如果只按照用戶維度區(qū)分汇恤，那么這個用戶所有數(shù)據(jù)都在一張表里庞钢，這張表就是無限增長的，時間長了查詢會越來越慢因谎。二級索引基括，是我們里面一個比較特殊的場景，就是我要快速找到這個人所要發(fā)布的某一時段的微博時蓝角，通過二級索引快速定位。

分布式服務(wù)追蹤系統(tǒng)

分布式追蹤服務(wù)系統(tǒng)饭冬，當系統(tǒng)到千萬級以后的時候使鹅，越來越龐雜逻住，所解決的問題更偏向穩(wěn)定性假哎，性能和監(jiān)控惋鹅。剛才說用戶只要有一個請求過來趁舀，你可以依賴你的服務(wù)RPC1蝴罪、RPC2医咨，你會發(fā)現(xiàn)RPC2又依賴RPC3柔昼、RPC4垂券。分布式服務(wù)的時候一個痛點侨艾，就是說一個請求從用戶過來之后执虹，在后臺不同的機器之間不停的調(diào)用并返回。

當你發(fā)現(xiàn)一個問題的時候唠梨，這些日志落在不同的機器上袋励，你也不知道問題到底出在哪兒，各個服務(wù)之間互相隔離，互相之間沒有建立關(guān)聯(lián)茬故。所以導致排查問題基本沒有任何手段盖灸，就是出了問題沒法兒解決。

我們要解決的問題磺芭，我們剛才說日志互相隔離赁炎，我們就要把它建立聯(lián)系。建立聯(lián)系我們就有一個請求ID钾腺，然后結(jié)合RPC框架徙垫， 服務(wù)治理功能。假設(shè)請求從客戶端過來垮庐，其中包含一個ID 101松邪，到服務(wù)A時仍然帶有ID 101，然后調(diào)用RPC1的時候也會標識這是101 哨查，所以需要 一個唯一的 請求 ID 標識 遞歸迭代的傳遞到每一個 相關(guān) 節(jié)點逗抑。第二個，你做的時候寒亥，你不能說每個地方都加邮府，對業(yè)務(wù)系統(tǒng)來說需要一個框架來完成這個工作， 這 個框架要 對業(yè)務(wù) 系 統(tǒng) 是最低侵入原 則 溉奕， 用 JAVA 的 話 就可以用 AOP褂傀，要做到零侵入的原則，就是對所有相關(guān)的中間件打點加勤，從接口層組件（HTTP Client仙辟、HTTP Server）至到服務(wù)層組件（RPC Client、RPC Server）鳄梅，還有數(shù)據(jù)訪問中間件的叠国，這樣業(yè)務(wù)系統(tǒng)只需要少量的配置信息就可以實現(xiàn)全鏈路監(jiān)控 。為什么要用日志戴尸？服務(wù)化以后粟焊，每個服務(wù)可以用不同的開發(fā)語言， 考慮多種開發(fā)語言的兼容性 孙蒙， 內(nèi)部定 義標 準化的日志 是唯一且有效的辦法项棠。

最后，如何構(gòu)建基于GPS導航的路況監(jiān)控挎峦？我們剛才講分布式服務(wù)追蹤香追。分布式服務(wù)追蹤能解決的問題， 如果 單一用 戶發(fā)現(xiàn)問題 后 坦胶， 可以通 過請 求 ID 快速找到 發(fā) 生 問

題 的 節(jié) 點在什么翅阵，但是并沒有解決如何發(fā)現(xiàn)問題歪玲。我們看現(xiàn)實中比較容易理解的道路監(jiān)控，每輛車有GPS定位掷匠，我想看北京哪兒擁堵的時候滥崩，怎么做？ 第一個 讹语， 你肯定要知

道每個 車 在什么位置钙皮，它走到哪兒了。其實可以說每個車上只要有一個標識顽决，加上每一次流動的信息短条，就可以看到每個車流的位置和方向。 其次如何做 監(jiān) 控和 報 警才菠，我們怎么能了解道路的流量狀況和負載茸时，并及時報警。我們要定義這條街道多寬多高赋访，單位時間可以通行多少輛車可都，這就是道路的容量。有了道路容量蚓耽，再有道路的實時流量渠牲，我們就可以基于實習路況做預警？

對應于 分布式系 統(tǒng) 的話如何構(gòu)建步悠？ 第一 签杈， 你要 定義 每個服 務(wù)節(jié) 點它的 SLA A 是多少 ？SLA可以從系統(tǒng)的CPU占用率鼎兽、內(nèi)存占用率答姥、磁盤占用率、QPS請求數(shù)等來定義谚咬，相當于定義系統(tǒng)的容量鹦付。 第二個 ， 統(tǒng)計 線 上 動態(tài) 的流量序宦，你要知道服務(wù)的平均QPS睁壁、最低QPS和最大QPS背苦，有了流量和容量互捌，就可以對系統(tǒng)做全面的監(jiān)控和報警。

剛才講的是理論行剂，實際情況肯定比這個復雜秕噪。微博在春節(jié)的時候做許多活動，必須保障系統(tǒng)穩(wěn)定厚宰，理論上你只要定義容量和流量就可以腌巾。但實際遠遠不行遂填，為什么？有技術(shù)的因素澈蝙，有人為的因素吓坚，因為不同的開發(fā)定義的流量和容量指標有主觀性，很難全局量化標準灯荧，所以真正流量來了以后礁击，你預先評估的系統(tǒng)瓶頸往往不正確。實際中我們在春節(jié)前主要采取了三個措施：第一逗载，最簡單的就是有降 級 的 預 案哆窿，流量超過系統(tǒng)容量后，先把哪些功能砍掉厉斟，需要有明確的優(yōu)先級 挚躯。第二個， 線上全鏈路壓測擦秽，就是把現(xiàn)在的流量放大到我們平常流量的五倍甚至十倍（比如下線一半的服務(wù)器码荔，縮容而不是擴容），看看系統(tǒng)瓶頸最先發(fā)生在哪里号涯。我們之前有一些例子目胡，推測系統(tǒng)數(shù)據(jù)庫會先出現(xiàn)瓶頸，但是實測發(fā)現(xiàn)是前端的程序先遇到瓶頸链快。第三誉己，搭建在線 Docker 集群 ， 所有業(yè)務(wù)共享備用的 Docker集群資源域蜗，這樣可以極大的避免每個業(yè)務(wù)都預留資源巨双，但是實際上流量沒有增長造成的浪費。

總結(jié)

接下來說的是如何不停的學習和提升霉祸，這里以Java語言為例筑累，首先， 一定要 理解 JAVA丝蹭；第二步慢宗，JAVA完了以后，一定要 理 解 JVM奔穿；其次镜沽，還要 理解 操作系統(tǒng)；再次還是要了解一下 Design Pattern贱田，這將告訴你怎么把過去的經(jīng)驗抽象沉淀供將來借鑒缅茉；還要學習 TCP/IP、 分布式系 統(tǒng)男摧、數(shù)據(jù)結(jié)構(gòu)和算法蔬墩。

最后就是我想說的就是今天我所說的可能一切都是錯的译打！大家通過不停的學習、練習和總結(jié)拇颅， 形成自己的一套架構(gòu)設(shè)計原則和方法奏司，謝謝大家。