尽可能使用异步通信

发布：2018-07-22 17:08:02 浏览：3206

尽可能使用异步通信，而不是同步通信。服务和各个层之间的所有调用。使用程序设计语言专有的调用，确保发出了请求，且没有在等待。同步词用会使整个程序执行停止来等待一个响应，从而把所有的展务和各个层维系在一起，造成级联性的故障。使用异步通信技术可以确保每个服务和层是独立的，这样系统的可扩展程度比所有部件都掲合在一起的系统大得多。

一般的异步调用，无论是在一个服务内还是在两个服务间，实现起来都比实现同步调用难得多。原因在于异步调用通常都需要通知最初发送消息的服务，告诉它请求已经完成了。如果你发送完请求就不再理会，那就没必要再与调用方法通信或协作了。实现这个的方法很多且很简单，包括如下所示的PHP函数，它利用了符号在后台运行进程。

但是，并非所有服务发出请求后就不再管它什么状态了。通常，调用方法想知道被调用的方法是什么时候完成的。原因可能是在结果返回前发生了其他的处理。可以设想一个电子商务平台上的场景，即需要根据抵折扣代码重新计算邮费。理想的情况是同步执行这两个任务，而不是计算邮费(可能需要调用供应商的第三方法)，然后再对购物车中的物品处理折扣代码。但在两者都完成之前，我们不能把最终结果发送给用户。

在大多数程序设计语言中有一种机制，是为母方法和被调用的异步子方法之间的协调和通信设计的，叫作回调。在C/C++语言中，这是通过函数指针实现的。在Java语言中，是通过对象引用实现的。有许多设计模式使用回调，如委托设计模式和观察者设计模式。但是为什么要自找麻烦异步调用方法或服务呢?

我们之所以要自找麻烦进行异步调用，是因为如果采用同步调用，所有的方法、服务和层都会被维系在一起，它们中的任何一个运行放慢或出了故障，都会造成整个系统发生延迟的级联故障。把所有部件串联起来会导致故障成倍增长。我们只针对可用性讨论了这一概念，但它其实也适用于每KLOC存在bug的概率。如果方法A、B和和C都有99.99%6的机会没有bug，而且A方法同步地调用B方法，B方法同步地调用C方法，那么整个系统的逻辑流中有bug的概率就是99.99%×99.99%×99.9%=99.97%。

我们介绍过，根据不同的客户，把系统的资源池划分成独立的泳道。这样做的好处是如果一个泳道出了问题，不会術生到其他客户的泳道，这可以将问题的影响最小化。此外，检测故障也容易得多，因为同一个代码右采用异步调用的模块或方法也具有这种能力。

异步调用可以防止故障或运行减慢这种情况传播，而且有助于在发生问题时确定bug在哪里。许多遇到过数据库问题的人都在应用或Web层见证过这一点，因为一个很慢的查询使得连接受到阻碍堆积起来了，然后应用服务器上的套接字一直保持打开状态。数据库的监控系统可能不会发出故障信号，但应用的监控系统则会发出故障信号。这种情况是在应用和数据库服务器间使用了同步调用造成的，而且这种问题还很难诊断。

当然，不能对系统中所有方法和层之间的调用都使用异步调用，所以真正的问题是哪些调用应该采用异步调用。在使用非异步调用时，应该具有超时设置，能够在同步调用的方法或服务失败时，优雅地处理错误或继续进行处理。决定哪些调用可以采用异步模式的方法是基于下列标准分析每个调用。

外部API/第三方。调用的是第三方的方法或外部API吗?如果是，那么一定要采用异步调用。调用外部方法可能出现的问题太多，所以不能采用同步调用。你一定不想让自己的系统健康和可用性与你不能控制的系统紧密关联在一起。

长时间运行的进程。要调用的进程是不是运行时间很长?运行的计算需求和1O需求是不是很高?如果是，最好采用异步调用。运行慢的进程是比停机更棘手的问题。

容易出错的/频繁更改的方法。调用的方法会频繁更改吗?修改的次数越多，代码中有bug的可能性越大。不要把关键代码和需要频繁更改的代码关联在一起，否则会造成故障数量增加。

时间约束。当两个进程间没有时间约束时，考虑发出请求后就不再管什么状态的子进程。这个场景可能是新注册的用户收到一封欢迎邮件。虽然系统关心邮件是否发送出去了，但不应该等待邮件发送出去了才给用户返回注册页面的结果。

对于决定网站制作是否使用异步调用来说，这只是几条最重要的标准。我们把归纳所有标准作为练习留给读者。虽然我们能再列出十条标准，但随着列出标准的增多，它们可能更适用于特定的系统。另外，和你的开发团队一起做这个练习，这会让团队中的每个人都注意到使用同步调用和异步调用的利弊，从而遵循本原则，更好地扩展系统。