背景
不仅仅是因为现在微服务架构盛行，之前的服务之间协作进行通信也面临这样的选择，到底用同步的方式还是用异步的方式呢？这个基础性的选择会不可避免地引导我们使用不同的实现。
同步
使用同步方案，发起一个远程服务调用后，调用方会阻塞自己并等待整个操作的完成。
协作风格为请求/响应。即客户端发起一个请求，然后等待响应。
但是这个风格也适用于异步通信，如我可以发送一个请求，然后注册一个回调，当服务端操作结束后，调用该回调。
适用场景
- 极其关心调用结果
- 实现复杂的异步方案得不偿失
相关的架构风格
编排.png
这里首先说明一下，使用编排的架构风格不一定就是采取的请求/响应模式。但是基本情况会使用这种相应模式。
它的特征就是有一个服务作为中心大脑，由它来保证整套流程的运行。
然而缺点是，承担流程编排的服务作为中心控制点承担了太多的职责，它会成为网状结构的中心枢纽及很多逻辑的起点。这种方法就会导致出现少量的上帝服务，而与它打交道的那些服务会沦为贫血的、基于CRUD的服务。
相关技术
RPC
Remote Procedure Call 远程过程调用
核心特点是使用本地调用的方式和远程进行交互。即允许我们进行一个本地调用，但事实上结果是由某个远程服务器产生的。
优点
- 易于使用，大多RPC实现会帮助生成服务端和客户端的桩代码
缺点
- 开发人员混淆远程调用和本地调用，忽略对远程调用的优化
- 比较脆弱，很不适应修改且客户端和服务器的部署无法分离
REST
REpresentational State Transfer 表述性状态转移
REST本身没有提到底层应该使用什么协议，但是我们通常都是使用HTTP。
优点
- 客户端和服务端解耦
- 适用于大流量场景
缺点
- 因为客户端需要不断地发现链接、请求、再发现链接直到找到自己想要进行的操作，所以客户端和服务端通信的次数会比较多
- 需要自己实现HTTP客户端
- 性能相对Thrift（一种RPC技术）二进制协议相比会差很多
- 不能做到低延迟
异步
使用异步方案，调用方发出一个远程服务调用后，不需要阻塞等待操作的完成就可以返回。
协作风格为基于事件。即客户端不是发起请求，而是发布一个事件，然后期待其他的协作者接收到该消息，并且知道该怎么做。我们从来不告知任何人去做任何事情。基于事件的系统天生就是异步的。
整个系统都很聪明，业务逻辑并非集中存在于某个核心大脑，而是平均地分布在不同的协作者中。
基于事件的协作方式耦合性很低。
适用场景
- 远程任务运行时间比较的长
- 需要低延迟的情况
相关的架构风格
协同.png
协同服务的话如上图所示，可以仅仅由某个服务使用异步的方式触发一个事件。然后就会有相应的协作服务去做处理。这种方式可以显著的消除耦合，如果其他的服务也关心这个事件，简单地订阅这个事件就可以了。
然而它的缺点是不太容易的看到明显的业务流程视图，需要做一些额外的工作来监控流程，以保证其正确地运行。如构建一个与编排那张图所展现的流程相匹配额监控系统。实际的监控活动是针对每个服务的，但最终需要把监控到的结果映射到业务流程中。从而我们可以得知系统是如何运作的。
网友评论