提高应用服务器吞吐量的一般方法

概述：本文简单概述了为提高应用程序吞吐量的一般做法，这些做法仅涉及总体部署方面。

 

概览图

 

应用服务器

一般的，我们通过微软的网络负载平衡技术实现扩展，你可以架设32台以内的应用服务器，当然实际上你可以架设更多（微软有详细的资料介绍如何架设的更多）。对于一般的ERP应用来说，32台服务器已经足够足够使用了，因为性能的瓶颈实际上在数据库上。

 

使用微软网络负载平衡技术的好处：他没有一个中央调度服务器，所以你不必担心这个中央调度服务器的崩溃或缓慢导致事实上仍然有瓶颈。

 

这些应用服务器之间是完全均等的，也就是说A服务器能够提供的功能在B服务器上完全一样能够做到，他区别于从业务上划分不同的应用服务器。

 

如果你觉得一个服务器寄生一个服务实例，有些让这台服务器太浪费，你可以将你的服务设计成COM+或者寄生在IIS下，因为他们都有成熟的技术将服务器压榨到底。

 

当然，这样的服务器部署方式对程序编写有一定的要求，例如你在你的程序中使用静态变量缓存数据时，你可能遇到麻烦，因为当你更新你的缓 存时，即你的静态变量时，你仅仅只更新某一台服务器。相似的问题同样发生在单例的服务上。因此你必须保证服务是无状态的，那么缓存数据怎么办呢？

 

缓存服务器

幸好微软有开发了Velocity，一个使用分布式内存缓存技术，关于此技术的中文说明你可以参考《使用微软分布式缓存服务》，他是三篇连载的文章写的很详细。

 

通过使用Velocity你相当于有了一个全局的缓存空间，同样的，通过简单的手法你还可以实现全局的会话数据，这样你不用担心某台应用服务器崩溃导致会话数据。

 

当然，从我目前了解到的信息来看，Velocity将数据分布到多台计算机上，如果某个服务器崩溃，对于缓存的数据来说，我觉得无所谓，没有任何影响，问题是寄生在这个服务器的会话数据你在别的机器上也是找不到的。所以某台缓存服务器对部分在线用户是有影响的。

 

Velocity还提供了版本功能，这个功能你必须了解并在你的程序中充分考虑，这是在大并发下必须考虑的问题；

 

但是缓存服务器毕竟是缓存，理论上我们认为他具有不稳定性。所以当你需要一些具有全局状态的对象时，可能比较头大了。例如你希望有一个 元数据服务，记录当前应用中所有实体的结构，这些元数据不仅是数据，还有行为。目前我没有很好的办法，只能尽可能的将这些服务设计成无状态服务。

 

数据库服务器

其实一切瓶颈的根源还是在数据库服务器，到目前为止，我没有收到任何信息说Microsoft有打算让SQL Server可以将一个数据库分布在多个计算机上。

 

从目前的技术上来说，你还是可以有很多的手段提高性能，这些方法在网络上都有很多的文章，我这里仅是罗列一下：

l         购买一个64位的计算机，64位的操作系统，64位的SQLServer吧，购买你的计算机能够装进的最大内存，这是最简单最快速的办法，下面所有的方法都比不是这个来的快。要知道通常的ERP应用数据库都只有30GB以下，而SQL Server都可以把数据都缓存了；

l         将一个数据库分布在多个文件上，而这些文件又分布在不同的磁盘阵列上；

l         超级大的表请考虑将历史数据拆分到别的表，在查询中尽可能包含日期，而日期字段又是聚集索引；

l         调整你的SQL和索引，这个老生常谈了，也是最复杂的。

l         从业务上，你仅可能的将多个帐套（业务上的帐套）设计到不同的数据库，例如不要在订单表上设计一个诸如AccountID的列区分不同的帐套，而将全国各地的订单都塞到这个表中，虽然程序上稍稍复杂些（我有时候觉得反而程序简单些了），但是将请求隔离到不同的数据库是很值得的，因为很多死锁你很难搞定的；

l         将大量频繁读取但是一般不会做关联查询的数据，例如配置数据和权限数据，尽可能的放在缓存中吧，如果你没有办法放在缓存中，那么也请隔离到另外一个数据库服务器；

l         将不太关联的业务表拆分到不同数据库服务器，例如你的OA和生产系统做关联查询的不多。这样你的数据库负载又分担开了，如果你发现还是有些表需要关联查询时，考虑使用SQL Sever的远程视图，将其映射过来，这样你的程序就不必为这种情况来个IF语句了。

 

方法还有很多，大家可以帮助补充下啊。