IO模型
io_service對象是asio架構中的排程器，所有異步io事件都是通過它來分發處理的（io對象的構造函數中都需要傳入一個io_service對象）。
asio::io_service io_service;
asio::ip::tcp::socket socket(io_service);
在asio架構中，同步的io主要流程如下：
應用程式調用IO對象成員函數執行IO操作
IO對象向io_service 提出請求.
io_service 調用作業系統的功能執行連接配接操作.
作業系統向io_service 傳回執行結果.
io_service将錯誤的操作結果翻譯為boost::system::error_code類型，再傳遞給IO對象.
如果操作失敗,IO對象抛出boost::system::system_error類型的異常.
而異步IO的處理流程則有些不同：
IO對象請求io_service的服務
io_service 通知作業系統其需要開始一個異步連接配接.
作業系統訓示連接配接操作完成, io_service從隊列中擷取操作結果
應用程式必須調用io_service::run()以便于接收結果
調用io_service::run()後,io_service傳回一個操作結果,并将其翻譯為error_code,傳遞到事件回調函數中
io_service對象
io_service對象主要有兩個方法——post和run：
post用于釋出io事件，如timer，socket讀寫等，一般由asio架構相應對象調用，無需我們顯式調用。
run用于監聽io事件響應，并執行響應回調，對于異步io操作需要在代碼中顯式調用，對于同步io操作則由io對象隐式調用（并不是run函數，不過也是等待io事件）。
可見，io_service提供的是一個生産者消費者模型。在異步io操作中需要我們手動控制消費者，調用run函數，它的基本工作模式如下：
等待io事件響應，如果所有io事件響應完成則退出
等待到io事件響應後，執行其對應的回調
繼續等待下一個io事件，重複1-2
從中可以看出，io_service是一個工作隊列的模型。在使用過程中一般有如下幾個需要注意的地方：
1. run函數在io事件完成後會退出，導緻後續基于該對象的異步io任務無法執行
由于io_service并不會主動常見排程線程，需要我們手動配置設定，常見的方式是給其配置設定一個線程，然後執行run函數。但run函數在io事件完成後會退出，線程會終止，後續基于該對象的異步io任務無法得到排程。
解決這個問題的方法是通過一個asio::io_service::work對象來守護io_service。這樣，即使所有io任務都執行完成，也不會退出，繼續等待新的io任務。
boost::asio::io_service io;
boost::asio::io_service::work work(io);
io.run();
2. 回調在run函數的線程中同步執行，當回調處理時間較長時阻塞後續io響應
解決這個問題的方法有兩種：1. 啟動多線程執行run函數（run函數是線程安全的），2. 新啟動一個線程（或通過線程池）來執行回調函數。一般來講，如果回調處理事件不是特别短，應該使用線上程池中處理回調的方式。
3. 回調在run函數的線程中同步執行，io事件較多的時候得不到及時響應
這個其實是性能問題了，在多核cpu上可以通過在多個線程中執行run函數來解決這一問題。這種方式也隻能充分利用cpu性能，本身性能問題就不是光靠軟體就能解決的。
.net中的異步io排程方式
和io_service這種手動控制的方式比起來，.net則是純粹的自動檔了。IO排程由CLR托管了，無需手動控制。回調也是線上程池中執行，無需擔心影響後續IO響應。
正是由于CLR的托管，在.net 的異步IO架構中，就沒有類似io_service的排程對象存在，這也符合.net的一貫簡潔做法。