当你公司的系统解决了基本温饱，持续高速发展进入展望未来阶段的时候，此时公司高层开始考虑SASS层的建设，需要将已经有的业务产品能力抽象化，对外开放提供这样的能力
SAAS 化输出的关键是如何对不同的用户通过标准+扩展能力按需进行算力、数据、安全、功能有效定制，支持多用户共性和个性的问题，解决多租户的问题，同时也涉及到计费和服务水平等相关问题
通常工作中开发的软件都是业务软件，架构也都是业务架构。业务架构不像技术架构那么通用，在特定的领域里为特定的业务场景而诞生。大家的日常工作也基本上围绕着业务需求进行，为了提高支持业务的效率，元数据驱动应运而生了
元数据就是计算机的认知维度，可以说，掌握了元数据就掌握了信息的维度，只有充分利用好元数据（也就是信息的维度），通过合理的元数据建模（维度整合），对元数据进行科学管理（维度完善），才能让让计算机更好地认知企业系统
SASS需要解决的问题：
- 如何支持不同用户在标准的数据对象/数据模型上按需添加定义自定义的数据对象/扩展模型
- 如何按照不同用户进行按需功能搭配组合，满足不同用户从基础到专业级不同业务场景需求
- 如何统一对平台产品进行升级而不影响用户已有数据及功能
针对上述问题我们一个个分析解决方案：
- 问题1（如何以一套统一的数据架构即能支撑多租户的数据安全性需求以及通用的数据存储，也能支撑用户扩展的自定义数据对象定义和模型变更，同时也要保证数据定义层面的扩展和变更不会影响自身和其他租户的业务功能的可用性）
如果为每个租户创建各自的数据库呢？各自租户拥有各自的数据库，可以满足用户数据安全隔离的需求，也可以满足各租户自定义的数据需求，看上去像是一种合理的 SAAS 数据方案，但是仔细分析，发现有两个明显的问题：
- 如果用户需要修改或者扩展现有物理数据模型而进行的 DDL 操作，必然会影响线上业务的整体可用性，也可能会影响到标准数据模型，从而影响到线上功能使用
- 如果用户可自定义对物理模型进行扩展和定制，当平台进行模型升级的时候，极容易产生物理模型的冲突，导致新旧功能异常
增加一个层次(元数据层)来解耦逻辑模型到物理模型强映射的问题：
- 首先，我们需要对业务进行建模，对业务进行抽象，定义出业务逻辑模型，然后对模型进行二次抽象，定义出逻辑模型的定义数据，实现业务模型的数据化，也叫模型的元数据(the metadata of the logic model )，将模型结构存储为数据，而不是直接对应的物理存储结构
- 其次根据定义出的元数据，也就是对数据对象定义数据，数据对象数据内容数据的存储结构进行统一抽象，形成元数据逻辑模型
- 将元数据逻辑模型映射到元数据物理模型，对应实际存储结构
- 通过对业务模型的变更变成了对元数据层的数据的变更，而不是物理结构的变更，来实现业务逻辑模型同物理模型的解耦
很多事情说起来好像挺简单，实际上是一个非常巨大的系统工程，将其付诸实践是挑战非常大的事情，而取得踏踏实实的成功更难，上述的解题思路是 Salesforce 的解题思路，而且 Salesforce 不仅取得了成功，而且接近将其做到的极致，下面我们站在巨人的肩膀上来看看 Salesforce 如何通过元数据驱动的架构（核心是基础数据架构）来支撑多租户的 SAAS 业务平台的
一、多租户意味着什么？
多租户的含义用一句话来描述就是：一个云平台，无数多个客户。
一个云平台的含义是：一个代码库，一个数据库，一整套共享的可扩展服务包括数据服务、应用服务以及 Web 服务。
无数多个客户的含义是：每个客户都被分配一个唯一的租户 OrgID，所有的数据存储都是按照租户 OrgID 隔离的，所有的数据访问必须包含 OrgID，所有的操作也都是包含租户 OrgID 的，也就是所有的客户数据和行为都是被安全的通过唯一的租户 Org 进行严格的隔离的。
每个租户/组织只能看到和定义按照自己租户 OrgID 隔离的它自己版本的元数据和数据，而且只能执行自己租户 OrgID 所授权的行为，这样每个租户就拥有各自版本的 SAAS 方案
二、元数据驱动意味着什么
元数据对于平台意味着平台数据的数据，对于租户意味着是关于租户数据的数据，
当用户定义一个新的用户表的时候，用户创建的不是数据库中的物理表，而是在系统态的元数据表中添加了一条记录，这个记录描述的是用户表的逻辑定义，是虚拟的，这个表并不在数据库中物理存在，而这条记录代表就是用户态的数据表。
当用户定义了用户表的一个新的字段时，用户并没有在物理表中创建物理字段，而是在系统态的元数据表中添加了一个记录，这个记录描述的用户表的字段组成的逻辑结构，是虚拟的，这个字段也不再数据库中表结构中物理存在，而这条记录代表的就是用户态的用户表字段。
也就是通过存储在系统态的元数据表的元数据记录来作为虚拟用户的数据库结构
三、元数据驱动的多租户整体架构
我们先来大概了解下元数据驱动的多租户架构的整体架构，整体架构大概分为 5 个大的逻辑层次：
1. 底层数据架构分为三个层次：
- 最底层是数据层，存储了离散的系统和用户的业务数据，业务日常运营的数据存储在这里。
- 公共元数据层，存储了应用系统标准的对象和标准的字段定义，对底层数据的结构进行定义说明
- 租户特定元数据，存储了租户自动的对象和自定义的字段的定义，用于对底层的数据的结构进行定义说明。
2. 通用数据字典 UDD(Universal Data Dictionary)运行引擎层实现了应用对象到底层数据存储的映射，包含对象模型操作、SOQL 语言解析、查询优化，全文搜索等功能，我们常说的 ORM 功能也是其核心功能，但比其复杂的多。
3. 平台服务层，提供 PAAS 层平台服务，提供应用对象模型的创建，权限模型创建，逻辑和工作流程创建以及用户界面的创建包括屏幕布局，数据项，报表等
4. 标准应用层，提供端到端的标准的业务应用功能。
5. 租户虚拟应用层，用户可以在标准应用层或者平台服务层之上定义自己特有的业务应用功能，来满足自己特定的业务场景需要。
四、元数据驱动的多租户数据架构概览
首先，我们先来大概了解下元数据驱动的多租户模型的核心内容，元数据驱动的多租户的数据模型主要分为三个部分：元数据表、数据表和功能透视表。
1. 元数据表(Metadata Tables)
元数据表用于存放系统标准对象以及用户自定义对象和字段的定义的元数据，也就是系统和用户对象的逻辑结构暨对应于关系数据库中的虚拟表结构。元数据表主要包括 Objects 表以及 Fields 表，是系统标准对象和用户对象定义数据的仓库，元数据仓库。
2. 数据表(Data Tables)
数据表用户存放系统以及用户对象和字段的实际数据，实际的用户业务数据以及应用系统相关数据存放在这里。数据表包括 Data 表和存放大文本数据的 Clob 表。数据表存储了绝大部分用户的实际数据，是一个巨大的用户业务数据仓库。
3. 功能透视表(Specialized Pivot Tables)
功能透视表包含了非常关键的关系表、索引表、关系表以及其他特定用途表。例如关系表定义了对象间的关系，索引表解决虚拟结构索引的问题，后续进行详尽的叙述。