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

之前很流行的優(yōu)步(Uber)，從媒體公布的信息看鸽素，它每天接單量平均在百萬左右褒繁， 假如每天有10個小時的服務時間，平均QPS只有30左右馍忽。對于一個后臺服務器棒坏，單機的平均QPS可以到達800-1000燕差，單獨看寫的業(yè)務量很簡單 。

為什么我們又不能說輕視它坝冕？

第一徒探，我們看它的數(shù)據存儲，每天一百萬的話喂窟，一年數(shù)據量的規(guī)模是多少测暗？

第二，剛才說的訂單量磨澡，每一個訂單要推送給附近的司機碗啄、司機要并發(fā)搶單，后面業(yè)務場景的訪問量往往是前者的上百倍稳摄，輕松就超過上億級別了挫掏。

今天我想從架構的本質談起之后，希望大家理解在做一些建構設計的時候秩命，它的出發(fā)點以及它解決的問題是什么尉共。

什么是架構？

有人講弃锐， 說架構并不是一 個很 懸 乎的 東西 袄友， 實際 上就是一個架子 ， 放一些 業(yè)務 和算法霹菊，跟我們的生活中的晾衣架很像剧蚣。更抽象一點，說架構其 實 是 對 我 們 重復性業(yè)務 的抽象和我 們 未來 業(yè)務 拓展的前瞻旋廷，強調過去的經驗和你對整個行業(yè)的預見鸠按。

我們要想做一個架構的話需要哪些能力？

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

這個怎么來看呢:

第一目尖，你必須要有抽象的能力，抽象的能力最基本就是去重扎运，去重在整個架構中體現(xiàn)在方方面面瑟曲，從定義一個函數(shù)，到定義一個類豪治，到提供的一個服務洞拨，以及模板，背后都是要去重提高可復用率负拟。

第二烦衣，?分類能力。做軟件需要做對象的解耦，要定義對象的屬性和方法花吟，做分布式系統(tǒng)的時候要做服務的拆分和模塊化启泣，要定義服務的接口和規(guī)范。

第三示辈，?算法（性能）寥茫，它的價值體現(xiàn)在提升系統(tǒng)的性能，所有性能的提升矾麻，最終都會落到CPU纱耻，內存，IO和網絡這4大塊上险耀。

這一頁PPT舉了一些例子來更深入的理解常見技術背后的架構理念弄喘。

第一個例子，在分布式系統(tǒng)我們會做 MySQL分 庫 分表甩牺，我們要從不同的庫和表中讀取數(shù)據蘑志，這樣的抽象最直觀就是使用模板，因為絕大多數(shù)SQL語義是相同的贬派，除了路由到哪個庫哪個表急但，如果不使用Proxy中間件，模板就是性價比最高的方法搞乏。

第二看一下加速網絡的CDN波桩，它是做速度方面的性能提升，剛才我們也提到從CPU请敦、內存镐躲、IO、網絡四個方面來考慮侍筛，CDN本質上一個是做網絡智能調度優(yōu)化萤皂，另一個是多級緩存優(yōu)化。

第三個看一下服務化匣椰，剛才已經提到了裆熙，各個大網站轉型過程中一定會做服務化，其實它就是做抽象和做服務的拆分窝爪。第四個看一下消息隊列弛车，本質上還是做分類，只不過不是兩個邊際清晰的類蒲每，而是把兩個邊際不清晰的子系統(tǒng)通過隊列解構并且異步化。

新浪微博整體架構是什么樣的

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

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

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

第二個還充當著一個 流量控制的作用小泉，大家知道芦疏，在2014年春節(jié)的時候，微信紅包微姊，每分鐘8億多次的請求酸茴，其實真正到它后臺的請求量，只有十萬左右的數(shù)量級（這里的數(shù)據可能不準）兢交，剩余的流量在接口層就被擋住了薪捍；

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

一個是 平臺服 務晴裹，

第二昆稿， 搜索，

第三， 大數(shù)據。

