1.3 网络编程模型与服务治理
服务治理和服务划分密不可分。服务之间既然进行了划分，那么服务之间就要进行通信。当今服务整个链路中最耗时的不是链路节点本身，而是节点间的通信。理解网络编程模型可以更好的进行服务治理。
网络编程模型的选择与服务治理关心的性能指标，各种参数的配置，维护的上下游之间是怎样的关系都密切相关。
1.3.1 网络模型的分类
偶尔自己炖个汤，一条活鱼分成几个部分，头部用来炖汤。将鸡切块配上豆腐，冬瓜等时蔬入锅葱姜一起先炒后加水炖，只放水豆豉，不放其他调料。将鱼头放入笊篱中，入锅一起炖，千滚豆腐万滚鱼，炖到鱼头烂入锅中，将笊篱中剩下的鱼骨拿出即可。
世界上最遥远的距离是鱼与飞鸟的距离，一个翱翔天际，一个却深潜海底。我却偏偏想让它们在一起。
大家可能直觉的认为服务治理是一个更为宏观的概念，与网络模型的概念，和鱼和飞鸟一样风马牛不相及。其实服务治理很大方面是要处理服务与服务的衔接和通信。了解网络编程模型对服务治理有重大意义。
在Java支持异步I/O之前的很长一段时间里，高性能服务端开发领域一直被C++和C长期占据。
先来看看UNIX网络编程对I/O模型的分类，UNIX提供了5种I/O模型。
1. 阻塞I/O模型
最常用的I/O模型就是阻塞I/O模型，缺省情形下，所有文件操作都是阻塞的。我们以套接字接口为例来讲解此模型：在进程空间中调用recvfrom，其系统调用直到数据包到达且被复制到应用进程的缓冲区中或者发生错误时才返回，在此期间一直会等待，进程在从调用recefrom开始到它返回的整段时间内都是被阻塞的，因此被称为阻塞I/O模型。
2. 非阻塞I/O模型
recvfrom从应用层到内核时，如果该缓冲区没有数据的话，就直接返回一个EWOULDBLOCK错误，一般都对非阻塞I/O模型进行轮询检查这个状态，看内核是不是有数据到来。
3. I/O复用模型
Linux提供select/poll，进程通过将一个或多个fd传递给select或poll系统调用，阻塞在select操作上，这样select/poll可以帮我们侦测多个fd是否处于就绪状态。select/poll是顺序扫描fd是否就绪，而且支持数量有限，因此它的使用受到了一些制约。Linux还提供了一个epoll系统调用，epoll使用基于事件驱动方式代替顺序扫描，因此性能更高。当有fd就绪时，立即回调函数rollback。
4. 信号驱动I/O模型
首先开启套接口信号驱动I/O功能，并通过系统调用sigaction执行一个信号处理函数（此系统调用立即返回，进程继续工作，它是非阻塞的）。当数据准备就绪时，就为该进程生成一个SIGIO信号，通过信号回调通知应用程序调用recvfrom来读取数据，并通知主循环函数处理数据。
5. 异步I/O
告知内核启动某个操作，并让内核在整个操作完成后（包括将数据从内核复制到用户自己的缓冲区）通知我们。这种模型与信号驱动模型的主要区别是：信号驱动I/O由内核通知我们何时可以开始一个I/O操作；异步I/O模型由内核通知我们I/O操作何时已经完成。
再来整理一下这五种网络编程模型。
根据不同的业务场景和技术发展水平，选择合适的网络编程模型。模型的不同，会涉及性能不同的网络闪断、客户端重复接入，客户端安全认证，消息编解码查看，半包读写等情况。生产环境中发生问题，往往会导致跨节点的服务调用中断，严重的可能会导致整个集群环境都不可用，这些都是服务治理要考虑的问题。
