从程序员到架构师
2023-10-25 12:40:32 8 举报《从程序员到架构师》的读书笔记
作者其他创作
大纲/内容
现学先用
需求评审时间——>接口设计时间——>开发完成时间——>联调完成时间——>测试完成时间——>上线时间
第1部分 数据持久化层场景实战
第1章 冷热分离
第2章 查询分离
第3章 分库分表
第2部分 缓存层场景实战
第4章 读缓存
第5章 写缓存
第6章 数据收集
第7章 秒杀架构
第3部分 基于常见组件的微服务场景实战
第8章 注册发现
第9章 全链路日志
第10章 熔断
第11章 限流
第4部分 微服务进阶场景实战
第12章 微服务的痛：用时机经历告诉你它有多少陷阱
微服务好处
12.3微服务痛点
微服务职责划分
微服务力度拆分
没人知道系统整体架构的全貌
重复代码多
耗费更多的服务器资源
12.3.6分布式事务
解决方案在第13章 14章
12.3.7 服务之间的依赖
循环依赖问题
理清上游接口：容易遗漏
旧的不下，新的上一个v2：很多版本存在，很难管理
子主题
12.3.8 联调的痛苦
沟通效率低，每个组的优先级不一样
12.3.9部署上的难题
服务太多，本地无法全部跑起来，需要有个联调的环境
联调环境数据缺漏非常多
服务调用错误
联调环境极度不稳定
只能作为部分接口的联调
第13章 数据一致性
1. 实时数据不一致可以接受，到那时要保证最终数据一致
1）每个步骤完成后，生产一条消息给MQ，告知下一步处理接下来的数据。
2）消费者收到这条消息，将数据处理完成后，与步骤1）一样触发下一步。
3）消费者收到这条消息后，如果数据处理失败，这条消息应该保留，直到消费者下次重试
2）消费者收到这条消息，将数据处理完成后，与步骤1）一样触发下一步。
3）消费者收到这条消息后，如果数据处理失败，这条消息应该保留，直到消费者下次重试
2. 必须保证实时一致性
实时一致性其实就是常说的分布式事务。MySQL其实有一个两阶段提交的分布式事务方案MySQL XA，但是该方案存在严重的性能问题。比如，一个数据库的事务与多个数据库间的XA事务性能可能相差10倍
3. TCC模式
在TCC模式中，会把原来的一个接口分为Try接口、Confirm接口、Cancel接口
1）Try接口：用来检查数据、预留业务资源。
2）Confirm接口：用来确认实际业务操作、更新业务资源。
3）Cancel接口：是指释放Try接口中预留的资源。
2）Confirm接口：用来确认实际业务操作、更新业务资源。
3）Cancel接口：是指释放Try接口中预留的资源。
4. seata 中 AT 模式的自动回滚
第14章 数据同步
14.1 业务场景：如何解决问服务之间的数据依赖问题
14.2 数据冗余方案
1. 每次数据更新，调用数据冗余的服务进行更新操作
2. 通过消息的发布订阅，服务各自更新需要更新的数据
14.3 解耦业务逻辑的数据同步方案
实时同步数据和表结构到多个服务
查询的时候可以直接查询
不允许修改其他服务的表
14.4 基于Bifrost的数据同步方案
支持5点的开源中间件
支持实时同步
支持增量同步
不用谢业务逻辑
支持mysql之间同步
活跃度高
注意事项
数据同步的延时
同步过来的数据是只读的
监控一定要到位
核心逻辑不依赖数据同步
同步的数据有延时，不推荐
比如权限，超卖
第15章 BFF
子主题
第5部分 开发运维实战场景
第16章 接口的mock
mock服务设计
1. mock 接口支持返回动态字段
2. 支持一些简单的逻辑，比如根据输入参数走不同的逻辑
3. 支持回调
4. 支持规则校验
5. 支持文档接口导入
第17章 一个一套测试环境
每个服务请求都带上一个channelID，网关根据channelID去请求不同的服务
隔离
后天服务隔离
redis、redis隔离
配置隔离
用环境变量来覆盖配置中心的值
0 条评论
下一页
