1. 数据库拆分:
①. 分库(垂直拆):a. 将用户、商品、订单拆分到不同的库.②. 分表(水平拆):a. 单表超过1亿的数据量了,需要考虑水平拆分了:(1). 如uid按照特定的算法,拆分为多张表.数据结构是一样的.
2. 微服务借鉴:
①. 场景:a. 商城有用户、商品、交易 、搜索几个功能.b. 数据库拆分原理的共性来驱动微服务拆分.②. 拆分的原则:a. 垂直拆分(以业务或API为基准).b. 水平拆分(以处理的功能为基准).
(1). 垂直拆分:
①. 业务关系分析:a. 用户可以发布和交易商品,是逻辑关系,不是物理关系.b. 业务功能垂直拆分,形成多个单体服务(4个服务).②. 以用户服务来说,垂直拆分力度够不够?a. 有注册(写请求)、登录、用户查询(查请求).b. 写的重要性肯定大于读,但是写的请求小于读,一般读写比例为10:1.c. 如果一个用户只是一个服务,如果读很大了,一定会影响写服务.d. 可以按照api再次进一步垂直拆分.(1). 写是一个服务、读是一个服务,这就是读写分离.③. 仅仅是垂直拆分是不够的,因为它只是多个单机,可以形成集群服务. => 水平拆分
(2). 水平拆分:
①. 以APP发起一个请求,分析请求生命周期:a. 网关服务层:(1). 不会做具体的业务逻辑.(2). 如通用参数的检查、请求的鉴权、协议转换、路由转换.b. 业务逻辑层:(1). 进行业务逻辑的处理.(2). 如微信的好友拉黑、拒收消息,不需要跟DB打交道.c. 数据访问层:(1). CURD的功能、屏蔽各种DB的差异性.d. DB②. 总结:a. 一层就是一个服务,这样就水平拆分成了网关层、业务逻辑层、数据访问层.b. 上面只是同步架构,还有异步架构.c. 这几个层都是无状态化的,目的是为了高可用.
