共计 3775 个字符，预计需要花费 10 分钟才能阅读完成。
引言
作为业务零碎技术开发同学，面向当下：
首先应该是疾速搭建业务通路，让线上业务跑起来，疾速试错，解决生存问题；
第二步是在链路畅通、业务根本跑起来的根底上，如何撑持业务跑得更快，就须要解决快速增长问题；
第三步，在实现撑持业务快速增长的根底上，要进行精细化晋升，通过在撑持业务快跑间隙挤时间打磨零碎性能和体验，踏踏实实花工夫去形象能力，积淀产品，晋升效力；
同时咱们也必须面向未来，如何在形象能力以及积淀了产品的根底上，把所承载和积淀的业务能力疾速输入，奉献给整个行业，或为整个社会商业生态提供基座撑持。面向未来，将平台产品进行 SaaS 化降级，真正将能力进行有价值凋谢输入是咱们提前要布局的外围方向。
将平台产品进行 SaaS 输入，须要解决那些问题呢？这里尝试把外围问题列举一下：
如何依据不同用户需要进行计算能力按需调度调配？（IaaS/PaaS）
如何满足用户数据安全性要求，严格隔离不同用户的数据，使用户只能看到本人的数据？（PaaS）
如何反对不同用户在规范的数据对象 / 数据模型上按需增加自定义的数据对象 / 扩大模型？（PaaS & SaaS）
如何依照不同用户进行按需性能搭配组合，满足不同用户从根底到专业级不同业务场景需要？（SaaS）
如何对立对平台产品进行降级而不影响用户已有数据及性能？（IaaS、PaaS、SaaS）
通过以上问题，咱们能够看出，产品 SaaS 化输入的要害是如何对不同的用户通过规范 + 扩大能力按需进行算力、数据、平安、性能无效定制，反对多用户共性和共性的问题，即多租户的问题，同时也波及到计费和服务水平等相干问题。咱们上面来聊下上述问题的解题要害和解题思路：
第 1 个算力问题的外围是调度问题，弹性计算提供在 IaaS 层的对立算力调度能力，而 Serverless 则能够在 PaaS 层提供更高层次的算力调度能力。
第 4 个问题的外围是业务流程的形象和业务性能的拆分。畛域驱动设计以及服务化 (微服务) 在平台性能形象拆分上提供了绝对成熟的思路，催化了以纵向业务性能细分作为域划分的根据的服务化计划以及组织构造，次要诉求是在细分的业务性能服务根底上，能按需疾速灵便的组合，从而撑持不同的业务模式，提供业务敏捷性，撑持业务翻新求变。
当然反过来，因为纵向性能细分，业务功能域增多，整个业务链条上的咬合点越来越多，随之产生越来越多的数据起源冗余反复或者缺失，性能或者重合且各自发散，或者缺失，最终给整体业务带来较多数据远程桌面和性能的不一致性危险。这样一来，不仅横向端到端的业务串联老本高，而且要害门路的危险收敛老本比拟高，矛盾冲突点集中在各纵向域性能和数据咬合处，具体表现为：
数据上：
无主数据，有数据需要无 owner；
大量反复且不统一数据；
性能上：
局部业务性能缺失；
域之间存在业务性能反复且行为不统一。
到底是纵向切分域还是横向分业务模式拉平来做，这个问题没有标准答案，更没有最佳答案。只有依据不同的业务倒退阶段及时动静调整试错，换言之，这是一个一直寻找绝对最优解的动静过程。
弹性计算和 Serverless 解决了算力的问题，畛域驱动服务化设计解决了性能的拆分和按需搭配组合的问题，那么剩下的外围问题就是数据了：如何以一套对立的数据架构，既能撑持多租户的数据安全性需要以及通用的数据存储，也能撑持用户扩大的自定义数据对象定义和模型变更，同时也要保证数据定义层面的扩大和变更不会影响本身和其余租户业务性能的可用性。咱们来剖析下可能的计划（暂不思考按服务边界进行数据库拆分）：
对立的数据库，规范数据模型和扩大数据模型间接映射到物理表和索引：很显然，对于不同租户自定义的数据对象和数据模型要求是无奈撑持的，物理数据模型会互相烦扰、互相抵触直到无以为继。即便是对于所有租户齐全规范的性能和数据存储，平台本身的规范模型降级的 DDL 也会对用户的可用性造成较大影响，所以显然是行不通的。
如果为每个租户创立各自的数据库呢？各自租户领有各自的数据库，能够满足用户数据安全隔离的需要，也能够满足各租户自定义的数据需要，看上去像是一种正当的 SaaS 数据计划。然而仔细分析，会发现有两个显著的问题：
如果用户须要批改或者扩大现有物理数据模型而进行的 DDL 操作，必然会影响线上业务的整体可用性，也可能会影响到规范数据模型，从而影响到线上性能应用。
如果用户可自定义对物理模型进行扩大和定制，当平台进行模型降级的时候，极容易产生物理模型的抵触，导致新旧性能异样。
因为用户在各自数据库存在各自定义的扩大和定制，则平台数据模型和性能降级须要针对不同的租户进行别离验证，存在极大的降级验证工作量和危险。
以上两种计划可行性低，咱们从其中发现的问题是：平台业务零碎的逻辑模型到物理模型的间接映射是造成问题的次要因素。既然物理模型的变更是平台不稳固的动因，那么咱们是否能通过解耦业务逻辑模型和物理模型的映射关系来尝试解决这个问题呢？
既然问题曾经定义分明了，如何解决这个问题呢？通常咱们解决架构问题的一个“万能”的办法是：减少一个档次，咱们也来套用一次，减少一个档次（元数据层）来解耦逻辑模型到物理模型强映射的问题。
首先，咱们须要对业务进行建模，对业务进行形象，定义出业务逻辑模型，而后对模型进行二次形象，定义出逻辑模型的定义数据，实现业务模型的数据化，即模型的元数据(The Metadata of the Logic Model)，将模型构造存储为数据，而不是间接对应的物理存储构造。
其次依据定义出的元数据进行对立形象，造成元数据逻辑模型。
将元数据逻辑模型映射到元数据物理模型，对应理论存储构造。
通过对业务模型的变更，造成对元数据层的数据变更，而不是物理构造的变更，从而实现业务逻辑模型同物理模型的解耦。
很多事件说起来如同挺简略，实际上是一个十分微小的系统工程，将其付诸实践是挑战十分大的事件，而获得踏踏实实的胜利则更难。上述问题的解题思路是 Salesforce 的解题思路，而且 Salesforce 不仅获得了胜利，也靠近将其做到了极致，上面咱们站在伟人的肩膀上来看看 Salesforce 如何通过元数据驱动的架构（外围是根底数据架构）来撑持多租户的 SaaS 业务平台。
留神：因为 Salesforce 并未有对外围实现逻辑进行齐全公开和阐明，所以本文所整顿的局部外围逻辑蕴含了作者的逻辑推理和解读，然而的确进行了逻辑验证和场景验证，如有纰漏和不全面的中央，欢送探讨及斧正。
元数据驱动的多租户架构
Salesforce 将 http://Force.com 定义为 PaaS 平台，http://Force.com 的根底就是元数据驱动的软件架构来撑持多租户利用。首先我来解释下什么是以元数据驱动的软件架构为外围。
一、多租户意味着什么
多租户的含意用一句话来形容就是：一个云平台，有数多个客户。
一个云平台的含意是：一个代码库，一个数据库，一整套共享的可扩大服务，包含数据服务、应用服务以及 Web 服务。
有数多个客户的含意是：每个客户都被调配一个惟一的租户 OrgID，所有的数据存储都是依照租户 OrgID 隔离的，所有的数据拜访必须蕴含 OrgID，所有的操作也都是蕴含租户 OrgID 的，也就是所有的客户数据和行为都是被平安的通过惟一的租户 Org 进行严格隔离的。
每个租户 / 组织只能看到和定义依照本人租户 OrgID 隔离的本人版本的元数据和数据，而且只能执行本人租户 OrgID 所受权的行为，这样每个租户就领有各自版本的 SaaS 计划。
二、元数据驱动意味着什么
元数据对于平台意味着平台数据的数据，对于租户意味着是对于租户数据的数据。
当用户定义一个新的用户表的时候，用户创立的不是数据库中的物理表，而是在零碎态的元数据表中增加了一条记录，这个记录形容的是用户表的逻辑定义，是虚构的，这个表并不在数据库中物理存在，而这条记录代表就是用户态的数据表。
当用户定义了用户表的一个新的字段时，用户并没有在物理表中创立物理字段，而是在零碎态的元数据表中增加了一个记录，这个记录形容的用户表的字段组成的逻辑构造，是虚构的，这个字段也不在数据库表构造中物理存在，而这条记录代表的就是用户态的用户表字段。
也就是通过存储在零碎态的元数据表中的元数据记录作为虚构用户的数据库构造。
三、元数据驱动的多租户整体架构
咱们先来大略理解下元数据驱动的多租户的整体架构，整体架构大略分为 5 个逻辑档次：
底层数据架构分为三个档次：
最底层是数据层，存储了离散的零碎和用户的业务数据，业务日常经营的数据存储在这里。
公共元数据层，存储了利用零碎规范的对象和规范的字段定义，对底层数据的构造进行定义阐明。
租户特定元数据，存储了租户主动的对象和自定义的字段定义，用于对底层的数据结构进行定义阐明。
通用数据字典 UDD(Universal Data Dictionary) 运行引擎层实现了利用对象到底层数据存储的映射，蕴含对象模型操作、SOQL 语言解析、查问优化，全文搜寻等性能，咱们常说的 ORM 性能也是其外围性能，但比其简单的多。
平台服务层提供 PaaS 层平台服务，提供利用对象模型的创立，权限模型创立，逻辑和工作流程创立以及用户界面的创立，包含屏幕布局、数据项、报表等。
规范应用层提供端到端的规范的业务利用性能。
租户虚构应用层，用户能够在规范应用层或者平台服务层之上定义本人特有的业务利用性能，满足本人特定的业务场景须要。