到了后臺的各種服務其實都是處理的數(shù)據跷坝。 像平臺的業(yè)務部門柜候，做的就是 數(shù)據存儲和讀 取，對搜索來說做的是 數(shù)據的 檢 索轧抗，對大數(shù)據來說是做的數(shù)據的 挖掘。微博其實和淘寶是很類似

微博其實和淘寶是很類似的。一般來說畏陕，第一代架構，基本上能支撐到用戶到 百萬 級別仿滔，到第二代架構基本能支撐到 千萬 級別都沒什么問題惠毁，當業(yè)務規(guī)模到 億級別時，需要第三代的架構崎页。

從 LAMP 的架構到面向服 務 的架構鞠绰，有幾個地方是非常難的，首先不可能在第一代基礎上通過簡單的修修補補滿足用戶量快速增長的飒焦，同時線上業(yè)務又不能停蜈膨， 這是我們常說的 在 飛 機上 換 引擎的 問題。前兩天我有一個朋友問我，說他在內部推行服務化的時候翁巍，把一個模塊服務化做完了驴一，其他部門就是不接。我建議在做服務化的時候灶壶，首先更多是偏向業(yè)務的梳理肝断，同時要找準一個很好的切入點，既有架構和服務化上的提升驰凛，業(yè)務方也要有收益胸懈，比如提升性能或者降低維護成本同時升級過程要平滑，建議開始從原子化服務切入洒嗤，比如基礎的用戶服務箫荡， 基礎的短消息服務，基礎的推送服務渔隶。 第二羔挡，就是可 以做無狀 態(tài) 服 務，后面會詳細講间唉，還有數(shù)據量大了后需要做數(shù)據Sharding绞灼，后面會將。 第三代 架構 要解決的 問題呈野，就是用戶量和業(yè)務趨于穩(wěn)步增加（相對爆發(fā)期的指數(shù)級增長）低矮，更多考慮技術框架的穩(wěn)定性， 提升系統(tǒng)整體的性能被冒，降低成本军掂，還有對整個系統(tǒng)監(jiān)控的完善和升級。

大型網站的系統(tǒng)架構是如何演變的

我們通過通過數(shù)據看一下它的挑戰(zhàn)昨悼，PV是在10億級別蝗锥，QPS在百萬，數(shù)據量在千億級別率触。我們可用性终议，就是SLA要求4個9，接口響應最多不能超過150毫秒葱蝗，線上所有的故障必須得在5分鐘內解決完穴张。如果說5分鐘沒處理呢？那會影響你年終的績效考核两曼。2015年微博DAU已經過億皂甘。我們系統(tǒng)有上百個微服務，每周會有兩次的常規(guī)上線和不限次數(shù)的緊急上線合愈。我們的挑戰(zhàn)都一樣叮贩，就是數(shù)據量击狮，bigger and bigger佛析，用戶體驗是faster and faster益老，業(yè)務是more and more〈缒互聯(lián)網業(yè)務更多是產品體驗驅動捺萌， 技 術 在 產 品 體驗上最有效的貢獻 ， 就是你的性能 越來越好 膘茎。 每次降低加載一個頁面的時間桃纯，都可以間接的降低這個頁面上用戶的流失率。

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

下面看一下 第三代的 架構 圖 以及 我 們 怎么用正交分解法 闡 述披坏。 我們可以看到我們從兩個維度态坦，橫軸和縱軸可以看到。 一個 維 度 是 水平的 分層 拆分棒拂，第二從垂直的維度會做拆分伞梯。水平的維度從接口層、到服務層到數(shù)據存儲層帚屉。垂直怎么拆分谜诫，會用業(yè)務架構、技術架構攻旦、監(jiān)控平臺且预、服務治理等等來處理怀估。我相信到第二代的時候很多架構已

