收購“大黃蜂”，開啟商務車業(yè)務覆蓋城市：70+5月成立，8月上線運營1億用戶日訂單：600w+滴滴快的合并公司沒有知名度技術團隊10-30人左右日訂單從幾百單到幾萬單作坊式研發(fā)系統(tǒng)僅滿足基本的功能天氣不好系統(tǒng)就快的一

滴滴也反過來也是一樣，很有默契確立了原始的系統(tǒng)模型MongoDBMina2013年底打車大戰(zhàn)爆發(fā)，很短時間內，日訂單規(guī)模從幾萬單迅速膨脹到幾百萬單。系統(tǒng)面臨很多問題，問題分優(yōu)先級，首先對鏈路進行優(yōu)化，否則業(yè)務主流程都無法正常進行。鏈路問題及業(yè)務影響LBS瓶頸問題：暴增的LBS查詢和寫入給MongoDB帶來巨大的壓力，經常會延時影響：推單時選取的

有時離乘客很遠，或者很近的卻沒有推送長連接服務穩(wěn)定性問題：TCP

server期CPU

load很高、消息被截斷、連接丟失影響：

收不到訂單；

接單了乘客卻不知道；乘客取消訂單了不知道硬件問題不支持多隊列的網卡，IO中斷都被分配到了一個cpu核上，大量數據包到來的情況下，單個cpu核無法全部處理，導致LVS不斷丟包，連接不斷中斷。解決方案更換支持硬件多隊列的網卡(In在2.6.21以上)、，的57711等，linux

內核版本需要問題（Mina框架）內存使用控制不夠細粒度，

回收難以有效控制空閑連接檢查效率不高，在大量連接的情況下會出現周期性CPU

使用率飆高編

組件在高并發(fā)下會出現消息被截斷的情況解決方案（快的自己的AIO框架）資源(主要是ByteBuffer)池化,減少GC造成的影響廣播時，一份ByteBuffer復用到多個通道，減少內存拷貝使用TimerWheel檢測空閑連接，消除空閑連接檢測造成的支持按優(yōu)先級發(fā)送數據CPU尖峰Timer

wheel截止到2014年4月份，

解決了LBS瓶頸、長連接服務的穩(wěn)定性，

業(yè)務流程的穩(wěn)定性有很大提高。技術團隊100多人，日訂單600萬左右，業(yè)務場景越來越復雜，原來很多非核心問題變得越來越嚴重。穩(wěn)定性差經常會出現一些功能不可用。都忙著做業(yè)務需求，怎么快怎么來，后面堆積了大量的歷史債業(yè)務混雜在一起伸縮性差業(yè)務和非瓶頸每天有幾百萬的訂單，每天都發(fā)大量的券，單庫單表已經無法支撐了效率低下所有業(yè)務都在一個系統(tǒng)里，每天很多的并行分支安全問題線上配置都是明文寫在工程配置文件里的；XSS

很多沒有無法了解系統(tǒng)運行情況，故障定位效率很低協(xié)議客戶端和服務器的通信協(xié)議

，沒有

的文檔和格式一切都是為了更高的可用性系統(tǒng)全局梳理應用分布式改造無線開放平臺數據層改造日志收集與檢索系統(tǒng)風控平臺配置中心研發(fā)流程自動化流程與規(guī)范建立研發(fā)流程、代碼規(guī)范、SQL規(guī)范執(zhí)行嚴格的code

review，普及質量意識建立故障問責機制穩(wěn)定性的單點的性能瓶頸活動梳理鏈梳理鏈梳理每個環(huán)節(jié)的故障恢復機制，比如網絡閃斷后能否自動重連以及重連的影響梳理JVM

配置、tomcat配置、應用參數配置定期對系統(tǒng)做性能壓測，科學合理的應對定期review系統(tǒng)的機器部署建立服務降級機制業(yè)務梳理小規(guī)模的迭代重構不求一步到位，但求一直進步最初只有兩個系統(tǒng)http(系統(tǒng)名字就叫http)：處理客戶端http請求，例如乘客發(fā)單、支付等tcp(系統(tǒng)名字就叫tcp)：客戶端心跳處理；客戶端消息推送強依賴場景：A調用B，A依賴返回結果判定流程，用分布式RPC框架實現弱依賴場景：A調用B，A的處理邏輯不依賴返回結果，用分布式消息隊列實現mysqlredismongodb文件系統(tǒng)訂單lbs用戶支付數據層服務層發(fā)單接單付款登錄其他業(yè)務層工程架構向分布式邁進，整體劃分為三個層次：業(yè)務層、服務層、數據層。以下是示例圖，不是真實的架構圖RPC的選型大規(guī)模服務化之前，應用可能通過RPC工具簡單

