传统软件向SaaS软件转型方案的研究

关注、点赞，分享了解互联 前沿知识，月薪40K不是梦。

1 SaaS模型及相关概念

1.1 SaaS模型概述

SaaS模式是通过互联 提供软件服务的模式。与传统软件相比，SaaS软件不再是用户向软件开发商定制软件或进行二次开发，而是软件提供商在自己的服务器上部署应用软件。在Internet 上和通过Internet 提供在线软件服务。软件提供商负责搭建所有 络设备、软硬件运行平台等基础设施，并负责后期维护。企业用户根据实际需要，通过互联 向软件提供商订购所需的应用软件服务，并按照订购服务的数量和时长向提供商付费。

SaaS模式下，通过租用服务，用户可以按需使用软件，无需定制软件、购买硬件、搭建机房、招聘IT维护人员，用户无需关心软件的后期维护，只要当他们连接到互联 时，他们可以享受该软件。供应商提供的软件服务。用户无需一次性支付大笔软件定制费，只需支付少量租用费即可使用软件。风险非常低。如果软件不符合要求或者不适合公司的管理模式，可以停止租赁。

这种基于SaaS模式的软件服务方式，大大减轻了缺乏资金和IT人才的中小企业的压力。同时，软件厂商在推广和销售软件产品时，无需投入巨大的营销成本和后期维护成本，也无需为多个用户维护多套软件产品的怪问题，减轻了用户的负担。软件维护人员。 SaaS模式的四个基本要素是：互联 平台、 络存储、按需付费和多租户。

1.2 多租户概念

多租户是指多个企业用户（SaaS 模型中的习惯性租户）共同使用部署在软件供应商服务器上的应用程序实例。供应商提供一套软硬件资源， 络设备进行运行管理和资源维护。对租户的规模效应大大降低了软件运营成本。多租户是SaaS最重要的核心概念和关键技术之一。

1.3 成熟度模型

根据SaaS应用是否具有可配置性、高性能、可扩展性等特点，将SaaS成熟度模型分为四个层次。

第一级：定制开发，这是SaaS应用成熟度的第一级。每个租户对应一个单独开发的软件实例。与传统模式几乎没有区别，最大的区别在于商业模式，即SaaS提供商负责软件、硬件和相应的维护。

第二级：可配置，在第一级的基础上改进。每个租户仍然对应一个单独的软件实例，但厂商只提供一组代码，通过不同的配置灵活满足每个租户。

第三层：高性能多租户架构，提出多租户的概念，多个租户共享同一个运行实例。这种多租户单实例架构更接近于真正的SaaS 应用架构。降低硬件和维护成本，发挥SaaS应用的规模效应。

第四层：可扩展的多租户架构，增加中间调度层，将多个租户分配给多个运行实例，通过多个运行实例共享大规模租户访问。这种硬件成熟度和租户数量可以无限增加，是最理想的SaaS架构。

2 SaaS软件关键技术

2.1 多租户模式下的数据存储

SaaS软件与传统软件相比，最大的不同就是多租户模式。多个租户共享同一个软件实例，租户数据既隔离又共享。根据多租户模型的特点，选择了3种数据存储方案。

场景1：独立数据库。该数据存储方案将每个租户的数据信息存储在独立的数据库中，是实现SaaS数据隔离最便捷的方式，一个租户的数据模型变化不会影响其他租户的数据，安全性高好的。但是这种方案大大增加了数据库的安装成本，而且有多少租户就有多少数据库。这种数据存储方案适合银行、医院等对安全性要求较高的企业，但显然不适合资金匮乏的中小企业。

选项2：共享数据库。独立模式，每个租户共享同一个数据库，但每个租户都有一个独立的数据库模式，这意味着每个租户都有一组不同的数据表结构。当新租户创建时，系统会相应地创建一个默认的表结构，并与独立的数据库模式建立关联关系。多个租户的数据可以存储在一个数据库中。与独立数据库相比，虽然建库成本降低，并且存在一定程度的数据隔离，但在发生故障时很难恢复数据和数据统计。选项3：共享数据库。