經有了業(yè)務架構和技術架構的拆分灾部。我們看一下从藤， 接口層有feed悯搔、用戶關系、通訊接口；服務層增炭，SOA里有基層服務、原子服務和組合服務欲鹏，在微博我們只有原子服務和組合服務。原子服務不依賴于任何其他服務，組合服務由幾個原子服務和自己的業(yè)務邏輯構建而成 ，資源層負責海量數(shù)據的存儲（后面例子會詳細講）茵宪。技 術框架解決 獨立于 業(yè)務 的海量高并發(fā)場景下的技術難題憾股，由眾多的技術組件共同構建而成 。在接口層，微博使用JERSY框架雕沉，幫助你做參數(shù)的解析倔叼，參數(shù)的驗證巡验，序列化和反序列化敷硅；資源層，主要是緩存猿挚、DB相關的各類組件办绝，比如Cache組件和對象庫組件超埋。監(jiān) 控平臺和服 務 治理 ， 完成系統(tǒng)服務的像素級監(jiān)控絮蒿，對分布式系統(tǒng)做提前診斷冀泻、預警以及治理舞肆。包含了SLA規(guī)則的制定、服務監(jiān)控、服務調用鏈監(jiān)控趣竣、流量監(jiān)控、錯誤異常監(jiān)控、線上灰度發(fā)布上線系統(tǒng)府蔗、線上擴容縮容調度系統(tǒng)等狂男。

下面我們講一下常見的設計原則忠寻。

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

一個品山， 我 們 RPC 服 務組 件 （這里不講了）胆建，

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

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

第二個 ， 無狀態(tài) 涝登， 接口 層 最重要的就是無狀 態(tài)雄家。我們在電商網站購物，在這個過程中很多情況下是有狀態(tài)的胀滚，比如我瀏覽了哪些商品趟济，為什么大家又常說接口層是無狀態(tài)的，其實我們把狀態(tài)從接口層剝離到了數(shù)據層咽笼。像用戶在電商網站購物顷编，選了幾件商品，到了哪一步剑刑，接口無狀態(tài)后媳纬，狀態(tài)要么放在緩存中，要么放在數(shù)據庫中施掏， 其 實 它并不是沒有狀 態(tài) 钮惠， 只是在 這 個 過 程中我 們 要把一些有狀 態(tài) 的 東 西抽離出來 到了數(shù)據層。

第三個其监， 數(shù)據 層 比服 務層 更需要 設計萌腿，這是一條非常重要的經驗。對于服務層來說抖苦，可以拿PHP寫，明天你可以拿JAVA來寫米死，但是如果你的數(shù)據結構開始設計不合理锌历，將來數(shù)據結構的改變會花費你數(shù)倍的代價，老的數(shù)據格式向新的數(shù)據格式遷移會讓你痛不欲生峦筒，既有工作量上的究西，又有數(shù)據遷移跨越的時間周期，有一些甚至需要半年以上物喷。

第四卤材，物理結構與邏輯結構的映射，上一張圖看到兩個維度切成十二個區(qū)間峦失，每個區(qū)間代表一個技術領域扇丛，這個可以看做我們的邏輯結構。另外尉辑，不論后臺還是應用層的開發(fā)團隊帆精，一般都會分幾個垂直的業(yè)務組加上一個基礎技術架構組，這就是從物理組織架構到邏輯的技術架構的完美的映射，精細化團隊分工卓练，有利于提高溝通協(xié)作的效率 隘蝎。

第五， www .sanhao.com 的訪問過程襟企，我們這個架構圖里沒有涉及到的嘱么，舉個例子，比如當你在瀏覽器輸入www.sanhao網址的時候顽悼，這個請求在接口層之前發(fā)生了什么曼振？首先會查看你本機DNS以及DNS服務，查找域名對應的IP地址表蝙，然后發(fā)送HTTP請求過去拴测。這個請求首先會到前端的VIP地址（公網服務IP地址），VIP之后還要經過負載均衡器（Nginx服務器）府蛇，之后才到你的應用接口層集索。在接口層之前發(fā)生了這么多事，可能有用戶報一個問題的時候汇跨，你通過在接口層查日志根本發(fā)現(xiàn)不了問題务荆，原因就是問題可能發(fā)生在到達接口層之前了。

