从程序员到架构师

需求评审时间——>接口设计时间——>开发完成时间——>联调完成时间——>测试完成时间——>上线时间

现学先用

第1章 冷热分离

第2章 查询分离

第3章 分库分表

第1部分 数据持久化层场景实战

第4章 读缓存

第5章 写缓存

第6章 数据收集

第7章 秒杀架构

第2部分 缓存层场景实战

第8章 注册发现

第9章 全链路日志

第10章 熔断

第11章 限流

第3部分 基于常见组件的微服务场景实战

微服务好处

微服务职责划分

微服务力度拆分

没人知道系统整体架构的全貌

重复代码多

耗费更多的服务器资源

解决方案在第13章 14章

12.3.6分布式事务

理清上游接口：容易遗漏

旧的不下，新的上一个v2：很多版本存在，很难管理

循环依赖问题

子主题

12.3.7 服务之间的依赖

沟通效率低，每个组的优先级不一样

12.3.8 联调的痛苦

联调环境数据缺漏非常多

服务调用错误

只能作为部分接口的联调

联调环境极度不稳定

服务太多，本地无法全部跑起来，需要有个联调的环境

12.3.9部署上的难题

12.3微服务痛点

第12章 微服务的痛：用时机经历告诉你它有多少陷阱

1）每个步骤完成后，生产一条消息给MQ，告知下一步处理接下来的数据。2）消费者收到这条消息，将数据处理完成后，与步骤1）一样触发下一步。3）消费者收到这条消息后，如果数据处理失败，这条消息应该保留，直到消费者下次重试

1. 实时数据不一致可以接受，到那时要保证最终数据一致

实时一致性其实就是常说的分布式事务。MySQL其实有一个两阶段提交的分布式事务方案MySQL XA，但是该方案存在严重的性能问题。比如，一个数据库的事务与多个数据库间的XA事务性能可能相差10倍

2. 必须保证实时一致性

1）Try接口：用来检查数据、预留业务资源。2）Confirm接口：用来确认实际业务操作、更新业务资源。3）Cancel接口：是指释放Try接口中预留的资源。

在TCC模式中，会把原来的一个接口分为Try接口、Confirm接口、Cancel接口

3. TCC模式

4. seata 中 AT 模式的自动回滚

第13章 数据一致性

14.1 业务场景：如何解决问服务之间的数据依赖问题

1. 每次数据更新，调用数据冗余的服务进行更新操作

2. 通过消息的发布订阅，服务各自更新需要更新的数据

14.2 数据冗余方案

实时同步数据和表结构到多个服务

查询的时候可以直接查询

不允许修改其他服务的表

14.3 解耦业务逻辑的数据同步方案

支持实时同步

支持增量同步

不用谢业务逻辑

支持mysql之间同步

活跃度高

支持5点的开源中间件

数据同步的延时

同步过来的数据是只读的

监控一定要到位

同步的数据有延时，不推荐

比如权限，超卖

核心逻辑不依赖数据同步

注意事项

14.4 基于Bifrost的数据同步方案

第14章 数据同步

第15章 BFF

第4部分 微服务进阶场景实战

1. mock 接口支持返回动态字段

2. 支持一些简单的逻辑，比如根据输入参数走不同的逻辑

3. 支持回调

4. 支持规则校验

5. 支持文档接口导入

mock服务设计

第16章 接口的mock

每个服务请求都带上一个channelID，网关根据channelID去请求不同的服务

后天服务隔离

redis、redis隔离

用环境变量来覆盖配置中心的值

配置隔离

隔离

第17章 一个一套测试环境

第5部分 开发运维实战场景

从程序员到架构师