微服务架构陷阱与挑战

微服务架构6大陷阱

现在微服务的基础设施还是越来越完善了，现在基础设施缺乏的问题逐渐被解决了。

拆分粒度太细，服务关系复杂

拆分降低了服务的内部复杂度，但是提升了系统的外部复杂度，服务越多，服务和服务之间的连接关系越混乱。

拆分粒度太细，团队效率下降

拆分粒度太细，问题定位困难

不是很好排查问题，链路太长了。

拆分粒度太细，系统性能下降

基本上接口间的调用（包含接口的业务逻辑执行完毕）,大概的耗时是50ms，以后估计链路的耗时，就按照这个估计就好了。

缺乏基础设施，无法快速交付

缺乏基础设施，服务管理混乱

微服务架构4大挑战

微服务架构示意

左边是微服务架构，右边是单体架构

主要区别有两个：服务的拆分和数据的拆分

微服务技术挑战

只拆分代码，不拆分数据库，算不算微服务?

不算。

BASE 理论之最终一致性

一致性是有时间的，看你业务的忍受程度

业务级分布式事务-本地事务消息

业务级分布式事务-消息队列事务消息

业务级分布式事务-TCC

全局幂等

全局幂等设计示例-正常处理1

B收到之后，先根据全局ID判断状态是不是done，如果是done就直接返回，如果不是就处理业务。

第4步如果处理业务成功后，更新消息状态失败，如何应对这种情况?

要用事务来保证，比如要同时成功。

全局幂等设计示例-正常处理2

B服务不需要先记录消息了，直接同时完成业务和消息的done写入，针对这个方案，如果2消息丢了，那么A服务重发就好了

接口兼容 和 接口循环调用

2这种方式是加if else，这样的风险会很高