《从程序员到架构师》笔记
书名有点大，其实书中更偏向于一些架构场景介绍，书中讲解了作者经历过的十几次架构设计，介绍了场景，技术选择以及相关的权衡。书很快就能读完，对我个人来说多少有些收获。
冷热分离
书中讲了一个很常见的场景：工单数量越来越多，查询变得很慢，工单的特点就是过了一段时间就会关闭，很少再次访问，所以他们的解决方案也很直接：增加一个归档的状态，将归档的数据存入另外一个数据库，并且增加一种新的查询方式。
我们的 Serviceless 系统中为什么没有这种问题？我们使用的是DynomDB 所有的查询都是基于索引，没有分页功能，可以想象根据索引定位指定数据记录，然后根据 SortKey 顺序获取数据，性能上不存在问题。
书中还提到了二期实现，将冷数据迁移到 Hbase，主要的考量是查询归档数据方式非常简单，只需根据邮箱或者工单ID。自己没使用过 Hbase 不过它是和 DynomDB 类似的产品，直接根据工单或者邮箱去建立全局索引就可以满足需求。
读写分离
与第一个场景相比，查询会很复杂灵活，工单的状态可能会发生变化。数据量非常大，考虑大数据需要借用查询引擎
- 触发 三种方式 业务代码中修改，日志变更触发
- 实现 异步更新，使用消息队列，标记数据
- 存储 ElasticSearch
- 查询
- 迁移
分库分表
针对海量数据存储的很常见的方案，在我的工作中使用的 NoSQL 没有这种问题。
中间件模式 Proxy 模式和 Client 模式
个人更倾向于 Proxy 模式，因为可以做到与业务逻辑解解耦。书中选择 Client 模式是想做的灵活可控，不增加新的一层影响运维。
选取用户 ID 作为分片主键，必需优先保障查询用户所有订单效率。
Hash 取模 每次 2 倍扩容，模数选 2^n
迁移： 日志记录写入消息队列，加入新库新表
全部迁移之后做校验，逐步切换
读缓存
场景是商品详情页几十条查询，耗时十几秒。
分布式缓存 Redis AWS 去年底推出 ElasticCache Serverless
- 缓存预热
- 恶意请求缓存击穿
- 缓存雪崩 大面积过期，随机过期
更新缓存
先更新再删除 或者 先删除再更新再删除
写缓存
举例场景是预约抢购
消息队列比较适合这种业务场景，书中设计有些麻烦，使用 Redis 批量写加定时
数据收集
场景是收集用户活动，进行数据分析
书中架构比较复杂，首先写入本地日志， Logstash 收集写入 Kafka，再选择实时计算框架写入持久层。
最主要就是讨论为什么不能直接写入 Kafka 简单来说就是异步数据可能丢失，同步写入必须牺牲性能。
服务发现
书中使用的是 zookeeper 没有使用 Dubbo 考虑到其它非 Java 服务 K8s 需要全部改动
微服务框架，spring cloud
很多不知道的服务
全链路日志
这应该只是追踪，使用的是 Sky walking
应该是自己部署的开源项目
熔断
首先并不是流量大才会导致熔断，目标服务响应时间过长，线程阻塞都会触发熔断。
书中给出的例子，比如某个服务接口，调用第三方接口，响应时间过长，占用了太多线程，导致其他服务不可用，比如缓存雪崩，导致数据库服务压力过大，所有的服务都会出现堵塞超时。
线程隔离
熔断
Hystrix
当前服务与其他服务有强依赖关系，每一个依赖都有一个隔离的线程池
在给定时间窗口调用次数超过阈值并且超时比例超过阈值。触发熔断 调用本地 Fallback
限流
讲秒杀的时候有提到限流，这一章主要讲限流算法：固定窗口，滑动窗口，漏桶，令牌桶。 漏桶就像名字一样，桶里能放就漏下去，放不下就流出去了。令牌桶比较灵活。
分布式还是统一限流，这儿选择分布式是考虑统一时 Redis 压力过大。
RateLimiter
这个场景很有意思，自己还没遇到过。
微服务
数据一致性
业务场景：下游服务失败上游如何处理
实时一致性 TCC
最终一致性 MQ
TCC try confirm cancel 太过麻烦
Seata AT 模式自动回滚
数据同步
微服务数据依赖问题
订单服务依赖商品服务 场景按商品名搜索订单，当然订单表可以扩展商品字段，问题是如何保障一致性问题。
Biforst 同步冗余数据库
BFF
这个前端就可以负责
后面开发运维场景就没有太深入了。Mock 接口有很简单的方案，支持简单逻辑的比如根据参数返回不同值，这个点没深入研究。
一人一套测试环境，我们现在每个任务都会创建一个完全独立的环境，因为 serviceless 很容易做到。这部分作者的情况是一些服务必须服用，所以不能整体重新部署一套环境，解决方案比较切合实际，个人以为这才是实际开发中经常遇到问题的解决方式。
总结
这本书对于后端同学来说可能比较简单，对我来说熔断限流是不曾接触过的，其它部分场景多少比较熟悉。
