在国内的中小企业管理软件市场中，如何应用企业管理软件来优化管理经营、不断提高生产效率，这一需求日益增长。其中面向SaaS模式的企业管理软件，由于它的高效性，正不断为许多企业，特别是中小企业所采用。SaaS系统着重于敏捷性和整合服务，同时强调对多用户的并发支持，所以在开发时，更多的会考虑系统的高并发性、高数据量的特点，而且也要求系统平台必须具有非常高的性能和伸缩性。由此可见，研发人员在设计和实现基于SaaS的管理软件时会面临着诸多挑战，如系统性能、系统安全、良好的伸缩性与扩展性等。本文主要从整体架构、数据模型、扩展性、伸缩性这几个方面分析目前SaaS平台管理系统的设计思路和主要特点。

1 整体架构

从整体系统架构设计的角度来看， 目前主流的SaaS平台主要采用以下三种结构：

1.1 独立用户架构 这种独立用户架构中，每个客户都拥有一个为其定制的应用实例，应用实例具有完全不同的底层代码。从系统架构而言，基于这种架构SaaS管理软件非常类似于传统的本地软件，它的基本特点是属于同一客户的不同终端用户使用客户端软件连接到同一个应用实例，与其它同时运行在服务器上的应用实例相比，该客户的应用实例在服务器上完全独立运行。因为这个原因，在花费少量开发资源和无需重新设计整个架构的前提下，传统的服务器/客户端的应用可以被改造成为这种架构的的SaaS系统。技术人员通过将已有的非SaaS系统重构为基于独立用户的SaaS系统，然后整合服务器资源，并降低管理成本，比起其它更为成熟的SaaS管理系统，这种方式可以在投入不大的情况下获得一定收益。所以目前不少企业管理软件开发商都常常使用这种架构来设计并实现自己的SaaS系统。但是，虽然在开发上投入较少，这种SaaS系统也具有不可避免的缺点，主要是在使用后期，随着所支持客户数的上升，系统硬件维护和平台运营费用会急剧升高。因此从长远角度来看，带来的收益有限。

1.2 独立但可配置的用户架构 在独立但可配置的用户架构中，尽管每个客户还是各自拥有一个单独的应用实例，但每个用户实例可以根据客户需求单独定制。独立但可配置的用户架构与独立用户架构相比，最大的不同点在于，独立但可配置的用户架构中，每个客户所使用的应用实例将基于完全相同底层的代码，但SaaS服务提供商可以提供详细的配置选项，不同的应用实例之间保持独立运行在服务器之上，并允许客户修改部分流程和应用的界面。独立但可配置的用户架构将所有客户的应用实例统一在同一代码库之下，它在很大程度上减少了服务提供商的服务需求。主要原因在于，此时对系统底层代码任何微小的改变都会马上影响到所有客户，虽然可以节省单独修改所付出的成本，但是比起独立用户架构，如果将一个传统的C/S系统重写为这一类基于独立但可配置的用户架构的SaaS管理软件系统，将需要花费更多的二次开发成本。最后，此类系统同独立用户架构相类似的一点是，它同样需要SaaS服务提供商提供足够的硬件资源来同时运行大量的并发应用实例，因此在后期运行中，需要非常高的运营成本和维护成本。因此不少企业管理开发商在开发基于SaaS管理软件系统时，已渐渐减少采用这种架构。

1.3 可配置的多用户架构 这种架构是目前的主流架构，在这一可配置的多用户架构中，一个运行的应用实例将为系统内的所有客户服务，同时系统配置元数据，通过这一方式为每一个客户提供不同用户功能。而且系统采用可配置的安全策略和权限控制方式，这能保证每一个客户的数据可被单独存放，并将它数据隔离于其它的客户。因此从最终用户来看，他们看到所使用的应用实例是透明的，这些实例在同一时间也会为其他客户所共享。随着SaaS服务提供的业务和客户增多，通常的解决办法是通过提供更多的服务器资源来运行更多应用实例，而且常常这是唯一的方式，这种可配置的多用户架构同样有效地解决了这样一个问题。采用了这种架构后，比起前两种架构的SaaS系统，SaaS服务供应商可以用同样数量的服务器资源为更多的客户服务，从而更有效地利用硬件资源，降低运营成本。因此不少企业管理开发商在开发基于SaaS管理软件系统时，纷纷采用这种架构。

2 数据模型

除了整体架构，数据模型也是一个SaaS系统中最为核心的部分。对于构建一个SaaS平台的数据模型来说，最关键的问题在于决定如何在数据的共享和隔离之间求得一定的平衡，而目前主流的SaaS平台一般采用以下两种方式构造其数据模型。

2.1 独立数据库 独立数据库方式是实现数据隔离的一种最为简便的解决方案，在这一方案中，每个客户的数据单独存放在一个独立数据库中。所有的客户共享使用大部分的系统资源，大部分的代码。但在物理层面上，每个客户都拥有自己一整套单独存放的数据。系统用元数据来记录基本信息，如数据库和特定客户的对应关系等。系统内也设置一系列的数据安全访问策略和用户控制权限，通过这一方法，即使整个SaaS系统突然发生异常状况，也能保证某个客户的数据不会意外被其它客户所访问，从而提高数据的安全性。

在实际商业应用中，如果客户为了做到数据隔离，确保数据安全，而愿意支付额外的费用，这种独立数据库的数据模型是最为适合的解决方案。如银行业或医疗行业的客户们，为了安全考虑，经常需要隔离数据，在某些极端情况下，这些客户可能都不会去使用任何不支持客户独立数据库的SaaS系统。所以一般这种数据模型的应用范围比较有限，只会被通用客户或者对数据安全不具备敏感性的行业客户所采用。

2.2 共享数据库 目前大部分基于SaaS的管理系统都采用共享数据库的方式，所有客户各自拥有一套不同的数据表组合，并存放在单独的Schema之内，但它们共享同一个数据库。从开发的角度而言，技术人员比较容易实现这种客户独立Schema的方式。从数据扩展性来看，这种解决方案允许客户相对自由地增加和修改其中的数据结构。系统在开始建立客户的Schema时，会预先创建一系列初始的数据结构，然后客户可以对其做个性化的修改，来使其符合实际应用中的业务需求。

在数据共享和数据隔离之间，这种客户独立Schema的方式获得了一定的平衡。通过数据库共享的方式，一台服务器就可以支持更多的客户，同时又确保了数据安全，因为在物理上实现了一定程度的数据隔离。正因为这一良好特性，因此为大部分的SaaS系统所采用。

3 系统扩展性和伸缩性

在使用SaaS管理系统的时候，不同情况下的使用者有着不同的要求，在实际应用中，一个扩展性不好的数据模型无法满足客户在配置方面的个性化需求。因此开发的SaaS系统具有良好的扩展性，是应用中的一个重要用户需求。除此之外，SaaS系统在自设计之初就是为了使数以千计的用户同时使用，与普通的一般软件系统相比，系统具备良好的伸缩性就显得非常重要。因为在SaaS系统内，每一客户端都拥有非常多的用户，而且随着客户数量的上升，用户数量也会成倍地上升。用户数量的上升对于客户端安装的企业软件而言，意味着提升系统的性能。