和

服務，通過配置服務的地址進行調用，然而只是簡單的RPC還不夠。除了網絡通信和數據序列化，大型分布式RPC還應具備的其他要素：基于快的應用場景，

引入了開源的分布式PRC框架：dubbo。dubbo是阿里開源的框架，在阿里內部和國內大型互聯網公司有廣泛的應用，

對dubbo源碼足夠的了解。關于Dubbo踩過的一些坑鏈式調用的超時雪崩client->A(timeout:3s),A->B(timeout:3s),A->C(timeout:3s)。B是非關鍵服務，C是關鍵服務。B不可用時，A傻等3s最終超時，業(yè)務不可用；B變慢，

時期A線程耗光，業(yè)務不可用。線程優(yōu)先級Provider

A提供了關鍵服務A1，非關鍵服務A2，

時A2耗時高導致線程 ，導致A1不能提供服務。服務不停的上線下線Provider內存使用不當導致頻繁fullgc，觸發(fā)了Zookeeper的超時被下線，Provider

fullgc完成后又向zk

自己，過一會又fullgc服務無法中心協(xié)議，導致用默認的Dubbo協(xié)議用zookeeper做 中心，配置的 中心地址只寫ip和端口，沒有配置forbid

consumer異常調用某服務時出現該異常，原因是該服務的所有實例都下線了Zookeeper輸出大量的debug日志配置的log4j不是debug級別，但應用大量出現debug日志，zookeeper

3.4.3的日志系統(tǒng)是slf4j，應用里還依賴聊logback。StaticLoggerBinder.getSingleton()加載了logback配置，默認是debug級別，log4j沒有生效。消息隊列的選型選擇了RocketMQ，它在淘寶和支付寶得到了非常廣泛的應用，也有很多外部用戶。RocketMQ是java版的kafka。選擇RocketMQ是對現實衡量后一個比較合適的方案。足夠的掌控力快的所有系統(tǒng)都用java實現，對java最了解；RocketMQ全部是java實現；

非常了解源碼，向作者報告過幾個bug，自己改進過某些實現。高性能實測千兆網卡，2K消息大小，單機TPS16000生產消費無延遲。CPU消耗不大，瓶頸在網卡。線性伸縮服務能力可以隨著Broker的增加而得到線性的提升，而且擴展幾乎沒有限制；這方面和Kafka是一樣的。RocketMQ和Kafka的比較1主要相同點pull模型消費；topic分區(qū)；通過磁盤持久化消息；自己刷pagecache；mmap；sendfile；read-ahead;write-behind；運行在JVM上2主要不同點消息

結構RocketMQ單個broker的所有消息混合，磁盤寫性能更高；Kafka按分區(qū)

，分區(qū)內順序寫，但全局隨機，這局限了Kafka單個broker的分區(qū)數量不能太大，不超過64，而RocektMQ單個Broker結構導致它額外的增加了索引，每次先查詢索引，再定的分區(qū)可以達到10000。RocketMQ的混合位消息，增加了時間成本。集群管理RocketMQ用自己的NameServer，NameServer之間沒有關系；Kafka用Zookeeper做集群管理廣播消費RocketMQ可以將消息廣播到一個ConsumerGroup內的所有機器，也可以廣播給不同的ConsumerGroup，Kafka只能做到后者，這是有局限性的的問題客戶端與服務端通信硬編碼每新增一個業(yè)務請求，都要在服務端配置一個code和對應的邏輯處理，導致web工程經常改動發(fā)布。沒有

格式請求和響應格式沒有規(guī)范，導致服務端很難對請求做

處理，例如ABTest、監(jiān)測不同平臺和版本的流量。而且第合作伙伴集成的方式非常

