【Salesforce多租户&元数据在生态用工落地总结(from 玉霄)】

背景

15-19年自己一直在做电商相关的开发，去年从电商域转向做2B的企业管理软件。企业管理软件我并不陌生，第一份工作就是办公软件开发，负责电信的信息平台EIP（Enterprise Information Portal），主要包括门户、OA、SSO单点登录、工作流。这些内容跟企业智能的 阿里内外、BUC、ACL、主数据从技术视角看基本一致，只是技术完善度不同而已。

2B 2C的差异

曾经看过一篇文章分析2B和2C，从下面3点做了分析：

**面向的对象 —> 客户与用户
****产品特点—>**工具与玩具

商业模式 —>__卖身与卖艺

这个比较非常的贴切能够感受到两者产品明显的差异。

从技术角度比较下2B和2C的差异：

1. 客户与用户，2B和2C总用户量 都很大，但2B客户对数据隔离、权限区分要求更高。
2. 工具和玩具，2B强调效率、扩展、定制 ，2C强调体验、性能、并发。
3. 卖身与卖艺，2B会要求独立部署、独立交付，2C大家共用一个统一服务通过附加值收费。 # 技术问题 理解了2B和2C的差异那么技术上我们最需要解决的问题就比较清晰了。

• 多租户
• 高扩展
• 快速迭代

明确了技术上的诉求，结合目前市面NB的SAAS软件商的技术架构。元数据结合多租户的设计能够解决大部分我们遇到的问题。

数据隔离多租户方案

首先，多租户根据不同的隔离等级可以分为三种：

• 独立数据库
• 独立 Schema 共享数据库
• 共享数据表

独立数据库

每个租户一个数据库。

• 优点：为不同的租户提供独立的数据库，有助于简化数据模型的扩展设计，满足不同租户的独特需求；如果 出现故障，恢复数据比较简单。
• 缺点： 增多了数据库的安装数量，随之带来维护成本和购置成本的增加 这种方案与传统的一个客户、一套数据、一套部署类似，差别只在于软件统一部署在运营商那里。由此可见此方案 用户数据隔离级别高，安全性好，但是成本较高

共享数据库 独立 Schema

共享数据库、独立 Schema：即多个或所有的租户使用同一个数据库服务（如常见的ORACLE或MYSQL数据库）， 但是每个租户一个Schema。

• 优点： 为安全性要求较高的租户提供了一定程度的逻辑数据隔离，并不是完全隔离；每个数据库可支持更多 的租户数量。
• 缺点： 如果出现故障，数据恢复比较困难，因为恢复数据库将牵涉到其他租户的数据； 如果需要跨租户统计 数据，存在一定困难。

这种方案是方案一的变种。只需要安装一份数据库服务，通过不同的Schema对不同租户的数据进行隔离。由于数 据库服务是共享的，所以成本相对低廉。

共享数据表

共享数据库、共享数据表：即租户共享同一个Database，同一套数据库表（所有租户的数据都存放在一个数据库 的同一套表中）。在表中增加租户ID等租户标志字段，表明该记录是属于哪个租户的。

• 优点：所有租户使用同一套数据库，所以成本低廉。
• 缺点：隔离级别低，安全性低，需要在设计开发时加大对安全的开发量，数据备份和恢复困难。

这种方案和基于传统应用的数据库设计并没有任何区别，但是由于所有租户使用相同的数据库表，所以需要做好对 每个租户数据的隔离安全性处理，这就增加了系统设计和数据管理方面的复杂程度。

我们的选择

最终我们选择支持第一种、第三种