有货双中心双活架构实践

总述

       随着有货业务不断发展，有货系统架构从原来LAMP一直发展到现在基于混合公有云的双中心双活架构；在双十一活动中，系统在十几倍高流量的冲击下运行稳定，用户体验流畅。

架构演进

1、 LAMP –> 分布式服务化 (成本、效率)

• A、 从LAMP到基于JAVA的分布式服务化：提升系统性能，开发效率提升
• B、 IDC迁移到公有云：降低设备成本，提升运维效率

2、单中心 –> 混合云双中心双活（高可用、容灾）

• A、弹性服务能力，避免活动高峰期间中心资源紧缺
• B、中心级灾备和高可用
• C、核心业务按用户维度进行拆分，关键业务在本中心完成，避免跨中心数据操作

有货双中心双活架构

1、 架构设计前的思考

A、哪些业务需要做到双中心双活

       理想情况下，用户所有业务都在指定中心完成，中心之间只需要数据同步，这种架构下数据同步也可以根据容灾级别，分别进行实时同步或离线同步。但要做到理想中的双活架构，系统中所有数据都需要进行单元化，这对于运行较长时间，数据已经大量积累的系统来讲，难度和成本都是极大的挑战。

       基于有货现有业务场景分析，实现电商核心购物流程(注册、登录、浏览、购物车、下单业务)的双活是成本最小，收效最大的方案。实际落地时，在注册、登录、库存场景中，仍然使用主从方案，后续章节有具体分析。

B、数据单元化拆分

       单元化是双活架构的核心，一般来说，单元化有按用户维度、功能维度以及用户功能结合三种方式。
有货双活架构的核心目标为实现核心购物流程的双中心双活，采用基于用户维护进行单元化。

2、有货双中心双活架构

前端：

• a.通过自建问询服务器实现双中心分流，根据uid拆分策略将用户引导到各自中心，两个中心同时提供服务。
  
• b.使用HttpDNS，解决LocalDNS缓存问题，防止DNS劫持。
  
  入口层：
  
• a.使用动态CDN，提升服务QoS。
  
• b.自研分布式服务框架，服务注册、发现与治理自动化
  
  服务层：
  
• a.自研分布式服务框架，服务注册、发现与治理自动化。
  
• b.用户信息、订单、优惠券相关数据库、表实现数据库拆分，实现用户登录、浏览、购物车、下单等核心流程在本中心内完成。
  
• c.非关键业务使用数据库跨中心主备方式，从中心通过专线跨中心写入。
  
• d.双中心间通过MQ Fedration插件实现消息跨中心复制，实现业务层跨中心数据同步(用户session、订阅、收藏等数据)。
  
  数据层：
  
• a.前台服务统一通过分布式数据中间件(cobar)接入mysql， 由cobar实现读写分离和分库分表，两个中心cobar通过配置中心(ConfigureCenter)获取配置
  
• b.各中心内数据库采用MySQL Master-Slave架构，通过MHA进行故障切换
  
• c.中心间使用MySQL主主复制进行同步。
  
• d.非核心数据库(晒单、商品咨询、意见反馈、社区回复、点赞信息)主中心master可写，从中心服务通过专线跨中心写主中心master。
  
• e.用户信息、订单、优惠券业务相关表基于用户维度进行拆分，两中心各承担一半业务数据。
  

双活架构 - 重点流程分析

1、用户注册/登录流程

       由于历史原因，当前用户profile表中存在较多的多个uid归属同一用户的情况，这对profile表拆分造成较大困难。因profile表一旦拆分到双中心，会造成用户登录时匹配不到真实uid的情况； profile涉及用户注册和登录，相关业务采用如下流程：

- a.提供用户注册信息保存和用户session保存API， UIC服务通过DNS从公网访问该API， API支持强会话、独立签名验证以保障接入安全。

• b.双中心同时提供保存API并能够立即提供服务，当前哪个API提供服务由DNS配置指定。

2、库存服务流程

       库存服务目前为商品库存、优惠券领取数量，由于涉及原子操作，双中心拆分实现在当前优势不明显，目前暂时使用主中心写入，再同步到从中心方案。





       同登录注册API一样， 库存操作API需要使用强会话、独立的安全校验，以保证接入安全。

3、推荐服务架构

       推荐服务不进行双中心部署，当前架构中，实时推荐数据通过MQ Federation机制将推荐数据发到两个中心，前台推荐服务接收到消息后，将消息缓存到redis。离线推荐数据在凌晨计算完成后直接写入本中心redis，然后通过脚本同步到另一中心。

4、前后台接口架构

       后台系统与前台服务存在MQ和API调用接口，业务基本为状态通知或后台手工发起的修改操作，接口调用频次低，数据量较小。
后台为双中心主备架构，当前未进行双中心拆分； 前台服务拆分后，cobar层仍支持跨中心写，业务流程如下图：

有货双活架构-容灾

支持中心级故障容灾，一切皆可故障：

架构落地中典型问题

1、订单号生成

       数据单元化后订单号不能简单使用数据库序列，数据库切换时可能导致数据冲突使得数据冲突。
       业内有较好的分布式id生成方案，如UUID、snowflake算法等；有货现有订单号使用全数据，长度较小，因此当前采用中心编号+uid分库信息+数据库序列号。

2、跨中心数据库切换中数据同步问题

       当故障发生需要将主库切换到另一中心时，需要检测数据同步是否完成；否则在切回时会出现数据丢失，这会造成故障时切换时间延长；根据双中心间数据同步时延，一般会有几十~100ms。

3、数据库切换后如何及时更新配置

       有货使用分布式数据中间件cobar进行数据主从和分库分表，在双活架构下，我们对cobar进行部分定制，数据库配置放到配置中心；配置中心支持subscribe/notify机制，当数据库切换时，修改配置中心中数据库配置，可以及时通知cobar更新配置。