另外，為了防止單個(gè)調(diào)用方的非法調(diào)用對(duì)服務(wù)的影響，服務(wù)也支持了多個(gè)維度限流，包括調(diào)用方AppId/ip限流和服務(wù)限流，接口限流等。
四、性能&擴(kuò)展
由于 在線旅游 行業(yè)近幾年的高速增長(zhǎng)，攜程作為行業(yè)領(lǐng)頭羊也蓬勃發(fā)展，因此訪問量和數(shù)據(jù)量也大幅提升。公司對(duì)業(yè)務(wù)的要求是可以支撐10倍容量擴(kuò)展，擴(kuò)展最難的部分在數(shù)據(jù)層，因?yàn)樯婕暗酱媪繑?shù)據(jù)的遷移。
實(shí)時(shí)用戶行為系統(tǒng)的數(shù)據(jù)層包括Redis和MySQL，Redis因?yàn)閷?shí)現(xiàn)了一致性哈希，擴(kuò)容時(shí)只要加機(jī)器，并對(duì)分配到新分區(qū)的數(shù)據(jù)作讀補(bǔ)償就可以。
MySQL方面，我們也做了水平切分作為擴(kuò)展的準(zhǔn)備，分片數(shù)量的選擇考慮為2的n次方，這樣做在擴(kuò)容時(shí)有明顯的好處。因?yàn)閿y程的mysql數(shù)據(jù)庫(kù)現(xiàn)在普遍采用的是一主一備的方式，在擴(kuò)容時(shí)可以直接把備機(jī)拉平成第二臺(tái)（組）主機(jī)。假設(shè)原來分了2個(gè)庫(kù)，d0和d1，都放在服務(wù)器s0上，s0同時(shí)有備機(jī)s1。擴(kuò)容只需要如下幾步：
確保s0 -> s1同步順利，沒有明顯延遲 s0暫時(shí)關(guān)閉讀寫權(quán)限 確認(rèn)s1已經(jīng)完全同步s0更新 s1開放讀寫權(quán)限 d1的dns由s0切換到s1 s0開放讀寫權(quán)限
遷移過程利用MySQL的復(fù)制分發(fā)特性，避免了繁瑣易錯(cuò)的人工同步過程，大大降低了遷移成本和時(shí)間。整個(gè)操作過程可以在幾分鐘完成，結(jié)合DB降級(jí)的功能，只有在DNS切換的幾秒鐘時(shí)間會(huì)產(chǎn)生異常。
整個(gè)過程比較簡(jiǎn)單方便，降低了運(yùn)維負(fù)擔(dān)，一定程度也能降低過多操作造成類似GitLab式悲劇的可能性。
五、部署
前文提到Storm部署是比較方便的，只要上傳重啟就可以完成部署。部署之后由于程序重新啟動(dòng)上下文丟失，可以通過Kafka記錄的游標(biāo)找到之前處理位置，恢復(fù)處理。
另外有部分情況下程序可能需要多版本運(yùn)行，比如行為紀(jì)錄暫時(shí)有多個(gè)版本，這種情況下我們會(huì)新增一個(gè)backupJob，在backupJob中運(yùn)行歷史版本。