第六穷遂，我們說分布式系統(tǒng)函匕，它最終的瓶頸會落在哪里呢？前端時間有一個網友跟我討論的時候蚪黑，說他們的系統(tǒng)遇到了一個瓶頸盅惜， 查遍了CPU，內存忌穿，網絡抒寂，存儲，都沒有問題掠剑。我說你再查一遍屈芜，因為最終你不論用上千臺服務器還是上萬臺服務器，最終系統(tǒng)出瓶頸的一定會落在某一臺機（可能是葉子節(jié)點也可能是核心的節(jié)點）朴译，一定落在CPU井佑、內存、存儲和網絡上眠寿，最后查出來問題出在一臺服務器的網卡帶寬上躬翁。

詳細的內容可以加Java架構師群：671017482了解

微博多級雙機房緩存架構

接下來我們看一下微博的Feed多級緩存。我們做業(yè)務的時候澜公，經常很少做業(yè)務分析姆另，技術大會上的分享又都偏向技術架構喇肋。其實大家更多的日常工作是需要花費更多時間在業(yè)務優(yōu)化上。這張圖是統(tǒng)計微博的信息流前幾頁的訪問比例迹辐，像前三頁占了97%蝶防，在做緩存設計的時候，我們最多只存最近的M條數(shù)據明吩。 這里強調的就是做系統(tǒng)設計 要基于用 戶 的 場 景 间学， 越細致越好 。舉了一個例子印荔，大家都會用電商低葫，電商在雙十一會做全國范圍內的活動，他們做設計的時候也會考慮場景的仍律，一個就是購物車嘿悬，我曾經跟相關開發(fā)討論過，購物車是在雙十一之前用戶的訪問量非常大水泉，就是不停地往里加商品善涨。在真正到雙十一那天他不會往購物車加東西了，但是他會頻繁的瀏覽購物車草则。針對這個場景钢拧，活動之前重點設計優(yōu)化購物車的寫場景， 活動開始后優(yōu)化購物車的讀場景炕横。

你看到的微博是由哪些部分聚合而成的呢源内？最右邊的是Feed，就是微博所有關注的人份殿，他們的微博所組成的膜钓。微博我們會按照時間順序把所有關注人的順序做一個排序。隨著業(yè)務的發(fā)展卿嘲，除了跟時間序相關的微博還有非時間序的微博呻此，就是會有廣告的要求，增加一些廣告腔寡，還有粉絲頭條，就是拿錢買的音瓷，熱門微博钮莲，都會插在其中快耿。分發(fā)控制，就是說和一些推薦相關的凭语，我推薦一些相關的好友的微博，我推薦一些你可能沒有讀過的微博撩扒，我推薦一些其他類型的微博似扔。 當然對非時序的微博和分發(fā)控制微博吨些，實際會起多個并行的程序來讀取，最后同步做統(tǒng)一的聚合炒辉。這里稍微分享一下豪墅， 從SNS社交領域來看，國內現(xiàn)在做的比較好的三個信息流：

微博 是 基于弱關系的媒體信息流 黔寇；

朋友圈是基于 強 關系的信息流 偶器；

另外一個做的比 較 好的就是今日 頭 條 ， 它并不是基于關系來構建信息流 缝裤， 而是基于 興趣和相關性的個性化推薦 信息流 屏轰。

信息流的聚合，體現(xiàn)在很多很多的產品之中憋飞，除了SNS霎苗，電商里也有信息流的聚合的影子。比如搜索一個商品后出來的列表頁榛做，它的信息流基本由幾部分組成：第一唁盏，打廣告的；第二個瘤睹，做一些推薦升敲，熱門的商品，其次轰传，才是關鍵字相關的搜索結果驴党。 信息流 開始的時候 很 簡單 ， 但是到后期會 發(fā)現(xiàn) 获茬， 你的 這 個流 如何做控制分發(fā) 港庄， 非常復雜， 微博在最近一兩年一直在做 這樣 的工作恕曲。

