一种提高微服务架构的稳定性与数据一致性的方法（1）

look_w

微服务架构解决了很多问题，但是同时引入了很多问题。本文要探讨的是如何解决下面这几个问题。
有大量的同步 RPC 依赖，如何保证自身的可靠性？依赖的微服务调用失败了，我应该失败，还是成功。依赖很多外部服务之后，自身如何保障稳定性。如果所有依赖的服务成功，我才算成功，自身的稳定性就堪忧了。

RPC 调用失败，降级处理之后如何保证数据可修复？如果调用失败时，选择跳过。那么因此产生的数据不一致性问题如何修复？平时毛毛雨，可以忽略。但是大故障之后，人工还是要来擦屁股的，这个成本就特别高。使用消息队列的最大的意义是在让消息可以在故障的时候堆积起来，等故障恢复了再慢慢来处理，减少人工介入的成本。
消息队列是一个RPC主流程的旁路流程，怎么保证可靠性？依赖消息队列做系统解耦的时候，怎么确保消息自身是可靠入队列的？消息是否需要先可靠写入队列，然后再提交数据库事务？如果消息必须先写入队列，比如 kafka。但是 kafka 挂了怎么办？那我在线业务岂不被离线的队列给连累了？
消息队列怎么保持与数据库的事务一致？如果消息是先写入队列，然后数据库提交事务。那么就会有因为并发修改的情况下，数据库提交失败，但是消息已经写入到队列的情况。如果队列后面挂了奖励等业务流程，这个时候就会导致错发，或者要求奖励那边去再查一遍数据库的状态。但是如果先提交数据库事务，后写入队列，又无法严格保证队列里的消息是没有丢失的。
这些问题是所有混用了 RPC 和异步队列的业务都会遇到的普遍问题。这里我给一个提案来解决以上的所有问题。
同步转异步，解决稳定性问题在平时的时候，都是 RPC 同步调用。如果调用失败了，则自动把同步调用降级为异步的。消息此时进入队列，然后异步被重试。所以处理下游依赖就变成了三种可能性

• 完全强依赖，下游不能挂
• 因为我的返回值依赖了某个下游的处理结果，我必须同步调用它。但是不是强依赖，可降级。降级时不返回这部分的数据。同步调用降级时转为异步的。
• 完全异步化。下游服务只是消费我写入的队列，我不与之直接RPC通信