这些 token 失效是通过有效期，就是几个小时，失效后就用 ticket 来换。
结果一上线，由于端上有一个 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 失效，把用户踢下去，对于这种情况你们怎么处理，不是你本身的问题。
洪泽国：这个是调用方有约束的，调网络错误不应该是提的，更多是要从业务层面上，端和业务系统的配合形成。它调一个业务，业务调我，业务调我超时了，现在好多业务处理不是那么完美，出错也踢掉这是不合理的，我们跟他梳理，只有失效踢出是最合理。如果没有的话就踢掉，短信服务提供商那边压力是比较大的，做柔性降级。
