从操作系统机制浅谈服务器及服务平台方案的选择
在做一个系统分析及方案架构选择时，很多人常会说我选择linux作为服务器是当然，为什么当然呢？为什么不选择windows server呢？我试着从简单个人的角度去理解描述它。个人浅见，抛砖引玉一下。
先从网上抄点市场数据吧（未经证实），当然这些数据最终形成，不一定完全是纯技术的原因，更多是商业市场方面的原因，说简单点就是出于利益等原因，但我们做过简单的用户，我们只能接受适应，呵呵当然，有时还能发发牢骚。
Linux诞生，开发，发展于网络，所以对网络应用的支持度是与生俱来的，集群，分布式都是他（如果算上Unix）率先实现支持的，在服务器OS占有量超过75%，国际TOP500的服务器91.8%使用Linux系的操作系统Windows发迹于个人桌面系统，真正的Server始于2000，系统消耗的性能比较大（其实大不了多少，随着技术发展，微软开始在server上做了更多的努力，现在额外性能消耗已没有以前多了,呵呵），安全性方面也差于Linux（部分原因是由于windows黑客数量多，所以不能过于冤枉它，呵呵）。
一，从性能调优方来考虑：
对高并发及海量数据的服务平台，性能都是不断优化调整出来的。而不是什么的高超的架构设计就能一步到位的。
linux: 远远胜出，因为linux是方便调优的，方便定制，可以完全针对机器的配置设置优化，也可针对你所要创建的服务特点来优化。
Windows:首先内在支持消耗一定的资源比如在Windows下，gui是在内核态运行的（参见Windows Internals)你是无法不要它的，呵呵，其实是对于常用的系统操作的支持而提供过多，不容易调整的功能及模块。当然如果你是微软的高级的开发人员，你完全可以做到非常到全的系统调优，但可惜的，这些人都不在你的公司，同时你从人力资源市场上批量获得此类人才的可能性为零。
二，IO
我们这里不讨论一般的IO模型，我们只讨论一些操作系统中面向高并发高吞吐量的所用的IO模型进行讨论
Linux 的IO模型为：
1.select /poll
基本上就是轮询机制来查看每个IO句柄有无读写数据，不足很明显：
1024句柄限制，当然有办法进行调整。
用户空间的轮询机制消耗过多不必要的资源，消耗会随着IO句柄的增加而增加，特别对长链接应用的负面影响是最大的。
2.epoll：
a.机制：
基于“伪”AIO（异步IO).当有读写状态时，事件通知用户级。以内核态实现，以达到高效及节省资源。
b.优点：
支持一个进程打开大数目的socket描述符(FD)
IO效率不随FD数目增加而线性下降
使用mmap加速内核与用户空间的消息传递
内核微调提供的优化可能性及灵活性
3.本地IO角度
windows IO
1.Windows的高效模型Completion IO 完成端口
a.机制:
重叠IO支持：其实就是AIO(异步IO),说白话一点就是从内核级别在有数据读写可能时通过回调函数或事件来通知用户空间进行数据处理。
对线程进行管理：
操作返回的方式：一般操作完成后要通知程序进行后续处理。但写操作可以不通知用户，此时如果用户写操作不能马上完成，写操作的相关数据会被暂存到非交换缓冲区中，在操作完成的时候，系统会自动释放缓冲区，此时发起完写操作，使用的内存就可以释放了。但如果占用非交换缓冲太多会使系统停止响应
b.优点:
三，进程，线程：
这个不做详细分析，太多关于这方面的资料：这里我们只关注几点：
1.简单机制：
windows: 提供进程与线程接口，基于线程进行调度，进程提供资源共享空间。
linux : 内核只提供进程，线程只是用户级别的封装接口，以进程方式实现线程，只是一个主进程以子进程方式创建了线程这些子进程共享一些资源罢了：
2.对比：
windows下的进程资源消耗大于linux 的进程。
四，安全机制：
历史上看linux用户管理比windows严格，显得更安全：）不过随着windows server的发展，linux在这优势不再明显，但是windows是流行的桌面系统，用户群体太大，产生hacker有更好的环境土壤呀，呵呵。
四，操作系统机制对服务的影响：
1.高并发角度：
其实从最新的技术发展动态来看，如果单纯从技术性能机制上比，linux,windows没有太大的差别，高并发一般取决于连接对资源的消耗方式。但是在其上方案的提供上，却有差别。比如Nginx,Node.JS,Apache,Lighttpd，Tomcat, J2EE相关的AApplication Server这些高并发Web或应用服务器在windows平台上，有的是不支持。有的是运行效率不高。同时相关的组件提供在linux平台上有更多的支持。
2.高吞吐量角度：
从吞吐量上处理，基于操作系统可提供的最大化资源，基于各种IO的效率，包括网络IO,本地文件的IO效率。
3.缓存角度：
缓存角度有很多方案及级别。我们先从最简单非方案级别，从IO角度分个类进行简单描述：
1.本地文件缓存。这个有很多方案，但如果你了解操作系统的VFS层之后，你会发现，如果你对服务器业务承载的合理划分，提高命中率以后。你可以不用任何缓存方案，利用操作系统的自已的文件机制，你就能处理本地文件缓存，效率一点也不比第三方方案差，当然，你如果处理复杂的文件缓存的话，你要考虑目录的文件数限制，小文件处理等，你要选择相应的第三方文件缓存方案。其实数据库从其内部访问机制来看，如果数据库文件大小小于等于可用内存总量大小，文件系统的缓存机制同样可以加速数据库的速度，你会发现数据是越来越快速的运行，很奇怪是吧？这里我会在专门的系统方案中进行分析。
2.逻辑缓存：
这个从操作系统层面没有太大区别，区别在于第三方软件对linux的支持度远大于windows平台，没有办法，技术历史文化原因起更大作用：）
五，开发及运维平台方案的角度
windows平台：
.net 它只是一个能与J2EE进行对等对比的企业解决方案平台，因为针对高并发，高吞吐量，海量数据的Web或其它服务应用来说，太多优于.net解决方案。所以我们现在只针对。.net与J2EE进行对比。
这是因为经过历史检验的服务系统及平台方案不在windows平台上，现在使用范围最广的平台方案，最新发展有影响力的平台也不在windows及.net平台上，多是基于linux平台上混合语言及平台的整合与集成。当然造成这个因素很复杂，涉及商业运营，成本，技术的历名及文化。
1.从多系统整合，平台延展性上讲：
.net显然无法要提并论 。选择了.net你就选定了windows操作系统，选定了硬范围比如在CPU上, 因为windows目前基本上是支持Intel，比如一些高端服务器设备windows server就无法支持，这就不方便（只是不方便没有说不可能：））方案集成以前大型机上的各种旧系统，同时也无法利用一些大型机高的硬件性能，大型机上一些专门服务型操作系统的安全性。也选定了SQL_Server数据库，在数据库方面，.Net 在自身的Microsoft SQL Server 上也会比其他数据库运行得好。J2EE是一套通用标准，有诸多公司，诸多方案进行支持，系统互联，还有一些旧的系统的整合， 这些都是.net无法相提并论的。详细讨论会在系统方案分析文章中进行讨论。
2.系统成熟度：
J2EE 在1999 年形成了其成熟的架构，并且到今天已经有相当成熟的经过检验的企业应用系统。而.net发展还显稚嫩。而且从微软企业历史可以看出微软从来不是一个老牌的企业级解决方案的提供者。
3. 工程管理角度：
目前人力资源市场上的对企业解决方案人才，J2EE及以前各种Linux，Unix,服务平台上的人才的积累是远远大于windows 操作系统及.net平台的。这是快速发展的互联网企业面临的最大工程管理问题，同时如今这几年在移动互联网大潮下，基于linux，及类linux底层的移动设备的疯狂发展（如Android,IOS)，不仅服务端，移动客户端的非windows人才与windows平台的比例也不在同一水平线上。
六，软件工程角度：
其实这个角度常常是最重要的方案选择角度。
1.旧系统的整合，
2.多系统平台的兼容，发展推动力量，新技术的快速应用。
3.专业人力资源的快速配置与获取：
首先要考虑目前公司组织方面的人力资源的技术特点，如果系统主要是基于企业级系统，而且多是熟悉基于windows平台的开发，那首先.net及windows server服务器。如果不是这样的特定条件，最好选择linux平台上的其它稳定匹配的方案或方案整合。
4.商业服务方面：
有人说windows虽然付费但提供强大技术支持，真的是这样吗？一般情况下，得到的支持是两个字“重启” ，我有一些朋友在微软做开发或做技术支持，聊下来的结果是，对一些桌面应用的支持还算到位，当然里面包括最多的一台词就是“先重启试试”，慢了要重启，Crash了要重启，不能用一些东西了，要重启。 对于服务器支持而言多是感叹，但在linux社区上你倒反而可以得到更多有建设性的帮助。当然这个角度纯是个人戏说，人人有自己的感受。
----未完----
