广义上讲，内核本身就是一个服务器，为所有的用户模式进程提供服务，但是狭义上讲只有在真的有请求的时候内核采取的对策才叫做服务，比如注册-执行模式下的time以及hrtimer等等，用户空间的程序或者内核空间的执行绪可以随意注册一个timer之后就不管了，timer到期以后内核会执行之，这就相当于timer的创建者请求了内核的一项服务，就是执行timer，不光是这个，在内核中处处都是服务执行者，比如工作队列，软中断…我们可以看到的是，所有这些几乎都是使用一个全局的链表，服务的请求者创建请求之后只需要将请求插入这个全局的链表就可以了，而内核执行的方式往往是串行的执行，也就是遍历链表的请求，一个接一个的执行，这个服务方式和用户空间的大大不同。
在用户空间中，服务器的架构方式多种多样，比如多线程，多进程，消息映射等等，为何在内核不用这些方式呢？首先看一下用户空间的这些方式的机制是谁提供的，正是内核本身，内核是什么，现代的内核就是提供多个多线程的用户上下文，然而谁为内核提供这些机制呢？除非有了专有的硬件，这只是其一，另外，内核的原则就是怎样效率高就怎样，其实内核中也是可以创建线程的，比如内核线程，但是对一些小的请求创建一个线程将是一笔很大的开销，并且没有人为之买单，用户空间的每请求一线程的服务方式可以让内核进行优化，如果该操作系统实在不适合每请求一线程那么可以尝试使用多进程模型，apache的mpm就是这么做的，但是在内核中有必要搞得这么花哨吗？硬件几乎不会用不同的策略来适应软件，因此一切都要内核自己来权衡。在用户空间，并发量是不确定的，负载也不确定，确定的是峰值，比如再好的PC也不适合单独做web服务器，这是因为有系统内核和硬件在下面兜着呢，到了内核，一切变得没有了底线，如果谁触底了，那么这个系统内核将被淘汰，这样的情况对于硬件也是显然的，应用程序可以设计出自己独特的架构以适应需求，往往操作系统内核可以以不同的方式去提供这种支撑，如果内核本身也设计出了独特的架构，硬件往往不会委屈自己去适应内核，毕竟内核也是一个服务者，一切都要听应用的，顾客就是上帝，应用程序是终极顾客，虽然内核相对于硬件也是顾客，但是这个顾客的权力被应用程序削弱了很多。
有山就有路，有河就能渡。
