微服务架构6大陷阱
现在微服务的基础设施还是越来越完善了，现在基础设施缺乏的问题逐渐被解决了。
拆分粒度太细，服务关系复杂
拆分降低了服务的内部复杂度，但是提升了系统的外部复杂度，服务越多，服务和服务之间的连接关系越混乱。
拆分粒度太细，团队效率下降
拆分粒度太细，问题定位困难
不是很好排查问题，链路太长了。
拆分粒度太细，系统性能下降
基本上接口间的调用（包含接口的业务逻辑执行完毕）,大概的耗时是50ms，以后估计链路的耗时，就按照这个估计就好了。
缺乏基础设施，无法快速交付
缺乏基础设施，服务管理混乱
微服务架构4大挑战
微服务架构示意
左边是微服务架构，右边是单体架构
主要区别有两个：服务的拆分和数据的拆分
微服务技术挑战
只拆分代码，不拆分数据库，算不算微服务?
不算。
BASE 理论之最终一致性
一致性是有时间的，看你业务的忍受程度
业务级分布式事务-本地事务消息
业务级分布式事务-消息队列事务消息
业务级分布式事务-TCC
全局幂等
全局幂等设计示例-正常处理1
B收到之后，先根据全局ID判断状态是不是done，如果是done就直接返回，如果不是就处理业务。
第4步如果处理业务成功后，更新消息状态失败，如何应对这种情况?
要用事务来保证，比如要同时成功。
全局幂等设计示例-正常处理2
B服务不需要先记录消息了，直接同时完成业务和消息的done写入，针对这个方案，如果2消息丢了，那么A服务重发就好了
接口兼容 和 接口循环调用
2这种方式是加if else，这样的风险会很高
