異步化編程中聞名的Callback Hell，讓不少同學望而止步。當業務復雜的時候，各種call back互相嵌套，使代碼變得更加容易出錯和不易理解。業內也有有不少框架提供了異步化編程支持，有以下三個思路：

 

纖程

 

纖程可以認為是輕量級的用戶線程，脫離了OS的調度機制，在應用級別進行調度管理。由于它只維護了基本的執行棧信息，并不立即分配執行資源，因此，它可以輕松創建成千上萬的纖程(受內存大小的限制)，通過極少的線程完成對纖程的調度執行。這個方向的代表有微信團隊開源的libco，以及在語言層面上支持的Go語言等。libco hook了底層IO相關的系統函數，通過底層IO事件驅動纖程的調度執行。

 

當遇到同步調用網絡請求時，libco自動注冊回調監聽器，并讓出CPU。而在IO事件完成或者超時候，自動恢復纖程，然后調度執行。它的實現機制決定了它非常適合依賴耗時IO服務的實現。承載了微信千萬級調用的一個基石。不過遺憾的是，libco是一個高效的c/c++協程庫，并沒有在JVM上實現。

 

Quasar是在JVM之上實現了纖程機制，基本可以在Quasar的類庫基礎上，以同步的模式來編寫異步的代碼。在真正執行代碼前，通過編譯或者Instrument Agent的形式織入相關的字節碼。從頭起步引入纖程還是一個不錯的選擇。對現有項目的改造，需要對現有的線程類修改成纖程類，這需要改動我們底層非常多的中間件。另外業內公布的使用經驗較少，后續可以持續關注它的發展。

 

以上就是小編對于HTTP服務異步化如何實現的解答。