共享架构，即所有租户共享一个数据库，共享同一套数据表结构。一张数据表存储了所有租户的数据信息，每个租户的数据通过TenantID字段进行区分。这种方案是共享程度最高、隔离程度最低的数据存储方式。该解决方案还具有最低的硬件维护和购买成本，并且每台数据库服务器支持最多的租户。这种方式非常适合大型中小型企业的租户。因此，下面将详细研究该方案下的关键技术。

2.2 共享数据库共享架构的多租户模式

(1) 多租户技术

多租户技术是SaaS服务模式与传统模式最本质的区别。实现SaaS模型成熟度模型的必要条件是解决数据的隔离，实现多租户模型。在SaaS模式下建立多租户，需要在业务表中增加一个TenantID字段来区分每个不同的租户，保证每个租户数据的安全。如表1所示。

通过TenantID字段获取对应租户的业务数据。当系统使用租户的业务数据时，需要添加’TenantID=? ‘条件来执行业务数据操作。

(2) 数据扩展技术

为了满足不同租户的不同需求，SaaS软件必须能够保证数据的可扩展性。多租户模式满足了大规模租户对数据的个性化需求，最常见的解决方案是实现扩展数据的可配置性。实现数据可配置性的常用方案有以下3种。

方案一：自定义字段，是在每个租户共享的数据表中添加相应的自定义字段，以根据租户的需要保存扩展数据。该方案的数据扩展非常简单，但其可扩展性非常有限。当租户数量达到一定数量时，表中会添加很多字段，每个租户添加的字段对其他租户毫无意义，损坏严重。表的结构，一些扩展字段可能为空，浪费表空间。

选项2：预分配字段。该方法在表格中提供了一定数量的预设字段。当租户想要扩展数据时，他们从表格中选择合适的预设字段进行扩展，但不同的租户选择相同预设字段的含义。大概不一样吧。例如，表2 中的TenantID 字段区分了每个租户。除了一些固定字段外，还提供了一些预分配字段。 Ext1、Ext2 和Ext3 是预先分配的字段。预分配字段的使用由租户自己保留。字符串类型，可以使用元数据表跟踪其真实类型。点击图片查看大图

表2 预分配字段方案表结构

该方案虽然可以满足可配置性和可扩展性的要求，但预留的空间浪费太多，预设太少，无法满足租户的需求。

方案3：名称-值对，该方案使用单独的表来存储扩展数据。扩展表将数据表的水平扩展列转换为垂直扩展数据集，为每个原始数据记录设置一个扩展字段，并作为记录保存在扩展表中。将数据表中的数据记录与元数据表中的配置记录关联起来，形成扩展数据记录。如图1所示。

虽然这种方案很好地达到了多租户数据扩展的灵活性要求，但增加了查询、更新记录等数据库操作的复杂度，每次操作都涉及到多个表间的关联，因此该方案也有待优化。

方案4：XML共享模型的数据扩展，这种方案在数据表中采用一种XML数据类型字段来存储租户间的数据。当今主流的关系数据系统都支持XML数据的存储和管理，并提供了很多函数来直接对XML文档节点进行管理。下面以Oracle数据库系统为例。

表结构：TableName(TenantID,Col1,Col2,,XMLDataField),其中www.huisheliren.com TenantID、Col1、Col2字段是所有租户共用的字段；XMLDataField字段存储租户特有的异构数据，其格式完全遵循XML的格式。设计XMLDataField字段的格式如下：

value1

value2

value3

……

XML文档中每个子节点代表租户的一个扩展列，包括列名、列的数据类型、列所对应的值等信息。每增加一个扩展列就在相应的XML文档中添加一个子节点，满足租户对数据扩展的个性化需要。

