最近看了一个技术分享的视频《百万级并发商品服务架构解密》, 演讲者来自 网易考拉的丁鸣亮, 感觉讲的还不错, 根据内容简单整理如下(商品详情案例):
针对不同平台数据需求定制不同的接口详情, 减少各大端的彼此互相依赖、影响
商品基本数据可以通过商品服务异构到应用服务, 即使商品服务宕机也不影响基础的商品访问, 异构方式可以使用 MQ、binlog 等形式进行.
商品动态数据可通过实时查询 商品服务 返回最新的数据.
商品附属数据非核心功能, 关键时刻可选择降级数据.
以上我们通过数据的划分实现了 动静分离、核心数据与非核心数据区分, 当然商品基础数据异构到应用层做缓存的方式是否合理, 好处是响应的提升、容灾、减少网络的消耗, 但换来的是增加了数据的冗余, 牺牲了服务的边界划分. (当然也可以有选择性的对热点商品进行异构缓存).
商品详情三级缓存:
借用 cpu 的三级缓存概念, L1对于商品预见性预热到 local cache, L2 对于真实用户热点数据刷到本地. L3 一般为 redis、memcache 缓存使用.
服务灰度上线
Consumer端:
捕获被调用方异常, 平滑处理错误, 防止异常蔓延
设置合理超时时间, 服务降级, 防止服务崩溃异常蔓延
代码层做非核心服务兼容, 对开关进行测试, 禁止真正发生问题后开关失效.
Provider端:
没有流控感觉就像在裸奔, 之前有个案例是突然服务全部不能用, 导致服务完全不能用, 最后排查原来是因为某条 sql 没用到索引, 然而当时高峰期却束手无策, 如果能有根据负载情况流控方案, 也不会出现全线崩溃。
减少核心业务的入侵 进行解耦
分清主次
解决循环依赖
举例: 我服务慢因为的调用了你的服务, 你的服务慢因为调用他的服务, 他的服务慢因为其中有个数据调用了我的服务
明确服务边界, 保持干净.