双中心机房部署
解决方案
系统对外接入能力分为两种业务：业务能力、业务支撑。其中业务能力为央视影音客户端、IPTV、互联网电视等业务线与用户中心系统之间交互的能力接口层，业务线可调用用户中心相关服务接口为用户提供服务。业务支撑为运营管理人员提供了丰富的运营管理功能。经过业务分析，业务支撑运营管理要求的可用性较低，固业务支撑服务只在私有云机房部署即可。因此我们只需要对业务能力、service服务、以及数据层进行双中心部署。
双中心部署业务能力、services服务集群、数据库、nosql缓存数据库、文件系统等一分二，在两个云机房分别进行部署即可。用户请求通过智能DNS解析，通过判定请求来源IP属于哪个ISP，从而调度到对应的机房处理用户请求。这种智能DNS解析可能会导致用户多次请求分发到不同机房，比如用户IP发生变更、DNS劫持等情况，解决这类问题的方式大致有两种：一种是将请求信息先发送到自己的GSLB服务中，GSLB服务根据用户信息决定将请求分发到哪个机房，这种方式局限性大，需要请求中携带用户相关信息；另外一种是从数据层保证双中心机房数据的一致性，从而保证用户请求无论是到哪个机房都能正确处理。
为保证双中心机房数据一致性，我们需要将业务分为三种类型：一种双中心独立读写型；一种是双向同步；另外一种是单点写入型。
一、双中心独立读写型
如DB缓存数据，这类数据是接口访问DB的缓存数据，缓存命中则读取缓存数据，缓存不命中则会重新从DB中读取数据并更新缓存，且基于DB binlog的canal服务会实时更新缓存数据，固只要保证了DB数据一致性，这部分DB缓存就不需要进行双中心同步了。
二、双向同步
系统/用户行为日志文件，系统日志文件只要用于排查问题、归档存储，用户行为日志文件用来做用户行为分析，为精准营销做数据抽取，所以有一定延时是完全可以接受的，这部分文件我们采用flume+kafka进行双向同步。
通过flume-ng实时采集传输日志文件内容，发送到kafka消息队列中，目标机房通过kafka consumer将消息队列中的日志文件内容实时写入到目标机房。即使发生网络中断、或服务故障，日志文件内容依然缓冲在kafka消息队列中，待网络、服务恢复后则会继续写入积压的日志文件内容。
文件系统是保存运营支撑平台活动素材、用户图片、视频等资源文件的，我们采用分布式文件系统进行部署，两个机房的所有文件存储服务组成同一个分布式文件系统集群。
双中心机房分别部署client和tracker server服务，以便双中心机房能各自管理storage cluster group配置信息，及upload、append、download、delete等操作。Storage cluster跨机房进行配置，每个group中的storage节点必须跨机房，由于group下的storage是互为备份的，每个storage节点都会存储整个group的全量文件，故这种部署策略能防止单点故障、网络中断造成的数据丢失。
三、单点写入型
为保证业务数据的一致性，写入操作只允许单点写，即跨机房写入核心私有云机房，写入介质可以是DB、缓存等。
写入操作分为两种，一种无需知道写入结果且允许一定延迟，这部分数据我们通过MQ消息队列远程异步去写入，公有云机房将写入操作发送至MQ中，私有云机房MQ消费者负责拉取消息，并保证成功写入数据至缓存或DB中，即使发生网络故障，消息会积压在MQ消息队列中，待网络恢复后再去拉取消息并写入。另一种写入必须马上知道结果或对于写入延迟0容忍，这类数据我们必须跨机房实时同步写入，如果网络故障导致写入失败，服务将暂时不可用，这时候我们在针对服务做降级处理。
在保证单点写入的同时，我们利用主从同步、数据同步工具等手段，将私有云机房的数据实时同步至公有云机房，保证数据的一致性。若网络发生故障，数据同步暂时停止，将影响部分服务的可用性和可靠性，这时我们需要针对服务进行降级处理，待网络恢复后继续同步数据、恢复服务。