有关性能优化服务器部署的扩展话题
本文的前提在于代码和SQL等均已完成优化，但现有部署框架无法满足未来的发展，不得不进行部署优化的情况下。
1. 利用强大的客户端（改造难度:★ 优化效果: ★ 服务器资金耗费：无）
如果我们将所有的算法运算放在服务器上，那么如果暂时无运算增加服务器的话，随着客户数量几何倍数增长，那么服务器或许不是因为数据库端成为瓶颈，而是被浩如烟海的各种算法运算给压垮。
有时候我们的客户很强大，客户端的机器很强，甚至用到E8400之类的CPU，内存普遍在4G，那么一些与数据库无关的算法运算可以适当分散在客户端。典型应用：网游。网游很黄很暴力？厄，一些需要将数据存储在服务器的图形设计工具，这总可以了吧J
2. 客户端很弱，单一服务器亦很弱（改造难度:★★ 优化效果: ★★服务器资金耗费：★★★）
每年年末客户或许会进行一些财务结算之类的东东，咱们就别用客户端的火铳电脑，去做这种大规模运算了。可以在后台放置一台任务分配服务器，然后将客户的请求放入队列中，在这台服务器后面有很多小运算服务器，将运算分布至他们身上，然后再将数据写入数据库
3. 分布式运算服务器VS单薄的数据库（改造难度:★★优化效果: ★★★ 服务器资金耗费：★）
当运算能力通过分布应用加强之后，随着数据量的增加，大家会发现原先威猛的数据库先生也开始变得力不从心了。这种时候，如果预算成问题的话，但增加一台镜像的预算是允许的话，那么可以做一个镜像专用于数据库的查询操作，将查询与更新的操作负载分开。或许可以解决些许问题
4. 爆炸般扩散的客户数量VS羊肠小道一般的数据性能（改造难度:★★★优化效果: ★★★★★ 服务器资金耗费：★★★★★）
我们清楚FaceBook以及Twitter的用户目前是上亿级别的，那么依赖传统关系数据库的优化是无法满足其应用的。那么No SQL数据库就派上用场了，由一堆数据库节点共同构成的一个分布式网络服务，对No SQL数据库的一个写操作，会被复制到其他节点上去，对No SQL数据库的读操作，也会被路由到某个节点上面去读取。对于一个No SQL数据库的群集来说，扩展性能是比较简单的事情，只管在群集里面添加节点就可以了。
5. 爆炸般扩散的客户数量+实时BI数据仓库分析（改造难度:★★★★★优化效果: ★★★★★ 服务器资金耗费：★★★★★★★★★）
这种应用如淘宝，亚马逊等大型电子商务网站。他们既需要提供客户舒服的客户体验，也需要实时进行BI运算，为商家服务。
那么简单的通过Key/Value级别的No SQL数据库在满足客户端的应用之外，是满足不了天量数据BI运算要求的，所以集群化的数据仓库应用就派上用场了，不过该应用的投入级别将达到上亿美金。有米者的首选，无米者的梦想。
服务器部署的选型优化，是与业务应用场景以及客户群的发展密切关联的，需要经过反复推敲和验证，因为这种决策会影响整个公司未来数年的预算以及技术型别，还是那句话，根据不同的情况使用不同的兵器，在做什么之前应明白为什么这样做，先不要盲目推翻某一种现行框架，或羡慕其他“先进”的框架，尤其在现有框架依然存在巨大优化空间之前。J
