超级服务器的诞生
我出生于1631年，宿居在柴桑郡爱叶县，家世历来以经商为主，我13岁时候，开始跟着学习如何做买卖。父亲交给我东河附近的一个店铺，我跟父亲商量，店铺以卖盐为营。
很快店铺弄好了，我就早晨跑盐税局去弄盐票，然后去盐场批发盐，中午赶回来，下午卖盐，每天工作量简单重复，从来没有差错（结构化程序）。到了年底算了下账，一年收入还行。当年风调雨顺，其他农家都大丰收。到了第二年，佃户换盐量大了不少，我一人累不过来，只能找帮手。找来三个长工，一人负责帮我批发盐，一人负责帮我挑盐，一人负责帮我卖盐（函数化程序）。每天按照我的安排有条不紊的做着，早晨批发盐的长工先出发去盐税局，然后挑盐的长工去盐场等着拿盐，而卖盐的人早早起来把头一天挑回的盐卖掉。
这一年干的不错，我手上余钱多了不少，心思活络起来，觉得只卖盐似乎不够满足我的想法。于是跟父亲合计了一下，开始卖布匹，茶叶，大米等商品起来，按照卖盐的思路，将之前的帮手工作内容扩大，批发盐的同时还得负责批发其他商品，挑盐的同时也还得负责挑其他的商品，因此每个人都比之前更忙了（多线程程序）。批发盐的长工从早忙到晚去各个地方采购商品，挑担的和卖货的长工也一样，当然他们的工钱我也涨了不少。
可是出乎意料的问题很快出现了，一天挑担的帮手去盐场等去了，可是负责批发的长工却去批发布匹去，批发完以后，挑担的人没来，只好一直等着人来挑货，而店铺里面又缺着布匹，卖货的人一直在等着布匹，三人这样荒废了一天。后面类似的情况一再出现，工作常常协调不过来，长工经常互相等待造成工作无法执行下去（哲学家就餐死锁问题，因死锁问题非常多种类，这里不具体列出来，可以参考操作系统原理）。为了这个问题，我琢磨好久，只能设置一些规则出来。由卖货的人来决定挑担的人该干什么活，而挑担的人来决定批发的人该干什么活。卖货的人发现缺布匹，就安排挑担的人去挑布匹，挑担的人来安排批发的人去哪批发布匹。如此，工作总能衔接上，再也没犯过那样所有人光等着的情况。
我的生意很快重新兴隆起来，因为价格低廉，来买东西的人更多了。长工已经根本忙不过来，我只能再多请几个帮手（多核计算机）。当人手多了以后，渐渐我发现，安排人手已经忙不过来，每天给每个帮手安排活就够累，还要协调好他们的工作。为此，我请来一个秀才，帮我重新规划流程。按照设计，将所有做批发的人分配到一个组（数据内容收集组件），类似，挑担的人一个组（消息组件），卖货的人一个组（数据内容消费组件）。而且因为询问商品的人多了以后，建立前台组（web组件），又库存量大，新增库存组（内容存储组件）。还有账目组（数据库组件），每个组分工明确。组之间沟通的内容必须规范化，简洁化，快速化。前台组每天负责将客户咨询的信息整理出来，交给卖货组，卖货组通过库存组提供现有库存，预算出大概需要多少货物，让挑担组去挑来，而挑担组安排批发组去批发。账目组需要记录下库存的消耗，卖货组卖的货物，以及批发组批发了多少货物。每个组不用去关心太多，例如挑担组只需要知道哪种货物需要挑多少，把任务交给批发组，安排指定的人数去批发点挑货就行。（组件化设计）
我的生意发展的很快，其他商家还是一两个人在运作，而我的店铺都快几百号人。可是随着而来的压力，也快速呈现出来，所有的组都在我的商铺办公，我为此不得不扩大店铺，增高店铺楼层（高性能服务器）。店铺扩大的成本越来越高，楼越高，建材原料越贵，以几何倍数来增加，我有点不堪重负。因为客人的量越来越大，我不得不扩大我的前台和大门（增加带宽）；有些客人离我太遥远，为了买我的货不得不一次性采购很多东西，赶上节假日，来的人采购太多，我的店铺无法承受高峰时段的压力；账目的保管和库存的管理，我不得不天天担心着，生怕因为破坏或者着火，让我的事业毁于一旦。每天要整理账目并且备份账目，库存也是分多个地方存贮，但毕竟还在一个大楼里面，我整日无法入睡。（以上都是单台服务器慢慢出现的问题，随着用户访问量加大，问题越来越严重，急需变革。）