我曾经经历了unix开发向windows 开发的转型
现在又开始经历windows 开发向linux开发的转型
经过最近的知识回顾和实际工作，我总结出几点，给大家的一点提示，对于windows开发人员转移到linux平台上或许有点作用：
经验总体总结：不要照搬照抄windows上的开发经验，应该深入学习linux的技术特点，并根据linux的特点去进行开发，有以下几点重点的经验，由于我们开发的主要程序在windows上都已windows service形式存在，因此主要对比一下这两者的主要区别和注意事项：
1）linux 中没有service 这种特殊公民
注意windows service 与 linux守候进程之前的本质区别，在windows系统中，windows service是一种特殊公民，服务不是一个普通的进程，最本质的区别是windows的安全隔离机制除了进程外，还有个重要的概念窗口工作站，这一层在linux系统中式不存在的，linux的守候进程的行为特征完全跟普通进程一样。
linux也没有windows上针对service这种特殊应用程序的管理配套环境，比如SCM，注册表，因此你和任何一个linux守候进程进行交互都需要在应用设计时在应用中涉及，包括如果start和stop
2) 记得实现CUI，响应信号作为内含管理端口
windows service 通常我们不进行主动管理，更多时候通过外部条件的变化驱动它的逻辑变化，比如来了新的请求，数据有改变等等，如果要做一个管理程序，通常是做一个windows应用程序（比如sql server 的 service manager），然后通过各种IPC手段进行通信
而在linux的守候进程中，本身设计的时候一般都会对来自CUI的kill进行进程内的信号响应，直接响应来自终端的信号控制守候进程行为，这是一种标准实现方式，比如ngnix，应该遵循
3）是否使用单进程多线程模型需要考虑
单进程，多线程这个在windows下几乎成为服务器端必备的选项。如果在linux下使用多线程模型请考虑几个问题：
第一个问题也是最重要的问题，内核一定在2.6版本以上，如果不是的话，一定升级服务器，由于我们service程序一般都是跟IO强相关的操作，在没有NPTL 的内核支持下，这种多线程程序将遭遇脆弱问题与性能问题，由于没有NPTL支持，线程在的信号投递需要在用户空间内靠类库完成，没有内核线程对应，效率和稳定性都很成问题
linux的标准服务程序设计一遍采用master + worker 多进程与I/O复用模型，这种模型是否值得模仿可以考虑
4）标准的文件IO
Linux系统中很多资源都是映射成为文件，采用统一的IO函数来出来，这个要注意理解，和windows有一定区别，文件,mmap（共享内存），设备等都会映射采用文件，统一一套IO函数来支持
5）推荐unix domain socket 作为IPC手段
unix domain socket 虽然开发模型与socket一致，但是由于它不需要经过网络协议栈的处理，没有复杂的包装解包协议操作，而且采用mmap作为数据缓冲区域，应该说性能还是非常高，最大的好处是他的开发模型与网络socket一致，代码风格可以保持一致，接口协议复用
6) java 对IPC的支持目前来看还不够好
java目前对linux下的各种IPC手段好没有原生支持，有一些第三方类库，当然如果不需要大数据传输的话，signal还是可以满足的。
因此我觉得java 的应用程序还是应该设计成多线程的，由于进程通信的不便利性，只是需要有一个进程管理程序，保持其稳定性
7）libevent能够满足绝大多数场景需求，如果极度追求性能还是自己写吧
使用libevnet能够带来极大的好处，使代码的可维护性大大提高，很多开源项目，如memcached等都是用了libevent，但是由于libevent采用EPOLL LT模式而非ET模式，因此不是最高性能的选择，如果极度追求性能，还是不行的。
这也就是memcached这个纯粹的内存管理应用，竟然在性能上赶不上mysql handle socket和 redis这些缓冲型应用的直接原因
写了这么多，也算是给自己做记录吧，分享给大家，希望多交流