護成本高。流量控制和安全來多少請求就處理多少，根本不考慮后端服務的承受能力。而某些時候需要對后端做保護，例如過多的流量；后端服務快撐不住了；單個IP

頻率過高；單個用戶

頻率過高等等。開發(fā)效率業(yè)務邏輯比較分散，有的在web應用里，有的在dubbo服務里。提供新功能時，工程師關注的點比較多，增加了系統(tǒng)風險。文檔業(yè)務頻繁變化和快速發(fā)展，文檔無法跟上，最后沒人能說清到底有哪些協(xié)議，協(xié)議里的字段含義針對這些問題，重新設計了無線接入服務，也就是快的無線開放平臺：KOP。以下是一些大的設計原則：—接入權限控制為接入的客戶端分配一對appkey/appsecret，appkey是客戶端唯一標識，app

secret是一個密鑰由客戶端保管，用來對請求做數字簽名。KOP對客戶端請求做簽名校驗，校驗通過才會執(zhí)行請求。二流量分配和降級同樣的API，不同接入端的

限制可以不一樣?？砂闯鞘?、客戶端平臺類型做ABTest。情況下，優(yōu)先保證單，接單，支付這些客戶端的流量，同時也會優(yōu)先保證

API的服務能力，例如登錄，下的API。被被限制時，返回一個限流錯誤碼，客戶端根據不同場景酌情處理。三流量分析綜合考慮客戶端、API、IP、用戶多個維度，實時分析當前請求是否

請求，

的IP和用戶會被凍結一段時間，如果嚴重的則會進入

封禁。防重放

，為了防止請求的URL被重放，客戶端生成的URL都是有有效期的，服務器會比對請求里的時間戳和服務器當前時間，如果超過設置的閾值，將會返回一個請求過期錯誤。黑白基于請求URL的表達式四實時發(fā)布上線或下線API不需要對KOP進行發(fā)布，實時生效。當然，為了安全，會有API的審核機制。五實時能統(tǒng)計每個客戶端對每個API每分鐘的調用總量、成功量、失敗量、平均耗時能以分鐘為單位查看指定時間段內的數據曲線，并且能對比歷史數據當響應時間或失敗數量超過閾值時，系統(tǒng)會自動發(fā)送

。日志場景快速查詢分布在多臺機器上的日志，方便問題快速定位用戶請求

多個集群，一鍵查詢出請求的日志軌跡基于日志做實時的計算分析關于日志收集日志分為檢索類日志和計算類日志，檢索類日志通過log4j的flume

appender異步傳輸給flume

logserver，組后sink到elasticsearch。單個請求生命周期內的所有日志通過一個flag串聯，flag隨著dubbo請求傳遞到不同的JVM里，這樣能通過一個flag搜索出請求的生命周期內的操作軌跡。日志收集的agent通過管理平臺分發(fā)和部署，ageng定時上報心跳，通過管理系統(tǒng)能看到每個agent的運行情況，每個機器上有

自動

agent是否在運行，沒有運行則強制啟動，當然這個行為是可以關閉的。關于日志檢索當一個客戶端請求一個分布式的服務器端，的調用路徑非常復雜。當發(fā)生故障或者排查問題時，根據某些關鍵字快速定位對應的日志軌跡顯得非常重要。elasticsearch一共5臺物理機，每天處理1T的日志，日志檢索主要是為定位問題用，寫入量大，查詢量少。按照不同的業(yè)務分索引，比如出租車一個索引，代駕一個索引，每個索引10個主分片，每個分片1個副本，分片副本沒有配置太多是因為查詢比較少而索引更新量很大，這樣可以減少主分片和副本之間數據同步的成本，加快索引執(zhí)行的速度。主分片的數量需要根據實際場景權衡，分片多可以增加索引執(zhí)行的并發(fā)度，但是在排序和分頁時會增加

的消耗。為充分利用內存，單臺物理機上開啟兩個elasticsearch實例elasticsearch實例的GC策略用CMS，堆大小設置為8G，為及早進行平滑的回收，CMSInitiatingOccupancyFraction設為65Bulk方式提交數據，index.refresh_interva設定為20秒的問題，不知道有故障，知道有故障了也不清楚故障點在哪里沒有不知道實時的運營數據基于這些原因，

