OPPO业务多活架构演进和实践

2.同城多活业务架构3.异地多活业务架构4.总结机房多、容易满,难于有效利用和扩展北京01北京02北京03广州01广州02广州03•-个微服务数百个实例•-个微服务需要访问数百个三方实例•-个微服务需要连接几十、上百个分库•-个MySQL被数百个实例连接•-个Redis集群上千个实例•。。。。。规模过大,架构复杂机机房1:100%容量机机房2:100%容量0%中心机机房1:100%容量机机房2:100%容量机机房3:100%容量300%三活单元化机房机房1:50%容量机房机房2:50%容量机房机房3:50%容量机房机房1:33%容量机房2:33%容量机房3:33%容量机房4:33%容量元化机房机房1:25%容量机房2:25%容量机房3:25%容量机房4:25%容量机房5:25%容量用户分片2用户分片1用户分片n用户分片2用户分片1用户分片n机房机房n2.同城多活业务架构3.异地多活业务架构4.总结•主线多活•保障多数用户•数据分类、应用不同的CAP模型•平台业务SDK化•数据最终-致•记录日志、流水,避免修改、计数操作RegistryRegistryAFAPIGatewaySSAZ1SSAFAPIGatewayAZ1RaftRaftRaftAZ1RaftRaftRaftMySQL5.7+toasource-ip域名解析生效时间太长,Anycast变更可以立即生效。AnycastAnycastMSSyncOrchestratorAZ32个slave成功MSMMSSMSMMSSMSRedirect:读写都是主机房ForwardMSMS客户端调用链外网拨测平台内网网络监控……始数据多活平台(青龙)机房故障,停止该机房所有IP解析运营商故障,停止故障线路解析POP点故障,停掉该POP点下的所有IP机房专线故障,只保留业务的数据层主机房流量接入层容量不足,7层自动扩容,4层切机房流量比例业务故障,切换机房、熔断、降级2.同城多活业务架构3.异地多活业务架构4.总结…………11•按用户分片,访问不同机房•机房内封闭调用•机房无限水平扩展•单元自身如何跨机房高可用2北方机房南方机房北方机房南方机房双向同步按用户单元进行调度,数据全量,用户只会访问其中-个机房,避免双向同步冲突。业务域名评论域名按地域划分用户单元,分流业务域名评论域名按地域划分用户单元,分流业务功Jins订阅2.按账号分单元3.按地域分单元adg:匿名设备分组aug:匿名用户分组2.2.客户端获取单元号客户端首次访问业务时,先调用单元划分服务,获取单元号,并保存在客户端。3.3.客户端解析域名IP通过单元号参数,获取IP列表,客户端根据环境(WIFI名称、运营商名称)缓存结每个单元分配-个域名,降级时也能保证解析的-致性。4.4.客户端重定向调度过程中,还有部分请返回新IP地址,客户端立即重试新IP,保证切换过程中数据的-致性。1.用户首次访问服务时分配单元号,保存在客户端。2.如果按地域划分单元,部分用户不是就近提供服务。3.为每一个单元分配一个域名,降级时依然能保证和HttpDNS相同。4.加载、分享H5页面使用单元域名,保证H5和APP的调度规则相同。7.数据层联动,业务可提供未同步用户清单,API网关禁止访问,不允许调度。业务请求失败1.连接错误2.响应错误2.过期后继续使用原IP,异步刷新API网关调度生效-致性1.客户端降级到传统DNS,解析到错误的机房。2.调用生效过程中,还有部分请求访问旧机房。比对单元归属机房,响应新IP,并行跑马,HttpDNS优先。副本模式:主主:读写本机房,双向同步主备:读写主库,自动切备库主从:写主库,读从库冷备:读写主库,从库冷备服务层副本模式:主主:读写本机房,双向同步主备:读写主库,自动切备库主从:写主库,读从库冷备:读写主库,从库冷备服务层跨同城AZ高可用1.1.按设备、账号分单元,包括登录和非登录用户2.单元包括多个副本3.每个副本都是全量数据4.副本位于不同机房服务层服务层适用非强-致业务适用于强-致业务gg机房3:机房4(同城多活)gg机房3:机房4(同城多活)e 读eg读egCenterZone:中心单元,部署运营管理、长尾应GIobaIZone:-不能按统-维度拆分-可以拆分但需要全量访问-核心业务单元化,划分用户单元-核心业务尽量自包含,封闭调用tt获取单元号参数,根据单元号筛选实tt获取单元号参数,根据单元号筛选实例获取单元号,全链路传递tProvider/server实例打上单元标签数据访问层Relay2PCRelay2PC源机房源机房SourceDBSourceDBJins数据传输服务、加密5.多消费者支持,减少数据库压力6.分离Store模块和ReIay模块,优化异地传输性能SourceDBSELECTBIT_XOR(CRC32(CONCAT(column1,column2,…)))aschecksumFROMYOUR_TABLEWHEREts>=xxxandts<yyy根据记录修改时间戳,比对前-个周期内所有记录CRCXOR总值是否-致,不-致再对比行记录。acheacheMySQL订阅—数据最终-致acheacheinloginloginloginloginloginlogmdidcidseqtimestamplogoffset2.同城多活业务架构3.异地多活业务架构4.总结1.主线多活,数据分类,应用不同的CAP模型-同城多活:应用层无状态,数据层主备(具备自动切换能力)。CP模型-同城多活:应用层无状态,数据层主从(从库提供读能力)。AP模型-异地双活:按用户单元调度,数据双向同步。AP模型-用户两级划分,按账号划分单元,单元包括多个副本。-副本可应用主主、主备、主从模式,适用不同的业