一个Node.js饭店的发展历程
前面的一堆理论似乎不太好明白，最后讲一个关于饭店发展历程的故事作为结尾吧。
第一年
饭店开张，只有一个厨师（同时还兼任老板、服务员、打荷、收银员），当一个客人点餐之后，这个厨师就开始记录（服务员），然后他就开始备菜（打荷）、炒菜（厨师）、然后上菜（服务员）、收钱（收银员），这个时候即使有其他客人来了，等着吧还没忙完呢。这个厨师就这样兢兢业业，有条不紊的干着每一件事，因为每件事都是亲力亲为，都不能出错，虽然所有的事情都了然于心，但效率很低，一天只能卖出十多份饭菜。
这是饭店单线程的第一年：
利：它没有线程上下文交换所带来性能上的开销（因为每件事都是亲力亲为）；
弊：无法利用多核CPU（厨房空间那么大，完全可以很多人一起干活），同时错误会引起整个应用退出，应用的健壮性值得考验（当这个厨师生病，或者有事了饭店就得停业）
第二年
这个厨师第一年赚了点钱，回到老家把表哥、表弟全拉过来，现在他们有5个人，可工作方式还是跟厨师第一年的时候一样。当客人来了，就会有一个人去记录，然后自己去厨房洗菜、切菜、炒菜、洗碗、上菜、收钱。当来了第六个客人的时候，就要等待前面的人做完所有事情才能空出一个人来接待。后来他们就想既然客户多了，厨师就得多，再回老家多叫几个兄弟吧。这时新的问题发生了，当每个厨师做完饭后就出去找客人，客人说我刚刚点餐了，然后厨师就去厨房问，刚刚是哪个表兄接待的那个客户，要是没有人接待的话，我来处理。就这样忙忙碌碌一年，他们比去年多做了好多生意，但是感觉每天客户多的时候，厨房里头乱糟糟的，总要询问这个询问那个。
这就是饭店多线程的一年：
利：一个线程服务一个请求，线程之间可以共享数据，这样可以避免内存的浪费，可以同时处理多个请求；
弊：操作系统内核在切换线程的同时也要切换线程的上下文，当线程数量过多时，时间将会被消耗在上下文切换上（厨房里头乱糟糟的，总要询问这个询问那个）。
第三年
老板娘过来了（Node.Js闪亮登场），她发现这帮厨师都在各自为战，自己拿到客户的点餐后去洗菜、切菜、洗碗、炒菜、上菜、收钱，一个人只能同时处理一个任务，而且作为厨师没必要去做洗菜、切菜、洗碗、收银之类费时的工作。
所以老板娘把所有人进行了分工：
老板作为厨师长（Node里头的主线程），他不再去洗碗、洗菜、切菜、炒菜、收银（我们可以把洗碗、洗菜、炒菜、切菜认为是比较耗时的I/O），他只负责将收银台小妹（观察者）拿过来的菜单分配给不同的厨师，打荷（这些人就是不同的I/O线程），吩咐下去之后他不会等菜出来再走（进入下一个轮询），又问收银台小妹还有没有菜单要做，如果有继续轮询，如果没有了休息（退出进程）。当菜做出来之后放在上菜区（回调），收银台就显示菜出来了（将回调放入事件队列），当老板查询收银员（观察者）的时候，收银员就告诉厨师长，厨师长就通知服务员（处理不同I/O的线程）上菜（完成回调），这样饭店有条不紊的运行下去，客人也越来越多了。
有些高端客户不想在这挤，所以老板娘就想，饭店房子那么大（多核CPU）,可以叫她弟弟（子进程的主线程）在这开个子店（child_process），然后发现一个收银员不够用，那就多招几个收银员（多个观察者），就这样每个分店（进程）只有一个主管（主线程），主管的弱点就是无暇顾及洗碗等杂活（I/O），只能关注业务，至于饭店能开多大（应用程序能处理多大请求），要看主管的处理能力（主线程的编程强壮度）。最后，大饭店起了个时髦的名字叫Hotel NodeJs！
