分布式服务架构(原理、架构、实践)笔记

反模式

永远不要在本地事务中调用远程服务, 在这种场景下如果远程服务出现了问题, 则会拖长事务, 导致应用服务器占用太多的数据库连接, 让服务器负载迅速攀升, 在严重的情况下回压垮数据库。

NOSQL

nosql完全不适合交易场景， 主要用来做数据分析、ETL、报表、数据挖掘、推荐、日志处理、调用链跟踪等非核心交易场景。

最终一致性

使用定时任务捞取未执行完的任务，继续执行未执行完的任务，知道执行完成，或者取消已经完成的部分操作并回到原始状态。

查询模式

任何服务操作都需要提供一个查询接口，用来向外部输出操作执行的状态。服务操作的使用方可以通过查询接口得知服务操作执行的状态，然后根据不同的状态来做不同的处理操作。

补偿模式

为了让系统最终达到一致状态而做的努力都叫做补偿。
自动恢复：程序根据发生不一致的环境，通过继续进行未完成的操作，或者回滚已经完成的操作来自动达到一致状态。
通知运营：如果程序无法自动恢复，并且设计时考虑到了不一致的场景，则可以提供运营功能，通过运营手动进行补偿。

异步确保模式

异步确保模式是补偿模式的一个典型案例，经常应用到适用方对响应时间要求不太高的场景中，通常把这类操作从主流程中摘除，通过异步的方式进行处理，处理后把结果通过通知系统通知给使用方。

定期校对模式

在操作主流程中的系统间执行校对操作，可以在事后异步地批量校对操作的状态，如果发现不一致的操作，则进行补偿。一般在金融系统中使用。

可靠消息模式

在分布式系统中，对于主流程中优先级比较低的操作，大多采用异步的方式执行，为了让异步操作的调用方和被调用方充分解耦，我们通常通过消息队列实现异步化。

缓存一致性模式

读的顺序是先读缓存，后读数据库，写的顺序要先写数据库， 后写缓存。

接口异步调用模式

服务1请求服务2受理某项任务，服务2受理后即刻返回给服务1其受理结果，如果受理成功，则服务1继续做其他任务，而服务2异步地处理这项任务，直到服务2处理完这项任务后，才反向地通知服务1任务已经完成，服务1再做后续处理。
接口异步调用模式适用于非核心链路上负载较高的处理环节，这个环节经常耗时较长，并且对时效性要求不高。

消息队列异步处理模式

服务1将某种事件传递给服务2，而不需要等待服务2返回结果。在这种场景下，服务1与服务2可以充分解耦，此种模式适用于服务的上游不关心下游的处理结果，下游也不需要向上游返回处理结果。