另外，为了防止单个调用方的非法调用对服务的影响，服务也支持了多个维度限流，包括调用方AppId/ip限流和服务限流，接口限流等。
四、性能&扩展
由于 在线旅游 行业近几年的高速增长，携程作为行业领头羊也蓬勃发展，因此访问量和数据量也大幅提升。公司对业务的要求是可以支撑10倍容量扩展，扩展最难的部分在数据层，因为涉及到存量数据的迁移。
实时用户行为系统的数据层包括Redis和MySQL，Redis因为实现了一致性哈希，扩容时只要加机器，并对分配到新分区的数据作读补偿就可以。
MySQL方面，我们也做了水平切分作为扩展的准备，分片数量的选择考虑为2的n次方，这样做在扩容时有明显的好处。因为携程的mysql数据库现在普遍采用的是一主一备的方式，在扩容时可以直接把备机拉平成第二台（组）主机。假设原来分了2个库，d0和d1，都放在服务器s0上，s0同时有备机s1。扩容只需要如下几步：
确保s0 -> s1同步顺利，没有明显延迟 s0暂时关闭读写权限 确认s1已经完全同步s0更新 s1开放读写权限 d1的dns由s0切换到s1 s0开放读写权限
迁移过程利用MySQL的复制分发特性，避免了繁琐易错的人工同步过程，大大降低了迁移成本和时间。整个操作过程可以在几分钟完成，结合DB降级的功能，只有在DNS切换的几秒钟时间会产生异常。
整个过程比较简单方便，降低了运维负担，一定程度也能降低过多操作造成类似GitLab式悲剧的可能性。
五、部署
前文提到Storm部署是比较方便的，只要上传重启就可以完成部署。部署之后由于程序重新启动上下文丢失，可以通过Kafka记录的游标找到之前处理位置，恢复处理。
另外有部分情况下程序可能需要多版本运行，比如行为纪录暂时有多个版本，这种情况下我们会新增一个backupJob，在backupJob中运行历史版本。