详解：Salesforce元数据支撑SASS架构设计

当你公司的系统处置了根本温饱，持续高速开展进入瞻望将来阶段的时候，此时公司高层开端考虑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)
功能透视表包含了非常关键的关系表、索引表、关系表以及其他特定用处表。例如关系表定义了对象间的关系，索引表处置虚拟构造索引的问题，后续停止详尽的叙述。