使用XML字段作为数据扩展方案，对扩展数据的操作简单，不需频繁地多表连接，可以灵活地满足多租户模式下的异构数据的定制，提高了性能。该方案的使用需要在系统的架构模式中添加一层对XML数据进行解析再呈现给客户以及对客户数据封装成XML数据再保存到数据库中。

2.3 多租户模式下的功能可配置

SaaS软件所强调的是“按需使用，按需付费”。在SaaS模式下，租户根据自己不同的需求来使用同一软件，则需达到可配置性要求。实现功能的可配置，可采用如图2所示的四级表结构。

点击图片查看大图

图2 四级表结构

每个租户对应一个预设的功能模式，预设了租户的基本功能。功能模式由多个原子功能构成。租户表存储租户的相关信息，TenantID：租户的唯一标识;UserName：租户的登录账 ；Password：租户的登录密码;PatternNo：租户使用系统包括的功能模式。功能表存储了系统所有的原子功能相关信息，MENU_No:原子功能唯一标识;MENU_NAME：原子功能的名称。模式表存储了功能模式信息。PatternNo:系统中包括的所有模式标识。MENU_No：功能模式包括的原子功能。模式表可以作为租户选择功能的向导。租户模式功能表存储了租户所拥有的功能的相关信息。租户模式功能表定义了该租户所有的功能信息，该表可以作为租户所拥有的所有功能的查询。

3 SaaS模式下的体系架构设计

如果数据扩展方案采用的是XML数据字段，则需要在此基础上添加一层XML数据处理层，完成对XML数据的解析、封装处理。这样的体系架构可以极大地满足大规模的各种行业的租户，具有极大的可扩展性。SaaS系统体系架构如图3所示。

图3 SaaS体系架构

SASS需要解决的问题：

如何支持不同用户按需向标准数据对象/数据模型添加和定义自定义数据对象/扩展模型

如何结合不同用户的按需特性，满足不同用户在不同业务场景下的需求，从基础到专业

如何在不影响用户现有数据和功能的情况下统一升级平台产品

针对以上问题，我们来一一分析解决方案。

问题一（如何使用统一的数据架构来支持多租户数据安全需求和通用数据存储，以及用户扩展自定义数据对象定义和模型变更，同时保证数据定义级别？不影响业务可用性自己和其他租户的功能）

如果我为每个租户创建一个单独的数据库呢？每个租户都有自己的数据库，既可以满足用户数据安全隔离的需要，也可以满足每个租户自定义的数据需求。虽然这看起来是一个合理的SAAS数据方案，但仔细分析揭示了两个明显的问题。

如果用户需要修改或扩展现有的物理数据模型来进行DDL 操作，势必会影响在线服务的整体可用性，也会影响标准数据模型，可能会影响您使用在线功能的能力。

如果用户可以自定义物理模型的扩展和定制，那么在平台升级模型时，很容易造成物理模型之间的冲突，导致新旧功能失序。

添加一个层（元数据层），将强大的映射问题从逻辑模型分离到物理模型。

首先需要对业务进行建模，对业务进行抽象，定义业务逻辑模型，二次抽象模型，定义逻辑模型定义数据，实现业务模型的数据化，也称为元数据。模型的（逻辑模型的元数据）将模型结构存储为数据，而不是直接对应的物理存储结构。

二、根据定义的元数据，即将数据对象定义数据和数据对象数据内容数据的存储结构进行整合抽象，形成元数据逻辑模型

将元数据的逻辑模型映射到元数据的物理模型，对应实际的存储结构

业务逻辑模型与物理模型的解耦是通过将业务模型更改为更改元数据层中的数据而不是更改物理结构来实现的。

看似简单的事情，其实是一个非常大的系统工程，实施起来非常困难，更难取得可靠的成功。 Salesforce 不仅取得了成功，而且达到了极致。让我们站在巨人的肩膀上，看看Salesforce 如何通过元数据驱动的架构（其核心是基础数据架构）平台支持多租户SAAS 业务