尽可能应用异步通讯，而不是同步通讯。办事和各个层之间的所有挪用。应用法式设计说话专有的挪用，确保发出了要求，且没有在期待。同步词用会使全部法式履行停滞来期待一个响应，从而把所有的展务和各个层维系在一路，造成级联性的故障。应用异步通讯技巧可以确保每个办事和层是自力的，如许体系的可扩大水平比所有部件都掲合在一路的体系年夜得多。

一般的异步骤用，无论是在一个办事内照样在两个办事间，实现起来都比实现同步骤用可贵多。原因在于异步骤用平日都须要通知最初发送新闻的办事，告知它要求已经完成了。假如你发送完要求就不再理会，那就没需要再与挪用办法通讯或协作了。实现这个的办法许多且很简略，包含如下所示的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的可能性越年夜。不要把症结代码和须要频仍更改的代码联系关系在一路，不然会造成故障数目增长。

时光束缚。当两个过程间没有时光束缚时，斟酌发出要求后就不再管什么状况的子过程。这个场景可能是新注册的用户收到一封迎接邮件。固然体系关怀邮件是否发送出去了，但不该该期待邮件发送出去了才给用户返回注册页面的成果。

对于决议网站制造是否应用异步骤用来说，这只是几条最主要的尺度。我们把归纳所有尺度作为演习留给读者。固然我们能再列出十条尺度，但跟着列出尺度的增多，它们可能更实用于特定的体系。别的，和你的开辟团队一路做这个演习，这会让团队中的每小我都留意到应用同步骤用和异步骤用的利弊，从而遵守来源根基则，更好地扩大体系。