剛才我們是從業(yè)務上分析鹏氧，那么技術上怎么解決高并發(fā)，高性能的問題佩谣？微博訪問量很大的時候把还，底層存儲是用MySQL數(shù)據庫，當然也會有其他的茸俭。對于查詢請求量大的時候吊履，大家知道一定有緩存，可以復用可重用的計算結果调鬓⊥а祝可以看到，發(fā)一條微博腾窝，我有很多粉絲缀踪，他們都會來看我發(fā)的內容居砖，所以 微博是最適合使用 緩 存 的系統(tǒng)，微博的讀寫比例基本在幾十比一驴娃。微博使用了 雙 層緩 存奏候，上面是L1，每個L1上都是一組（包含4-6臺機器）托慨，左邊的框相當于一個機房鼻由，右邊又是一個機房。在這個系統(tǒng)中L1緩存所起的作用是什么厚棵？ 首先蕉世，L1 緩 存增加整個系 統(tǒng) 的 QPS， 其次 以低成本靈活擴容的方式 增加 系統(tǒng) 的 帶寬 婆硬。想象一個極端場景狠轻，只有一篇博文，但是它的訪問量無限增長彬犯，其實我們不需要影響L2緩存向楼，因為它的內容存儲的量小，但它就是訪問量大谐区。這種場景下湖蜕，你就需要使用L1來擴容提升QPS和帶寬瓶頸。另外一個場景宋列，就是L2級緩存發(fā)生作用昭抒，比如我有一千萬個用戶，去訪問的是一百萬個用戶的微博 炼杖，這個時候灭返，他不只是說你的吞吐量和訪問帶寬，就是你要緩存的博文的內容也很多了坤邪，這個時候你要考慮緩存的容量熙含， 第二 級緩 存更多的是從容量上來 規(guī)劃，保證請求以較小的比例 穿透到 后端的 數(shù)據 庫 中 艇纺，根據你的用戶模型你可以估出來怎静，到底有百分之多少的請求不能穿透到DB， 評估這個容量之后黔衡，才能更好的評估DB需要多少庫消约，需要承擔多大的訪問的壓力。另外员帮，我們看雙機房的話，左邊一個导饲，右邊一個捞高。 兩個機房是互 為 主 備 氯材， 或者互 為熱備 。如果兩個用戶在不

同地域硝岗，他們訪問兩個不同機房的時候氢哮，假設用戶從IDC1過來，因為就近原理型檀，他會訪問L1冗尤，沒有的話才會跑到Master，當在IDC1沒找到的時候才會跑到IDC2來找胀溺。同時有用戶從IDC2訪問裂七，也會有請求從L1和Master返回或者到IDC1去查找。 IDC1 和 IDC2 仓坞，兩個機房都有全量的用戶數(shù)據背零，同時在線提供服務，但是緩存查詢又遵循最近訪問原理无埃。

還有哪些多級緩存的例子呢徙瓶？CDN是典型的多級緩存。CDN在國內各個地區(qū)做了很多節(jié)點嫉称，比如在杭州市部署一個節(jié)點時侦镇，在機房里肯定不止一臺機器，那么對于一個地區(qū)來說织阅，只有幾臺服務器到源站回源壳繁，其他節(jié)點都到這幾臺服務器回源即可，這么看CDN至少也有兩級蒲稳。Local Cache+ 分布式 緩 存氮趋，這也是常見的一種策略。有一種場景江耀，分布式緩存并不適用剩胁， 比如 單 點 資 源 的爆發(fā)性峰值流量，這個時候使用Local Cache + 分布式緩存祥国，Local Cache 在 應用 服 務 器 上用很小的 內存資源 擋住少量的 極端峰值流量昵观，長尾的流量仍然訪問分布式緩存，這樣的Hybrid緩存架構通過復用眾多的應用服務器節(jié)點舌稀，降低了系統(tǒng)的整體成本啊犬。

