业务并行化——前进时代的需要

在这个飞速发展的信息时代，信息流量日渐增大。有时候可能还是峰谷，可能因为某个热点事件突然会让你的网络流量飙升至峰顶。也有可能让你的磁盘io或者cpu为100%using.不过一般情况下我们可以用多台计算机进行负载均衡器进行调度，让每个后端并行运作的服务器各个负载都在一定的平均水平范围浮动。听起来不错，确实是这样的，不过这是大型网络应用的典范，对于一个成长型的企业来说这个可能只能事与愿违，因为要做的工作还很多。

首先，我们应该明白后端服务器并行运作时可能生产出各自不同的运算结果反馈给客户端。这个时候我们需要控制后端并行服务器上所运行的业务程序也是可以并行的。这样才能保证服务器应用平台的并行化下的业务并行化，从而保证服务器高性价比的服务。这就是我们追求业务并行化的原因之一。

很多人看来后端的业务平台举例来说LAMP/LNMP/FNMP下后端PHP产生的session数据统一通告网络存放memcache来保持负载均衡器的调度一致性，mysql共同为后端多个应用提供事务操作，然后挂载一个NFS来提供公共的webroot，这就是最基本的并行化架构了。没错session的共享可以那样，不过这个架构最大的缺点是使用了NFS ,Nfs在小规模网站，并发不是太高的应用上，还可以跑的胜欢。如果是应用在一个高并发、多事务的在线商城或者人气较高论坛的。显然这里是个瓶颈，很多大型论坛和网站他们又是怎么做的呢？肯定不应该是用nfs在做webroot，我测试过NFS\Samba来做高并发的webroot，并发写点击少于本地应用点击90%。（也测试过MFS分布式文件系统）。效果很不理想，而且这样的架构存在单点故障，这样的架构存在单点故障，这是很致命的。负载均衡调度下的单点故障，这是很不让人愿意的，但确实又存在！ 那我们应该怎么应对和改变这种现状呢？

首先，nfs本身不是什么问题，问题是我们为什么要让后端n个应用服务器共享它？因为我们的业务应用某些地方还不能并行化。 某些地方会产生“独一无二”的数据或者指令，而且他们会影响全局的访问。所以这正是我们要解决的问题——业务并行化！ 我们需要各个业务平台能独立地、并行的在各个云端运行，他们产生的数据结果又能“形散而神不散”。 其中涉及临时目录写、文件上传、权限控制、后台功能设计、前段展示等。 如果能够并行化了，我们的系统架构基本上可以让每个点的服务器全力运行在“本地”资源上，而且保障全局稳定性与高性能。我想这就是出路……