* 架构浅析
先来看一下asio的0层的组件图。
(图1.0)
io_object是I/O对象的集合，其中包含大家所熟悉的socket、deadline_timer等对象，主要功能是提供接口给用户使用。
services服务是逻辑功能的实现者，其中包含提供定时功能的deadline_timer_service、提供socket相关功能的win_iocp_socket_service(windows平台)/reactive_socket_service(其他平台)、作为io_service功能的真正实现者win_iocp_io_service(windows平台)/task_io_service(其他平台)等等服务。
"Asio核心组件"在这一层中可以理解为就是io_service，它通过关联的类service_registry将实现具体功能所需的服务组合起来，再由io_object提供接口给用户使用。
这三大组件构成了asio的核心架构，asio的一切都是以此为根基衍生扩展出来的。
让我们将图1.0进一步细化：
(图1.1)
“Asio核心组件”细化为4个类:io_service，service_registry，service，service_base。其中，service_registry负责管理所有服务，使用延迟创建技术，在真正使用服务对象的时候才创建服务对象，并以单链表的方式管理，但只能增不能删，直到service_registry析构时才会释放其管理的服务对象。service是io_service的类中类，是一个虚基类，所有由service_registry管理的服务都必须从service派生。service_base是service的直接派生类，是services继承体系的第二级，组合了service_id<Type>，目前asio中所有服务均继承与service_base。
“I/O对象”细化为basic_io_object及其派生类。basic_io_object是所有I/O对象的基类，提供I/O对象与其对应服务的联系。
再将图1.1进一步细化(关注网络I/O方面的一些类，其他方面的类未画出)：
(图1.2)
io_service的真正逻辑实现封装在内部桥接的类io_service_impl中，io_service_impl是一个typedef(在windows平台下是win_iocp_io_service，其他平台下是task_io_service)。io_service_impl就是一个继承于service_base的服务，在io_service初始化也就是其关联类service_registry初始化时被创建，再由io_service持有其引用。
从图中可以看到，继承于service_base的服务有：
strand_service：提供串行化多线程调用的功能
deadline_timer_service：提供定时器功能
stream_socket_service：提供流式socket相关功能
datagram_socket_service：提供报文式socket相关功能
seq_packet_socket_service：提供seq_packet socket相关功能
raw_socket_service：提供原始套接字相关功能
socket_acceptor_service：提供端口监听和接受客户端连接相关功能
这些服务都是幕后英雄，对于用户而言是感知不到的，用户使用的都是其对应的I/O对象。
这些服务对应的I/O对象是：
io_service::strand
basic_deadline_timer
basic_stream_socket
basic_datagram_socket
basic_seq_packet_socket
basic_raw_socket
basic_socket_acceptor
除此之外，asio中还有串口通信、信号处理等功能，在此不再一一赘述。
由于本文会实时根据读者反馈的宝贵意见更新，为防其他读者看到过时的文章，因此本系列专题谢绝转载！
boost.asio源码剖析(二) ---- 架构浅析