基于Storm和HBase設計了自己的實時

平臺，分鐘級別實時展現系統(tǒng)運行狀況和業(yè)務數據。計算模型求和，求平均，分組舉例說明例它的每分鐘錯誤數量、請求總數，平均耗時，并且可按城市維度查看。一個A系統(tǒng)的，要日志信息定義名稱：perf

；路徑：/data/logs/perf.log

；格式：20151007111111,login.html,

,10名稱：error；路徑：/data/logs/error.log；格式：20151007111111,錯誤詳情日志模型perf：逗號分隔；年月日小時分鐘，請求URL，城市，耗時error：逗號分隔；年月日小時分鐘，錯誤詳情計算規(guī)則錯誤數量：select

sum(count)from

A.error請求總量：select

sum(count)

from

A.perf總平均耗時：select

avg(耗時)from

A.perf城市維度總量：select

sum(count)

from

A.perf

group

by

城市城市維度平均耗時：select

avg(耗時)from

A.perf

group

by

城市基于storm的流式計算只有兩個bolt，以剛才的例子說明請求總量城市維度請求總量總平均耗時基于HBase的數據只有

，沒有更新，避免了HBase行鎖競爭rowkey是有序的，因為要根據維度和時間段查詢，這樣會形成HBase

Region熱點，導致寫入比較集中，但是沒有性能問題，因為每個維度每隔1分鐘定時

，平均每秒的

很少。即使前端應用的日志量突然增加很多，HBase的

頻度仍然是穩(wěn)定的?；赗ocketMQ的數據緩沖收集的日志和storm計算的結果都先放入metaq集群，無論storm集群還是

節(jié)點，發(fā)生故障時系統(tǒng)仍然是穩(wěn)定的，不會將故障放大；即使有突然的流量

，因為有消息隊列做緩沖，storm和HBase仍然能以穩(wěn)定的TPS處理。這些都極大的保證了系統(tǒng)的穩(wěn)定性。metaq集群自身的健壯性足夠強，都是物理機。SSD

盤、高配內存和CPU、Broker全部是M/S結構?？梢?/p>

足夠多的緩沖數據。隨著業(yè)務發(fā)展，單數據庫單表已經

性能要求，特別是發(fā)券和訂單，開始考慮對某些數據做分庫分表了。

選擇在客戶端分庫分表，自己做了一個通用框架解決分庫分表的問題。但是還有以下問題：數據同步快的原來的數據庫分為前臺庫和庫，前臺庫給應用系統(tǒng)使用，庫只供使用。不管前臺應用有多少庫，庫只有一個，那么前臺的多個庫多個表如何對應到

的單庫單表？mysql的無法解決這個問題。離線計算抽取還有大數據的場景，大數據同事經常要dump數據做離線計算，都是通過sqoop到庫抽數據，有的復雜sql經常會使數據庫變得不穩(wěn)定。而且，不同業(yè)務場景下的sqoop會造成數據重復抽取，給數據庫添加了的負擔。的數據同步方案實現，mysql

binlog方式改為Row模式，將c抽取的binlog解析為mq消數據抽取用開源的c息，打包傳輸給MQ.一份數據，多種消費場景，之前是每種場景都抽取一份數據各個消費端不需要關心mysql，只需要關心mq的topic支持全局有序，局部有序，并發(fā)亂序可以指定時間點回放數據數據鏈路

、通過管理平臺自動部署節(jié)點分庫分表解決了前臺應用的性能問題，數據同步解決了多庫多表歸一的問題，但是隨著時間推移，單庫的問題越來越嚴重，迫切需要

案解決海量數據

的問題，同時又要讓現有的上層應用不會有太大改動。因為

基于HBase和數據同步設計了實時數據中心。將前臺mysql多庫多表通過同步平臺，都同步到了HBase為減少

應用層的改動，設計了一個SQL解析模塊，將SQL查詢轉換為HBase查詢支持二級索引二級索引HBASE并不支持二級索引，對HBASE而言只有一個索引那就是rowkey。如果要按其它字段查詢，那就要為這些字段建立與rowkey的

關系，這就是所謂的二級索引。HBSE二級索引可以通過Coprocessor在數據之前執(zhí)行一段代碼，這段代碼運行在HBASE服務端(