10-03 单元化架构设计

设计原则

透明

  • 对开发者透明
    在做实现时,不依赖于单元划分和部署
  • 对组件透明
    在组件运行时,不感知其承载单元
  • 对数据透明
    数据库并不知道为哪个单元提供服务

业务可分片

  • 系统业务复杂度足够高
  • 系统可以按照某一维度进行切分
  • 系统数据必须可以被区分

业务自包含

  • 同一业务功能必须在单元内完成
  • 同一业务操作所需数据也在该功能单元内
  • 尽量避免跨单元依赖

单元化设计三要素

在这里插入图片描述

系统切分

业务切分
  • DDD切分领域服务、数据和业务流程
    • 切分出的服务和数据属于同一单元
    • 出现交集(重叠)时,以单元间访问量做决策指标
  • 业务流程所需组件和数据划分在同一单元
    • 一个业务流程在同单元执行,保证性能和稳定性
    • 尽量避免跨单元的服务访问和数据库读写
    • 同单元高内聚,单元间低耦合
  • 与组织架构和核心业务流程强相关
    • 核心业务保证高可用,高增长必须单元化部署
    • 边缘业务跟随核心业务数据分配单元
  • 功能粒度要适当
    • 粗粒度单元,轻易超过单元资源承载上限,需要二次拆分
    • 细粒度单元,单元内资源浪费,性价比低
  • 开发团队随单元化架构调整
  • 整个过程要持续迭代
按用户属性切分
  • 用户属性对系统核心功能有决定性作用
    • 外卖、叫车、共享等业务严重依赖于用户的地域属性
    • VIP用户、大买家等不同类型的用户
  • 新建用户按规则自动分配单元,存量数据按规则做数据迁移
    • 相同属性的数据聚集在同一单元
    • 一个单元内完成系统所有核心业务,单元内不再按功能拆分
  • 数据ID规则
    • 不同单元同时生产数据,且数据有同步需求,ID必须保证跨单元不重复
    • 由ID可以按规则推算所属单元
  • 用户属性划分导致单元规模层次不齐
    • 过于庞大的单元,二次拆分
    • 合并多个小单元为一个常规单元
  • 当用户属性改变时、系统自动同步数据
    • 该类属性是低频变化
    • 系统同步速度高于属性变化速度
按数据切分
  • 按照数据某种属性进行单元划分
    • 无业务含义,不可更改,不重复,一般选ID或者时间戳
    • 水平扩展上限高
    • 账户、订单、流水、商户、商品等比较易于切分
    • 通过规则推算所属单元
  • 设计规则是数据均分
    单元分配的数据比例等于其整体流量比例
  • 无业务依赖,跨单元访问不可控
    引入中间件实现开发者透明
  • 无法切分的数据,高频访问,创建特殊附属单元
    • 该单元必须与切分单元在同一数据中心、机房,以降低访问延时
    • 任意切分单元对附属单元的写入都会同步到其他附属单元
    • 大部分系统都是写少读多,写复制的成本远低于高频读操作
    • 数据实时性要求高的系统可能会失败
  • 无法切分的数据,低频访问,系统共享同一单元
    • 低频读写,时延不影响主业务,代价可接收
    • 根据数据中心距离,选择与所有数据中心都相对最近的数据中心作为共享单元的部署地
  • 单元内部垂直切分
    单元瓶颈优秀考虑内部垂直切分
  • 综合库
    创建单独的综合库,同步汇总所有单元的数据,供非实时业务使用

单元组成的元素

  • 组件
    • 服务,业务逻辑
    • 不直接被单元外访问
    • 独立构建、发布
  • 数据
    仅限该单元数据
  • 中间件
    • 内部通信
    • 与单元路由有关的中间件
  • 反向代理
    • 单元内服务的反向代理服务器,供外部访问
    • 单元选择功能的路由器
    • 安全和控制策略的中心
  • 网关
    • 单元内访问外部服务的代理服务器
    • 单元选择功能的代理服务器

单元路由

外网访问
  • 为不同数据中心的不同单元分配不同域名
    • 建立全局路由规则服务
    • 或客户端登录后本地计算所属单元(或数据中心)
    • 客户端直接访问所属单元
  • 未改造客户端、匿名用户等
    • 利用公有云就近提供服务
    • 由业务服务设置Cookie标志指定所属单元
  • tag、Cookie或URL参数指定要访问单元
    公有云或CDN提供次服务
单元网关
  • 单元网关也是该单元的反向代理服务器
  • 单元网关根据规则计算请求所属单元
    • 属于当前单元,直接路由请求到正确的组件(服务)
    • 属于其他单元,转发到对应的正确单元并上报路由错误信息
    • 无法判定,根据路由规则发送给组件,由业务逻辑进一步分辨
应用层
  • 统一封装的开发框架处理请求,在拦截器或者过滤器层对开发者透明
    • 根据请求计算所属单元,属于本单元则继续处理
    • 不属于本单元则转发
    • 无法判定就交予业务逻辑层或数据库访问层来决定
  • 业务层
    • 普通对单元无感知的业务,按原有逻辑直接处理
    • 依赖于单元信息的业务,可以自行计算或从容器注入单元信息
中间件
  • 远程调用框架要透明化支持自动单元路由
    • RPC
    • HttpClient
    • 根据请求计算出正确的目标单元并自动路由
  • 数据访问层
    • 最后防线
    • 通过数据访问的驱动程序或框架改造,使其对开发者透明
    • 如果有误,将错误的访问路由到正确的数据库(或表)

数据复制

  • 单元化的数据为本单元组件服务
    • 依赖决定是否需要复制数据
    • 单元间互相复制
    • 通过数据中台复制
  • 根据业务场景选择
    • 强一致、最终一致
    • 最大数据延迟
    • 读写失败对业务的影响
  • 关系型数据库复制
    MySQL、Oracle
  • NoSQL数据库复制
    MongoDB、Redis
  • 消息中间件复制
    Kafka,RabbitMQ

实例

电商

在这里插入图片描述

外卖

在这里插入图片描述

  • 0
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值