盡可能使用異步通信，而不是同步通信。服務(wù)和各個層之間的所有調(diào)用。使用程序設(shè)計語言專有的調(diào)用，確保發(fā)出了請求，且沒有在等待。同步詞用會使整個程序執(zhí)行停止來等待一個響應(yīng)，從而把所有的展務(wù)和各個層維系在一起，造成級聯(lián)性的故障。使用異步通信技術(shù)可以確保每個服務(wù)和層是獨立的，這樣系統(tǒng)的可擴展程度比所有部件都掲合在一起的系統(tǒng)大得多。

一般的異步調(diào)用，無論是在一個服務(wù)內(nèi)還是在兩個服務(wù)間，實現(xiàn)起來都比實現(xiàn)同步調(diào)用難得多。原因在于異步調(diào)用通常都需要通知最初發(fā)送消息的服務(wù)，告訴它請求已經(jīng)完成了。如果你發(fā)送完請求就不再理會，那就沒必要再與調(diào)用方法通信或協(xié)作了。實現(xiàn)這個的方法很多且很簡單，包括如下所示的PHP函數(shù)，它利用了符號在后臺運行進程。



但是，并非所有服務(wù)發(fā)出請求后就不再管它什么狀態(tài)了。通常，調(diào)用方法想知道被調(diào)用的方法是什么時候完成的。原因可能是在結(jié)果返回前發(fā)生了其他的處理?？梢栽O(shè)想一個電子商務(wù)平臺上的場景，即需要根據(jù)抵折扣代碼重新計算郵費。理想的情況是同步執(zhí)行這兩個任務(wù)，而不是計算郵費(可能需要調(diào)用供應(yīng)商的第三方法)，然后再對購物車中的物品處理折扣代碼。但在兩者都完成之前，我們不能把最終結(jié)果發(fā)送給用戶。
 
在大多數(shù)程序設(shè)計語言中有一種機制，是為母方法和被調(diào)用的異步子方法之間的協(xié)調(diào)和通信設(shè)計的，叫作回調(diào)。在C/C++語言中，這是通過函數(shù)指針實現(xiàn)的。在Java語言中，是通過對象引用實現(xiàn)的。有許多設(shè)計模式使用回調(diào)，如委托設(shè)計模式和觀察者設(shè)計模式。但是為什么要自找麻煩異步調(diào)用方法或服務(wù)呢?

我們之所以要自找麻煩進行異步調(diào)用，是因為如果采用同步調(diào)用，所有的方法、服務(wù)和層都會被維系在一起，它們中的任何一個運行放慢或出了故障，都會造成整個系統(tǒng)發(fā)生延遲的級聯(lián)故障。把所有部件串聯(lián)起來會導(dǎo)致故障成倍增長。我們只針對可用性討論了這一概念，但它其實也適用于每KLOC存在bug的概率。如果方法A、B和和C都有99.99%6的機會沒有bug，而且A方法同步地調(diào)用B方法，B方法同步地調(diào)用C方法，那么整個系統(tǒng)的邏輯流中有bug的概率就是99.99%×99.99%×99.9%=99.97%。

我們介紹過，根據(jù)不同的客戶，把系統(tǒng)的資源池劃分成獨立的泳道。這樣做的好處是如果一個泳道出了問題，不會術(shù)生到其他客戶的泳道，這可以將問題的影響最小化。此外，檢測故障也容易得多，因為同一個代碼右采用異步調(diào)用的模塊或方法也具有這種能力。

異步調(diào)用可以防止故障或運行減慢這種情況傳播，而且有助于在發(fā)生問題時確定bug在哪里。許多遇到過數(shù)據(jù)庫問題的人都在應(yīng)用或Web層見證過這一點，因為一個很慢的查詢使得連接受到阻礙堆積起來了，然后應(yīng)用服務(wù)器上的套接字一直保持打開狀態(tài)。數(shù)據(jù)庫的監(jiān)控系統(tǒng)可能不會發(fā)出故障信號，但應(yīng)用的監(jiān)控系統(tǒng)則會發(fā)出故障信號。這種情況是在應(yīng)用和數(shù)據(jù)庫服務(wù)器間使用了同步調(diào)用造成的，而且這種問題還很難診斷。
 
當然，不能對系統(tǒng)中所有方法和層之間的調(diào)用都使用異步調(diào)用，所以真正的問題是哪些調(diào)用應(yīng)該采用異步調(diào)用。在使用非異步調(diào)用時，應(yīng)該具有超時設(shè)置，能夠在同步調(diào)用的方法或服務(wù)失敗時，優(yōu)雅地處理錯誤或繼續(xù)進行處理。決定哪些調(diào)用可以采用異步模式的方法是基于下列標準分析每個調(diào)用。

外部API/第三方。調(diào)用的是第三方的方法或外部API嗎?如果是，那么一定要采用異步調(diào)用。調(diào)用外部方法可能出現(xiàn)的問題太多，所以不能采用同步調(diào)用。你一定不想讓自己的系統(tǒng)健康和可用性與你不能控制的系統(tǒng)緊密關(guān)聯(lián)在一起。

長時間運行的進程。要調(diào)用的進程是不是運行時間很長?運行的計算需求和1O需求是不是很高?如果是，最好采用異步調(diào)用。運行慢的進程是比停機更棘手的問題。

容易出錯的/頻繁更改的方法。調(diào)用的方法會頻繁更改嗎?修改的次數(shù)越多，代碼中有bug的可能性越大。不要把關(guān)鍵代碼和需要頻繁更改的代碼關(guān)聯(lián)在一起，否則會造成故障數(shù)量增加。

時間約束。當兩個進程間沒有時間約束時，考慮發(fā)出請求后就不再管什么狀態(tài)的子進程。這個場景可能是新注冊的用戶收到一封歡迎郵件。雖然系統(tǒng)關(guān)心郵件是否發(fā)送出去了，但不應(yīng)該等待郵件發(fā)送出去了才給用戶返回注冊頁面的結(jié)果。

對于決定網(wǎng)站制作是否使用異步調(diào)用來說，這只是幾條最重要的標準。我們把歸納所有標準作為練習(xí)留給讀者。雖然我們能再列出十條標準，但隨著列出標準的增多，它們可能更適用于特定的系統(tǒng)。另外，和你的開發(fā)團隊一起做這個練習(xí)，這會讓團隊中的每個人都注意到使用同步調(diào)用和異步調(diào)用的利弊，從而遵循本原則，更好地擴展系統(tǒng)。