結果一上線，由於端上有一個 bug，然後所有的等於 ddos 攻擊一樣，不停閃。當時 Passport 伺服器還比較少，10 臺左右的服務，正常 CPU 利用率大概在 30% 不到，那個介面一上一下子到 70%，眼看全要掛了，然後連夜我們趕快把那樣一個介面單獨拆出來，打到不同的單元上，然後重新部署。

所以給大家一個建議，當用 SOA 的時候，如果你的量特別大的時候，你一定要記得把它的 CPU 佔用非常高那些功能及介面提前單獨拆分出來。

高可用的效果

更多得益於 golang 本身，我們去年線上單機 QPS 峰值超過一萬，現在我們有更多的機房，滴滴整個的訂單去年和今年都是有數倍增長。

我們響應時間，我們的所有介面無論獲取使用者資訊或者是校驗，其實是非常小的，目前高併發介面小於 5 毫秒。密碼相關的介面是在 200 毫秒，這主要加解密本身的耗時。

總結

滴滴跟前面分享的今日頭條非常相似，發展太快，四年的時間，滴滴的技術規範完全沒有統一，文嵩加入滴滴之後，有機會再做服務治理包括框架統一，但是這件事可能會比較挑戰，目前滴滴的技術體系特別異構，PHP、Java、Golang 都有，因此目前也不能太多從系統層面給大家做分享，以後應該有這樣的機會。

後面有一句話，什麼是一切為了高可用？針對 Passport 賬號這種系統，需要有柔性的降級，可能需要一些巧妙設計，包括多機房。

one more thing

被攻擊的問題

再補充一個被攻擊的問題。其它的系統被攻擊相對好一點，賬號給你擋了，登入後再攻擊，至少有 ticket 給你擋了。

發簡訊攻擊，這個維護費用是非常巨大的，攻擊者目的你並不知道，他就是要你不停發簡訊，曾經被這個東西搞得焦頭爛額。

當然可以做一些蜜罐的機制，當發現有異常，返回正常值，讓攻擊者覺得正常，其實服務端什麼也沒做，這是蜜罐機制。要真正解決這類問題，跟安全部一起做了試點，端上做這種是比較簡單，認證比較容易。但是在 app 上不好做，通過 JavaScript 算，其實比較麻煩，並且容易別識破。另外還可以做一些人機識別機制。

Q&A

Q：token 什麼時候更新？

洪澤國：token 只有兩種失效機制，一個是使用者重新登入，第二個踢掉，現在參照微信的做法，端上定期會拿著來換一次。

Q：密碼更新，所有的 token 都失效 如何解決？

洪澤國：金鑰一更新，登入都踢出？這個問題之前的確有討論過，有兩種方式，第一，讓它失效，所有人重新登入，並不是完全不能接受，對使用者來講就是重新登入，金鑰洩漏是一次事故。第二，看緊急程度，當前哪些人登入，比如先把沒有登入的踢掉，後端算出來，對於已經有的，然後慢慢踢。新的在入口的時候，就要給它打到新的一套服務裡面去，你要做新老兩套金鑰服務之間的切換，並且在上線是知道。

Q：HttpDNS 作用？

洪澤國：HttpDNS 從入口層面上就決定了所有的這一個請求全部落在這個機房，而不會存在兩個 IDC 之間內部錯峰的一切交替，不會你這個故障某一個服務我就打到那邊。HttpDNS 比較簡單，維護的資訊比較少。無非就是一個服務對應一個IP列表，這是動態，這是很容易做的，資訊不會太多。

Q：切換 IDC 怎麼做，資料你怎麼複製？

洪澤國：我們的確在討論這樣的方式，我不太確認是不是能夠最完美回答你的問題，我們現在方案通過 HttpDNS 做中轉，通過它我能夠完成這件事情，第二，怎麼發現故障，這裡麵包括兩個問題，一個是怎麼發現 IDC 掛了。第二，發現後怎麼做，發現後 HttpDNS 很容易給一個新地址。第一個問題怎麼發現，我們內部也在嘗試一些方法，可能更多通過手段的方式，或者通過檢測鏈路故障，無非觸發時機，所有的鏈路故障都是從系統，網路層面上觸發的。只要 HttpDNS 提供一個介面，一旦故障給它打個標記，A 故障，HttpDNS 就返回 B，這是很容易做到。但是怎麼判斷它是故障，這是一個問題。這個更多從網路層面去觸發。

Q：剛才說如果其它服務鏈路問題導致 Web 失效，把使用者踢下去，對於這種情況你們怎麼處理，不是你本身的問題。

洪澤國：這個是呼叫方有約束的，調網路錯誤不應該是提的，更多是要從業務層面上，端和業務系統的配合形成。它調一個業務，業務調我，業務調我超時了，現在好多業務處理不是那麼完美，出錯也踢掉這是不合理的，我們跟他梳理，只有失效踢出是最合理。如果沒有的話就踢掉，簡訊服務提供商那邊壓力是比較大的，做柔性降級。