《百万级并发商品服务架构解密》读后总结

开篇

最近看了一个技术分享的视频《百万级并发商品服务架构解密》, 演讲者来自 网易考拉的丁鸣亮, 感受讲的还不错, 根据内容简单整理以下.

业务概念划分

1. 商品详情模块

• app 商品详情
• pc 商品详情
• wap 商品详情

针对不一样平台数据需求定制不一样的接口详情, 减小各大端的彼此互相依赖、影响

2. 商品通用模块

• sku
• 品牌
• 分类
• 当前售价
• 库存

3. 商品附属模块

• 活动标签
• 利益标签

数据概念划分

1. 商品基本数据

• property
• sku
• goods

商品基本数据能够经过商品服务异构到应用服务, 即便商品服务宕机也不影响基础的商品访问, 异构方式可使用 MQ、binlog 等形式进行.

2. 商品拓展数据

• 品牌
• 分类
• 所在仓库

3. 商品动态数据

• 当前价格
• 库存
• 满减|折扣

商品动态数据可经过实时查询 商品服务 返回最新的数据.

4. 商品附属数据

• 标签

商品附属数据非核心功能, 关键时刻可选择降级数据.

以上咱们经过数据的划分实现了 动静分离、核心数据与非核心数据区分, 固然商品基础数据异构到应用层作缓存的方式是否合理, 好处是响应的提高、容灾、减小网络的消耗, 但换来的是增长了数据的冗余, 牺牲了服务的边界划分. (固然也能够有选择性的对热点商品进行异构缓存).

三级缓存的预案

商品详情三级缓存:

1. L1缓存: 主动刷新热点商品 (local cache) 失效 5 min
2. L2缓存: 被动刷新被访问的商品 (local cache) 失效 1min
3. L3缓存: 全量的商品 失效7天

借用 cpu 的三级缓存概念, L1对于商品预见性预热到 local cache, L2 对于真实用户热点数据刷到本地. L3 通常为 redis、memcache 缓存使用.

服务稳定性提高:

服务灰度上线

Consumer端:

• 服务调用的二次封装

捕获被调用方异常, 平滑处理错误, 防止异常蔓延

• 服务调用的超时时间

设置合理超时时间, 服务降级, 防止服务崩溃异常蔓延

• 服务关停演练

代码层作非核心服务兼容, 对开关进行测试, 禁止真正发生问题后开关失效.

Provider端:

• 接口设置流控(限流,防止某服务调用异常影响其它Consumer)
• 按客户端设置流控
• 动静分离

没有流控感受就像在裸奔, 由于没有 流控、降级 致使服务彻底不能用, 最后排查原来是由于某条 sql 没用到索引, 若是有根据负载状况流控, 也不会出现这么大的损失。

减小核心业务的入侵 进行解耦

分清主次

解决循环依赖

举例: 我服务慢由于的调用了你的服务, 你的服务慢由于调用他的服务， 他的服务慢由于其中有个数据调用了个人服务

结语

明确服务边界, 保持干净.