SaaS应用企业最担心的不过是两件事，一是将企业的数据保存在外部的数据库服务器中是否安全;二是这么多用户同时访问SaaS应用服务，其性能是否可以保障。笔者这就以自己的亲身感受为例，谈谈SaaS应用提供商是如何通过数据库负载均衡来提高SaaS应用程序的性能。

　　第一阶段：单个数据库服务阶段。

　　笔者企业一开始就上了OA系统。这个OA系统是基于B/S架构的。企业刚开始设计、使用这个OA系统的时候，并不没有想到做为商品来卖，是供企业自己内部使用的。所有一开始，就只才用了单个数据库服务器。后来随着SaaS概念的提出，企业就想到也可以将这个OA系统拿出来卖。后来随着用户数量的增多，OA系统的性能明显下降。为了提高OA系统的性能，技术部分提出了双WEB服务器的方案。也就是说，通过两台WEB服务器来分流用户的请求。不过在后台数据库仍然只有一台。当用户数量比较少的时候，往往数据库不会成为用户访问数据的瓶颈。应用程序性能的瓶颈主要卡在WEB服务器上。为此在用户数量增加不多的情况下，通过添加新的WEB服务器可以明显提高应用程序的性能。

　　第二阶段：将数据更新与查询分布在不同的服务器中。

　　后来由于客户的要求，企业在原先的OA系统中又集成了公司论坛、项目管理等应用系统，用户的数量也随之增加。在这多方面的影响下，SaaS应用软件的性能又开始逐渐下降，企业不得接到客户的投诉。经过技术专家的分析与论证，此时通过增加WEB服务企来改善应用程序的性能效果已经不明显。为了提高应用程序的性能，提高客户满意度，经过跟企业技术部门协商后，决定通过增加数据库服务器来改善应用程序的性能。考虑到论坛、OA系统的应用特点，其中 80%上的用户都只是对信息的查询，而很少涉及到对数据的更新。企业决定将数据更新与查询分布在不同的服务器，来均衡数据库发负载。也就说，如果只是查询数据的话，只是从两台辅助服务器中进行查询。如果需要对其中的数据进行更新，那么WEB应用程序就会将用户的请求连接到主服务器中执行更新操作。更新完毕后，主服务器中的数据会同辅助服务器中的数据进行同步。这么设计可以大幅度的提高SaaS应用程序的性能。

　　一是将用户更新请求与查询请求进行分流。这个原理就好像是告诉公路上将车道分为超车道、普通车道、货车道等等。通过对信息流的合理分流，可以提高SaaS应用程序后台数据库的性能。同时有两台服务器同时响应用户的查询请求。WEB应用程序会自动根据这两台数据库服务器的负荷来引导用户连接到相对来说比较空闲的数据库服务器中。也就是说，这对于用户来说是透明的，他们并不知道后台数据库的部署已经有了天翻地覆的效果。

　　二是为后续的扩展提供了很好的平台。只要数据的更新不是导致应用程序性能下降的主要原因，即应用程序的性能瓶颈主要在于数据的查询作业，那么在以后就可以简单的通过增加辅助服务器来分散用户查询操作对数据库服务器带来的压力。由于用户数量的增加，笔者企业现在数据库辅助服务器已经增加到了5台。由于用户数量增加，其更新操作数量反而增加不多，根据观测现在主数据库服务器的性能还是可以的。为此企业暂时没有增加主数据库服务器的打算。

　　三是在数据的同步上比较容易实现。在通过使用多个数据库来负责均衡，其面临的主要问题就是数据同步的问题。当用户连接到某台数据库服务器，更新了相关内容之后，如何及时的同步到其他的数据库服务器中去。这是技术人员必须要考虑的问题。而采用这个主数据库加查询辅助数据库的方案，让数据同步的问题变得比较简单。也就是说，在这个方案中，技术人员只需要考虑主服务器到各个辅助服务器之间数据的更新，而不用考虑各个服务器内之间的数据更新。因为此时只有一台数据库服务器的数据是可以被用户更新的。其他服务器对于用户来说是只读的。故此时技术人员要实现数据同步的话，就会变得相对简单许多。

　　第三阶段：利用垂直分割提高数据库的性能。

　　虽然企业现在的数据库架构，暂时还可以满足用户性能上的需求。但是企业已经意识到，现在这种架构不会存在很久。因为现在用户的数量与信息流量都在急剧增加。主数据库服务器的负荷快要达到预计的警戒点了。现在企业技术人员已经在设计、部署新一轮的数据库升级方案了。按照技术人员的思路，这次想通过垂直分割地防范来改善主数据库服务的性能。也就是说，按照目前的应用情况，将SaaS应用的所有业务都放在一台主数据库上去进行数据更新，对于主数据库服务器的压力比较大。由于数据更新量实在太大，通过硬件升级、查询与更新数据分流等手段效果已经不是很明显。技术人员想用过垂直分割的手段，将不同的业务流量分割到不同的数据库服务器中去。即将BBS业务、OA业务、项目管理业务分别部署到三台主服务器上，而辅助服务器暂时保留原有的数量。如此通过WEB应用程序的引导，用户需要访问某个应用的话（需要对这个应用的数据进行更新操作），WEB应用程序就会自动将其引导到合适的主服务器中去。而辅助服务器的话，仍然担任着数据查询的角色。此时由于各个主服务器之间负责各自独立的业务，所以彼此之间也不需要很严格的数据同步。即只需要实现主服务器与辅助服务器之间的数据同步即可。

　　第四阶段：备用解决方案。

　　如果后续随着用户数量的增加与业务种类的增加，上面这个解决方案还不能够满足用户访问需求的话，技术人员还涉及了一个备用的解决方案。这个备用解决方案是在上面这个解决方案的基础上，通过添加同一个业务的主服务器数量来提高SaaS应用服务的性能。或者说，更进一步的解决方案，就是实现数据库的分布式方案。毕竟当用户多了、SaaS业务多了，需要实现在各个业务之间进行统一的身份认证。即凭借一个用户名与密码就可以访问各个SaaS应用服务。现在很多大型的WEB应用，如sina等网站，在后台都实现了分布式的数据库服务架构，通过提高数据查询与更新的效率来提高SaaS应用程序的性能。

　　如果用户与业务数量再增加，这个分布式数据库方案还不能够解决问题的话，那么就需要在数据存储、云计算等方面努力了。不过一般来说，只要用户数量在500万以下的SaaS的应用，一般以上几个解决方案就可以了。最后笔者要强调的是，虽然从成本、风险等角度考虑，根据用户的数量与业务的种类一步步的进行数据库解决方案的升级是可行的。因为现在向SQL Server或者Oracle等数据库都集成了相关的解决方案。升级是比较简单的，风险也不是很大。但是在系统规划的时候，还是需要考虑未来业务与用户数量的增长。在成本允许的情况下，尽量采取性能比较高的解决方案。也就是说，如上的各个阶段企业不用一步步来。只要资金充裕，并对未来的应用前景比较有信心的话，可以一步到位。毕竟在升级的过程中，无论规划的多好，都会出现短暂的停机现象。