先自我介绍一下哈，本人拥有17年的IT服务经验。从2011年开始从事Salesforce项目咨询与实施工作。最近几年呢，我一直都在研发一些自己的产品，同时也给一些大厂提供一些咨询服务。所以我自认为对Salesforce平台的产品与功能，以及其底层的架构与设计思想还是研究得比较深的。

我打算分几期的篇幅，来具体探讨一下这个平台底层架构的设计原理，其中我也会加入自己的一些思考。因为Salesforce的架构是十几年之前做的，现在的环境以及各种新技术与框架已经发生了比较大的变化。为了方便理解，我简化了一些比较复杂的概念，只保留了最核心的概念与原理。

说起低代码平台，我觉得首先要讲两个原理：一个是多租户，另外一个是元数据驱动。

多租户

简单来说，就是所有客户（租户）的系统都运行在一台服务器、一个数据库、一套代码上。当然我是把这个概念简化了，现实情况往往会更复杂，后续我们会把这一部分补回来。

元数据驱动

我们大家都知道，业务数据指的是客户、联系人、业务机会、合同等这类跟业务发生关联的数据。而元数据则指的是对象，字段，页面布局，验证规则，工作流等这类定义应用本身的数据。这也是低代码平台相对于传统应用底层数据结构的最大区别。传统应用底层数据库都是实体死表，而低代码平台为了应用程序的可配置性，全部都是使用的活表。

多租户的实现原理

多租户有时候听起来比较玄乎，但是我觉得它的实现原理其实非常简单。主要是有2张表：User 和 Organization。User表记录所有客户（租户）的所有用户，除了Username、Password这类基本的信息，还有它所属的租户（Organization）的信息（关联到Organization表）

Organization表则记录了所有客户（租户）的信息，除了一些常规的信息例如名称，购买License数量，到期日期之外，还有这个租户所处主机的子域名。

用户登录时，先验证Username与Password这类常规的信息，登录成功之后再重定向到它Organization的主机。从此之后，他只与这台主机发生关系。

元数据驱动的实现原理

理论上来说，我们只需要3张表就可以实现所有客户（租户）的所有需求。

Object、Field、Data



Object表记录了所有租户所有的对象（表），包含Object自己。

Field表记录了所有租户所有对象上的所有字段，每个字段的类型，长度等信息。

Data表则记录了每个Object的实例化（记录）。

Salesforce在早期使用的是Oracle数据库，Data表上有500个字段，依次为Value0，Value1...Value500。每个Object上的Field都有个唯一编号：0，1，2...500。每条Data记录只能属于一个Object（见图中的ObjID），然后Value0就是第一个字段的值，Value1就是第二个字段的值，以此类推。

通用数据访问接口

归根到底，任何应用系统的最终结果只是增删改查。所以在低代码平台的设计里，我们就把这个操作高度抽象化了。意思是，任何租户的任何对象的任何记录的增删改查，都是一套代码。通过通用数据访问接口，代码就可以对比Object和Field表里相应的记录来控制任何对象记录的读写。

新增

用户需要提供一个JSON格式的数据结构，指定你要新增的是哪个Object，每个字段的APIName和Value分别是什么。代码会把用户提供的Object，Field，以及它们的Value，和系统里的Object和Field的定义进行比对。如果有问题，则返回错误。否则就保存记录，成功插入一条Data表记录并返回记录的Id。

删除

需要指定记录的Id，如果Id存在就设置IsDeleted=1（软删除），否则就报错。

编辑

与新增一样

查询

需要指定记录的Id。如果Id在Data表里存在，就结合Field表返回该条记录所有字段以及它们的值，否则就报错。

为了简单，我们这里说的都是单条记录的操作，批量记录的操作我们会在后续的文章里再做分析。

使用No SQL数据库

我上面说的，都是Salesforce底层的架构设计。但有一点需要考虑的是，Salesforce的工程师们在最初设计这个产品的时候，他们使用了Oracle数据库，他们搞了一个有500个字段的Data表。他们那样搞是可以的，因为Salesforce早期的工程师都是Oracle数据库的核心研发人员，都是一帮玩数据库的高手，他们为了做这个架构已经改了很多数据库底层的设计。但我们如果这样搞的话那就死翘翘了，因为我们肯定很快就会遇到性能问题。

所以我们大可不必使用它的这个设计。我们可以使用No SQL数据库例如MongoDB。由于MongoDB本身就是key/value这样保存记录的文本型数据库，同一个表里不同记录的字段以及类型都可以不一样，所以我认为No SQL数据库是天生适合做低代码平台的数据存储的。

我们还是需要Object和Field表，为了简单我还是继续使用SQL数据库的术语：表、字段、记录，而不是MongoDB的术语：集合、字段、文档。

通过通用数据访问接口，我们可以通过对比Object和Field表里相应的记录来控制对象记录的读写。但是我们是把所有的记录都放在一个Data表，还是分对象拆分为多个表？Salesforce是前者，但是我倾向于后者。就是说，根据Object和Field表来生成每个对象的记录表。这样比较方便后续创建索引，以提高查询效率等。但是所有表和字段的操作都是通过通用数据访问接口，而不是像传统应用那样手动操作。

所有租户一个数据库，还是每个租户一个数据库？

Salesforce使用了前者，然后每条记录上都有一个OrgId字段来标识这条记录属于哪个Org。但是我个人还是倾向于后者。但是所有表的写入，都是通过通用数据访问接口，而不是手动操作数据库。

我的思路是这样。

一个总的数据库：User、Organization

每个租户一个数据库，使用OrgId来命名。

创建（初始化）一个租户（Org）时，程序自动创建User、Organization记录。然后创建一个以OrgId来命名的数据库。然后把母板里的元数据（Object、Field、Data、PageLayouts等等）拷贝到新Org。所谓母板，指的是创建Org时你选择的行业模板，其实它就是一个现有的租户。

当用户成功登录之后，我们就知道他的OrgId，于是我们就把他重定向到他的数据库。

总结一下

在这篇文章里，我们讨论了Salesforce低代码平台底层的一些最核心最基本的设计思想，解释了多租户和元数据驱动的概念。相对于Salesforce的架构，我们也提出了一些自己的实践与想法。文章里提到的一些方法，都是我们自己在做产品的过程中用到并且经过检验过的。如果你有什么问题或者建议，可以给我留言或者联系我。