我們來看一下 Feed 的存 儲 架構，微博的博文主要存在MySQL中壁查。首先來看內容表觉至，這個比較簡單，每條內容一個索引睡腿，每天建一張表语御，其次看索引表峻贮，一共建了兩級索引。首先想象一下用戶場景应闯，大部分用戶刷微博的時候纤控，看的是他關注所有人的微博，然后按時間來排序碉纺。仔細分析發(fā)現(xiàn)在這個場景下船万， 跟一個用戶的自己的相關性很小了。所以在一級索引的時候會先根據關注的用戶骨田，取他們的前條微博ID耿导，然后聚合排序。我們在做哈希（分庫分表）的時候盛撑，同時考慮了按照UID哈希和按照時間維度碎节。很業(yè)務和時間相關性很高的，今天的熱點新聞抵卫，明天就沒熱度了狮荔，數(shù)據的冷熱非常明顯，這種場景就需要按照時間維度做分表介粘，首先冷熱數(shù)據做了分離（可以對冷熱數(shù)據采用不同的存儲方案來降低成本）殖氏，其次， 很容止控制我數(shù)據庫表的爆炸姻采。像微博如果只按照用戶維度區(qū)分雅采，那么這個用戶所有數(shù)據都在一張表里，這張表就是無限增長的慨亲，時間長了查詢會越來越慢婚瓜。二級索引，是我們里面一個比較特殊的場景刑棵，就是我要快速找到這個人所要發(fā)布的某一時段的微博時巴刻，通過二級索引快速定位。

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

分布式追蹤服務系統(tǒng)蛉签，當系統(tǒng)到千萬級以后的時候胡陪，越來越龐雜，所解決的問題更偏向穩(wěn)定性碍舍，性能和監(jiān)控柠座。剛才說用戶只要有一個請求過來，你可以依賴你的服務RPC1片橡、RPC2妈经，你會發(fā)現(xiàn)RPC2又依賴RPC3、RPC4。分布式服務的時候一個痛點狂塘，就是說一個請求從用戶過來之后录煤，在后臺不同的機器之間不停的調用并返回。

當你發(fā)現(xiàn)一個問題的時候荞胡，這些日志落在不同的機器上，你也不知道問題到底出在哪兒了嚎，各個服務之間互相隔離泪漂，互相之間沒有建立關聯(lián)。所以導致排查問題基本沒有任何手段歪泳，就是出了問題沒法兒解決萝勤。

我們要解決的問題，我們剛才說日志互相隔離呐伞，我們就要把它建立聯(lián)系敌卓。建立聯(lián)系我們就有一個請求ID，然后結合RPC框架伶氢， 服務治理功能趟径。假設請求從客戶端過來，其中包含一個ID 101癣防，到服務A時仍然帶有ID 101蜗巧，然后調用RPC1的時候也會標識這是101 ，所以需要 一個唯一的 請求 ID 標識 遞歸迭代的傳遞到每一個 相關 節(jié)點蕾盯。第二個幕屹，你做的時候，你不能說每個地方都加级遭，對業(yè)務系統(tǒng)來說需要一個框架來完成這個工作望拖， 這 個框架要 對業(yè)務 系 統(tǒng) 是最低侵入原 則 ， 用 JAVA 的 話 就可以用 AOP挫鸽，要做到零侵入的原則说敏，就是對所有相關的中間件打點，從接口層組件（HTTP Client掠兄、HTTP Server）至到服務層組件（RPC Client像云、RPC Server），還有數(shù)據訪問中間件的蚂夕，這樣業(yè)務系統(tǒng)只需要少量的配置信息就可以實現(xiàn)全鏈路監(jiān)控 迅诬。為什么要用日志？服務化以后婿牍，每個服務可以用不同的開發(fā)語言侈贷， 考慮多種開發(fā)語言的兼容性 ， 內部定 義標 準化的日志 是唯一且有效的辦法。

最后俏蛮，如何構建基于GPS導航的路況監(jiān)控撑蚌？我們剛才講分布式服務追蹤。分布式服務追蹤能解決的問題搏屑， 如果 單一用 戶發(fā)現(xiàn)問題 后 争涌， 可以通 過請 求 ID 快速找到 發(fā) 生 問

題 的 節(jié) 點在什么，但是并沒有解決如何發(fā)現(xiàn)問題辣恋。我們看現(xiàn)實中比較容易理解的道路監(jiān)控亮垫，每輛車有GPS定位，我想看北京哪兒擁堵的時候伟骨，怎么做饮潦？ 第一個 ， 你肯定要知

