关于私有部署的一些方案思考

大客户私有部署的SaaS方案思考

概述

近来公司需要给大客户做私有部署，由于客户分公司较多，业务广泛，集团希望共享客户资源，统一服务流程，共享监控数据和统计数据，需要我们这边深入考虑部署方案。
　　目前我们使用的SaaS架构是多租户中的第三种方案，即共享数据库，共享 Schema，共享数据表。如果你不了解神码是SaaS？请移步维基百科详细查阅（软件即服务-SaaS）。简单来说是实现了在多用户环境下（此处的多用户一般是面向企业用户）共用相同的系统或程序组件，并且可确保各用户间数据的隔离性，由厂商提供统一托管和升级，是云计算时代的产物。由于绝大多数SaaS解决方案都基于多租户架构，所以有必要先了解下神码是多租户架构。

多租户

软件多租户：指的是一种软件架构，其中一个实例的软件在服务器上运行，并提供多租户。租户是一组用户，他们共享具有软件实例特定权限的公共访问权限。通过多租户架构，软件应用程序旨在为每个租户提供实例的专用共享 - 包括其数据，配置，用户管理，租户个人功能和非功能属性。多租户与单租户（多实例架构）形成对比，其中单独的软件实例代表不同的租户运行。

多租户数据隔离方案

在当下云计算时代，多租户技术在共用的数据中心以单一系统架构与服务提供多数客户端相同甚至可定制化的服务，并且仍可以保障客户的数据隔离。目前各种各样的云计算服务就是这类技术范畴，例如阿里云数据库服务（RDS）、阿里云服务器等等。
多租户在数据存储上存在三种主要的方案，分别是：
　　1. 独立数据库
　　这是第一种方案，即一个租户一个数据库，这种方案的用户数据隔离级别最高，安全性最好，但成本较高。
　　优点： 为不同的租户提供独立的数据库，有助于简化数据模型的扩展设计，满足不同租户的独特需求；如果出现故障，恢复数据比较简单。
　　缺点： 增多了数据库的安装数量，随之带来维护成本和购置成本的增加。

这种方案其实与传统的一个客户、一套数据、一套部署类似，差别只在于软件统一部署在运营商那里。如果面对的是银行、医院等需要非常高数据隔离级别的租户，可以选择这种模式，提高租用的定价。如果定价较低，产品走低价路线，这种方案一般对运营商来说是无法承受的。

2. 共享数据库，独立 Schema
　　这是第二种方案，即多个或所有租户共享Database，但是每个租户一个Schema（也可叫做一个USER）。底层库比如是：DB2、ORACLE等，一个数据库下可以有多个SCHEMA
　　优点： 为安全性要求较高的租户提供了一定程度的逻辑数据隔离，并不是完全隔离；每个数据库可支持更多的租户数量。
　　缺点： 如果出现故障，数据恢复比较困难，因为恢复数据库将牵涉到其他租户的数据，如果需要跨租户统计数据，存在一定困难。

3. 共享数据库，共享 Schema，共享数据表
　　这是第三种方案，即租户共享同一个Database、同一个Schema，但在表中增加TenantID多租户的数据字段。这是共享程度最高、隔离级别最低的模式，即每插入一条数据时都需要有一个客户的标识。这样才能在同一张表中区分出不同客户的数据。
　　优点： 三种方案比较，第三种方案的维护和购置成本最低，允许每个数据库支持的租户数量最多。
　　缺点： 隔离级别最低，安全性最低，需要在设计开发时加大对安全的开发量； 数据备份和恢复最困难，需要逐表逐条备份和还原; 供应商服务不稳定时，一损俱损，全部租户都受到影响。

如果希望以最少的服务器为最多的租户提供服务，并且租户接受牺牲隔离级别换取降低成本，这种方案最适合。 在SaaS实施过程中，有一个显著的考量点，就是如何对应用数据进行设计，以支持多租户，而这种设计的思路，是要在数据的共享、安全隔离和性能间取得平衡。

选择合理的实现模式

了解了这么多，再回到我们业务上来。目前从客户需求上来看，大致有几点重要诉求：

1. 管理层对数据共享方面倾向度更高，尤其是Boss。
2. 监控和统计方面，不同的分公司主要关心自己的业务监控，而Boss想打通整个服务流程。
3. 另外客户有自己的大数据分析平台，希望日后能做数据挖掘。

整体上用户对数据共享要求较高，安全隔离和性能方面，由于是私有部署在自己机房，可以通过硬件升级来实现水平扩容。分公司有些业务差别较大，分开服务商有助于适配自己公司业务，所以比较适合第三种方案。

不同分公司之间想要共享业务流程，可以加入到相同的组（集合）中来。便于数据交流和业务分发，比如IM转接，热线转接，工单流转等。代码上需要改造的是，登录时需要检测是否开启了共享组，读取自己所在的共享组信息。也可以通过配置文件实现功能模块的共享和数据表的共享。

配置文件改动：

; 共享组开关 default 0
shared.switch = 1
;共享服务商列表 
shared.list = 1,2,3,4,5
;共享模块列表 1-im 2-cc 3-tt 
shared.module = 1,2,3
;共享数据表
shared.table = 'user,...'

业务转接时逻辑改动:

<?php
$sharedInfo = array(
      'task_id'=>1001,//主键id
      'task_content'=>'您有一个来分公司1的转接请求’，
      'transfer_reason'=>'来找你的',
      'task_source'=>1//任务来源服务商id
      ...
);

对于im来说，可以做到单向或双向跨服务商转接会话，共享监控数据，统计服务记录。
入口处，只显示本服务商的技能组;
工作台上可以控制多个服务商技能组;
监控处，自行决定是否展示别的服务商数据，默认只展示本服务商的数据;
统计处，同监控。

整体结构大致如下：

实现的效果是，可以自由组合不同服务商，实现数据共享。

另外，如果真的要做组件式的功能，我们需要引入一套ORM框架，实现用户登录就完成功能配置模型的初始化。省去在各个功能处大量的if/else工作。

以上就是我对私有部署，多租户模型共享的理解和方案，如果不合理地方，欢迎指正。

参考：

1. 数据层的多租户浅谈
2. SaaS多租户数据隔离的三种方案
3. 多租户和单租户SaaS的架构对比