如何以最小成本将传统应用快速SaaS化

SaaS交付模式正越来越受到人们的认可。软件企业通过应用SaaS化将会变得更加敏捷、更快速地响应市场需求并且可以通过共享基础设施降低运营成本。然而，现实情况是目前很多企业在传统应用方面已经进行了大量的投资，完全抛弃传统应用，重新开发标准意义上的SaaS化应用，则意味着既有投资的大量浪费。那么，我们是否可以找到一种方法，在尽量少的改变现有应用，保护既有投资的前提下进行应用的快速地SaaS化呢？

重新定义多租户

SaaS化的核心是多租户。一般意义上，多租户意味着所有的租户运行在同一套基础设施之上。SaaS化带来的众多收益，如成本的降低、统一的部署与管理、快速的交付 -- 都依赖于租户共享一套基础设施这一点。

但是，这种多租户的定义并不适用于所有的应用与企业。笔者认为，多租户可以分为多种程度的多租户化：

01

把软件系统的部署及运营职责从用户迁移到租户

02

多租户共用同一套基础设施，但在一套基础设施内部，仍然运行在不同的服务器或虚拟机之上

03

多租户的系统运行在同一个应用的多个实例之上，多租户的个性化通过配置来保证。虽然上述三种层次的多租户的共享程度不同，但从租户及用户的角度来看，提供了完整的以多租户为核心的SaaS体验

当然，对于SaaS提供者来说，上述三种层次的多租户实现方式由于共享共用基础设施的程度不同，带来的系统的运营成本及运营效率有很大的差别。但是共享效率高的多租户方式依赖于对既有应用进行更深程度的重构与改造。SaaS提供商应该根据应用特性、租户需求的差别程度、需求的紧迫程度等选择合适的多租户实现方式。

分析现有应用

虽然现实中有多种多样的传统应用，但这些应用的设计与实现大多遵循着一定的架构模式。如网站应用遵循LIMP、Java应用遵循J2EE、STRUTS、SpringMVC、Spring Boot等框架。

下面我们以最经典的三层架构的B/S应用为例来分析如何进行SaaS化改造。

这种架构下，除了通用的负载均衡层以外，应用系统通常包括三层：

Web层

负责将用户请求转换并分发给Web服务器

应用层

负责处理应用的具体业务逻辑，并访问数据库

数据库层

存储业务数据，通常运行在单独的存储层

（通常在应用层与存储层之间还有一个数据访问层，在此我们把它包含到应用层中）

目前，绝大多数的应用基于上述的三层架构进行开发与实现。部分应用可能会有一些微小的变化，如增加单独的缓存层、数据访问层等，但其基本设计跟上述架构相同。

软件提供商根据客户的需求进行定制化开发之后交付给客户。客户们通常将这些应用运行在独立的基础设施环境中，并且不同的客户可能运行不同的版本的应用。在客户的部署实例中，随着用户量或业务量的增加，如果我们发现性能瓶颈发生在应用层，那么我们一般只能通过增加应用服务器来解决性能问题，而不能通过增加瓶颈发生的具体模块的实例来解决问题。

低成本低风险的改造策略

现在我们的问题是：在不整体改变现有应有的架构与设计的前提下，如何将应用改造成SaaS模式？在不重写整体解决方案的前提下，如何引入多租户？如何实现部署自动化等SaaS特性？

SaaS化改造策略的核心

每个租户在单独的基础设施上独立地运行完整的应用（包括Web层、应用层及存储层），在此基础上为各租户提供统一的用户登陆、用户认证与授权、租户配置、服务配置、数据访问、日志、计量等SaaS要求的通用特性。

这种改造策略主要包括以下方面：

01

无需对原有系统的架构与代码进行根本性修改，为每个租户启动一个完整的应用系统，并确保该系统正常地运行

02

多租户共用同一套基础设施，但在一套基础设施内部，仍然运行在不同的服务器或虚拟机之上

在所有租户的应用系统之上，增加一个SaaS框架层。具体包括以下工作：

1）创建统一的用户登陆认证界面；

2）创建自动构建新租户的脚本，包括租户申请、租户资源及基础设施初始化、应用的部署与初始化配置；

3）根据具体需求，实现SaaS通用特性，包括用户认证与授权、租户配置、服务配置、数据访问、日志、计量等；

4）创建与配置路由，根据用户所在的租户将请求转发到对应租户的独立应用系统之中。

结束语

该SaaS化改造方式无需对既有代码进行修改，只是将原来由客户负责运维与管理的应用系统转变为由软件提供商来运营，然后在各应用系统之上增加一层SaaS框架层，实现SaaS所需的基本特性。其代价最小，速度最快，试错成本低。如果我们不想承担完全SaaS化的成本与风险，又共享基础设施的改造成本太高，工期太长，而又希望能够快速地为客户提供SaaS服务，那么这种模式应该是最适合的。

END