道每個 車 在什么位置携狭，它走到哪兒了继蜡。其實可以說每個車上只要有一個標識，加上每一次流動的信息逛腿，就可以看到每個車流的位置和方向稀并。 其次如何做 監(jiān) 控和 報 警，我們怎么能了解道路的流量狀況和負載鳄逾，并及時報警稻轨。我們要定義這條街道多寬多高，單位時間可以通行多少輛車雕凹，這就是道路的容量殴俱。有了道路容量，再有道路的實時流量枚抵，我們就可以基于實習路況做預警线欲？

對應于 分布式系 統(tǒng) 的話如何構建？ 第一 汽摹， 你要 定義 每個服 務節(jié) 點它的 SLA A 是多少 李丰？SLA可以從系統(tǒng)的CPU占用率、內存占用率逼泣、磁盤占用率趴泌、QPS請求數(shù)等來定義，相當于定義系統(tǒng)的容量拉庶。 第二個 嗜憔， 統(tǒng)計 線 上 動態(tài) 的流量，你要知道服務的平均QPS氏仗、最低QPS和最大QPS吉捶，有了流量和容量，就可以對系統(tǒng)做全面的監(jiān)控和報警。

剛才講的是理論呐舔，實際情況肯定比這個復雜币励。微博在春節(jié)的時候做許多活動，必須保障系統(tǒng)穩(wěn)定珊拼，理論上你只要定義容量和流量就可以食呻。但實際遠遠不行，為什么澎现？有技術的因素搁进，有人為的因素，因為不同的開發(fā)定義的流量和容量指標有主觀性奋救，很難全局量化標準畜挨，所以真正流量來了以后，你預先評估的系統(tǒng)瓶頸往往不正確。實際中我們在春節(jié)前主要采取了三個措施：第一端姚，最簡單的就是有降 級 的 預 案，流量超過系統(tǒng)容量后上枕，先把哪些功能砍掉丸卷，需要有明確的優(yōu)先級 。第二個捐名， 線上全鏈路壓測旦万，就是把現(xiàn)在的流量放大到我們平常流量的五倍甚至十倍（比如下線一半的服務器，縮容而不是擴容）镶蹋，看看系統(tǒng)瓶頸最先發(fā)生在哪里成艘。我們之前有一些例子，推測系統(tǒng)數(shù)據庫會先出現(xiàn)瓶頸贺归，但是實測發(fā)現(xiàn)是前端的程序先遇到瓶頸淆两。第三，搭建在線 Docker 集群 拂酣， 所有業(yè)務共享備用的 Docker集群資源秋冰，這樣可以極大的避免每個業(yè)務都預留資源，但是實際上流量沒有增長造成的浪費婶熬。

在這里給大家提供一個學習交流的平臺剑勾，java架構師群 671017482

具有1-5工作經驗的，面對目前流行的技術不知從何下手赵颅，需要突破技術瓶頸的可以加群虽另。

在公司待久了，過得很安逸性含，但跳槽時面試碰壁洲赵。需要在短時間內進修、跳槽拿高薪的可以加群。

如果沒有工作經驗叠萍，但基礎非常扎實芝发，對java工作機制，常用設計思想苛谷，常用java開發(fā)框架掌握熟練的可以加群辅鲸。

總結

接下來說的是如何不停的學習和提升，這里以Java語言為例腹殿，首先独悴， 一定要 理解 JAVA；第二步锣尉，JAVA完了以后刻炒，一定要 理 解 JVM；其次自沧，還要 理解 操作系統(tǒng)坟奥；再次還是要了解一下 Design Pattern，這將告訴你怎么把過去的經驗抽象沉淀供將來借鑒拇厢；還要學習 TCP/IP爱谁、 分布式系 統(tǒng)、數(shù)據結構和算法孝偎。

最后就是我想說的就是今天我所說的可能一切都是錯的访敌！大家通過不停的學習、練習和總結衣盾， 形成自己的一套架構設計原則和方法寺旺，謝謝大家。