SET架构演进

传统架构问题

容灾

• 核心业务挂掉，影响全网用户
• 数据库主库挂掉，无法切换和恢复

资源扩展

• 单个IDC无法满足，扩展IDC，存在跨机房时延
• 单点数据库主库，连接数有限，无法支持持续扩展

大集群拆分

• 集群规模扩大后会带来相应问题

同城双活

• 业务上双活，分别承担部分流量
• 存储上主从架构，会发生跨机房写
• 数据中心故障后，切换流量

两地三中心

• 在同城双活基础上，异地部署灾备数据中心

SET化

• 解决业务扩展、容灾等需求
• 形成通用解决方案，方便各业务线接入

SET架构策略

与微服务的区别：纵向切割，用户操作路线在一个机房内完成

流量路由

• 按照特殊key进行路由（userid等），判断请求该路由到中心还是单元集群

中心集群

• 未经过单元化改造的服务，不在核心交易链路，称为中心集群

单元化集群

• 每个单元化集群只负责本单元内的流量处理，以实现流量拆分和故障隔离
• 每个单元化集群前期只存储本单元产生的数据，后续会进行双向数据同步，实现容灾切换需求

中间件

• RPC

  SET服务，SET内调用

  非SET服务，沿用现有路由逻辑

• KV

  支持分SET数据生产和查询

• MQ

  支持分SET消息生产和消费

数据同步

• 全局数据部署在中心集群，其他单元化集群同步到本单元内

优势

• 异地容灾
• 高效本地服务，流量可以路由到最近的SET
• 集装箱式扩展，实现一键部署

可以跨SET调用，灵活容灾

SET架构原则

• 业务面透明
• 切分规则按需定制，优先最大维度切分(例如位置信息)
• 部署规范原则，单个SET尽量不跨地域，或过大集群

RabbitMQ的SET化实现

双活实现

插件设置成功

add upstream

add policy

于另外一个节点

从而实现数据同步

如果需要本地消费，再加一个新的队列

添加路由关系