首先是系统层面上做了全栈集群化。Kafka和Storm本身比较成熟地支持集群化运维；Web服务支持了无状态处理并且通过负载均衡实现集群化；Redis和DB方面携程已经支持主备部署，使用过程中如果主机发生故障，备机会自动接管服务；通过全栈集群化保障系统没有单点。
另外系统在部分模块不可用时通过降级处理保障整个系统的可用性。先看看正常数据处理流程（如下图）：
图7 正常数据流程
在系统正常状态下，Storm会从Kafka中读取数据，分别写入到Redis和MySQL中。服务从Redis拉取（取不到时从DB补偿），输出给客户端。DB降级的情况下，数据流程也随之改变（如下图）。
图8 系统降级-DB
当MySQL不可用时，通过打开DB降级开关，Storm会正常写入Redis，但不再往MySQL写入数据。数据进入Reids就可以被查询服务使用，提供给客户端。另外Storm会把数据写入一份到Kafka的Retry队列，在MySQL正常服务之后，通过关闭DB降级开关，Storm会消费Retry队列中的数据，从而把数据写入到MySQL中。Redis和MySQL的数据在降级期间会有不一致，但系统恢复正常之后会通过Retry保证数据最终的一致性。Redis的降级处理也类似（如下图）：
图9 系统降级-Redis
唯一有点不同的是Redis的服务能力要远超过MySQL。所以在Redis降级时系统的吞吐能力是下降的。这时我们会监控db压力，如果发现MySQL压力较大，会暂时停止数据的写入，降低MySQL的压力，从而保证查询服务的稳定。
为了降低故障情况下对下游的影响，查询服务通过Netflix的Hystrix组件支持了熔断模式（如下图）。
图10 Circuit Breaker Pattern
在该模式下，一旦服务失败请求在给定时间内超过一个阈值，就会打开熔断开关。在开关开启情况下，服务对后续请求直接返回失败响应，不会再让请求经过业务模块处理，从而避免服务器进一步增加压力引起雪崩，也不会因为响应时间延长拖累调用方。
开关打开之后会开始计时，timeout后会进入Half Open的状态，在该状态下会允许一个请求通过，进入业务处理模块，如果能正常返回则关闭开关，否则继续保持开关打开直到下次timeout。这样业务恢复之后就能正常服务请求。
另外，为了防止单个调用方的非法调用对服务的影响，服务也支持了多个维度限流，包括调用方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中运行历史版本。
相关阅读：
相关推荐：
转载请注明出处。
相关文章
精彩导读
热门资讯
关注我们
