双中心机房部署解决方案

系统对外接入能力分为两种业务：业务能力、业务支撑。

其中业务能力为央视影音客户端、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 容忍，这类数据我们必须跨机房实时同步写入，如果网络故障导致写入失败，服务将暂时不可用，这时候我们在针对服务做降级处理。

在保证单点写入的同时，我们利用主从同步、数据同步工具等手段，将私有云机房的数据实时同步至公有云机房，保证数据的一致性。若网络发生故障，数据同步暂时停止，将影响部分服务的可用性和可靠性，这时我们需要针对服务进行降级处理，待网络恢复后继续同步数据、恢复服务。