SAAS架构设计

目录

• 背景和价值
• 1 租户设计
• 2 灵活用户自定义设计
  • 支持强大的自定义功能
    • 业务流程自定义
    • 数据模型自定义
    • 用户界面自定义
    • 报表和仪表盘自定义
    • 集成与扩展自定义
  • 技术实现：元数据模型
  • 技术点和挑战
    • 1 如何实现自定义报表？数据源有标准实体对象，也有自定义对象
    • 2 自定义对象和标准对象的关联如何解决
    • 3 自定义对象的字段搜索如何解决？
    • 4 如何实现界面自定义
    • 5 如何实现，业务流程自定义？（需要对BPM底层能力非常精通）
  • 元数据模型
    • 抽象出业务模型
    • 第一个版本物理模型
    • 最终物理模型
      • Object
      • Field
      • Data
      • Clob
  • 元数据存储技术选型
• 参考资料

背景和价值

SAAS架构要求
1 数据隔离。租户隔离
2 标准模型。 企业级4A架构+DDD
3 元数据模型。 支持用户自定义对象，字段等。

---

1 租户设计

2 灵活用户自定义设计

支持强大的自定义功能

满足个性化需求：不同企业有不同的业务流程、数据结构和用户界面要求。通过元数据模式，Salesforce 允许用户在不编写大量代码的情况下，对系统进行高度自定义，如自定义对象、字段、页面布局等，以贴合各企业独特的业务需求。
快速适应业务变化：企业业务会不断发展和变化，元数据模式使 Salesforce 能够快速响应这些变化。用户可以方便地添加新的业务逻辑、修改数据模型或调整界面元素，无需重新开发整个系统，提高了系统的灵活性和适应性。

Salesforce作为一款强大的客户关系管理（CRM）系统，为满足不同企业的独特业务需求，提供了丰富的自定义功能，以下是一些常见的自定义需求及示例：

业务流程自定义

• 需求：不同企业的销售流程、服务流程等各不相同，需要根据自身业务特点对流程进行定制，以提高业务效率和管理水平。
• 示例：一家制造企业，其销售流程包括初步需求沟通、产品定制方案设计、样品提供、合同谈判、生产安排、发货及售后服务等环节。可以在Salesforce中通过流程构建器（Process Builder）和工作流规则（Workflow Rules）来设置每个环节的触发条件、审批流程和相关操作，自动发送提醒邮件给相关人员，确保销售流程的每个环节都能顺利进行。

数据模型自定义

• 需求：企业可能有独特的数据管理需求，需要创建自定义对象、字段和关系，以准确记录和分析业务数据。
• 示例：一家金融服务公司除了使用Salesforce的标准客户和机会对象外，还创建了“金融产品”自定义对象，用于记录各种金融产品的详细信息，如产品名称、类型、收益率、风险等级等。同时，在“客户”对象中添加了“投资偏好”自定义字段，用于记录客户的投资倾向，以便更好地为客户提供个性化服务。

用户界面自定义

• 需求：为了提高用户体验和工作效率，企业希望根据员工的工作习惯和业务需求，对Salesforce的用户界面进行定制。
• 示例：一家科技公司的销售团队经常需要在移动设备上使用Salesforce，他们通过Lightning App Builder对移动界面进行了自定义，将常用的功能和信息，如客户联系人、销售机会进度、产品信息等放在突出位置，方便销售人员快速查看和操作。同时，为不同角色的用户（如销售代表、销售经理、市场专员）创建了不同的页面布局，展示与他们工作相关的关键信息和操作按钮。

报表和仪表盘自定义

• 需求：企业需要根据自身的业务指标和分析需求，创建个性化的报表和仪表盘，以便快速获取关键数据和洞察业务趋势。
• 示例：一家零售企业创建了一个销售仪表盘，通过自定义报表和图表，展示不同地区、不同产品线的销售数据，以及销售趋势、库存周转率等关键指标。管理层可以通过这个仪表盘实时了解业务状况，及时做出决策。例如，通过对比不同地区的销售数据，发现某个地区的销售额下降，进一步分析相关报表，找出可能的原因，如竞争对手的活动或市场需求的变化，从而制定相应的营销策略。

集成与扩展自定义

• 需求：企业通常会使用多种业务系统，需要将Salesforce与其他系统进行集成，实现数据共享和业务流程的自动化。
• 示例：一家电商企业将Salesforce与电商平台、物流系统进行了集成。当客户在电商平台上下单后，订单信息会自动同步到Salesforce中的“机会”对象，并触发后续的销售流程。同时，Salesforce中的发货信息也会实时更新到物流系统，实现订单处理和物流跟踪的无缝衔接。此外，企业还可以通过安装AppExchange上的应用或开发自定义插件来扩展Salesforce的功能，满足特定的业务需求。

技术实现：元数据模型

如果都用物理表的设计，那么单库最多支持上千个模型，一般来说，一个租户有数百个数据模型，单库就只能支撑至多数十个租户，成本极高；并且运行时，各租户会经常修改数据模型，这些模型的修改如果线上执行数据库DDL，将会极大影响数据库性能，并且会影响其它租户。

方案：
Salesforce给出Zero DDL的设计，线上海量的租户可以自由更新模型，模型的变更仅仅是元数据记录的更新而已，非常轻量，单库实例可以轻松支撑十万乃至百万模型以上。如果采用物理库设计，很难做到单实例支撑百万个数据表以及在线DDL。

关键设计思想就是：当用户定义一个新的用户表或者添加字段时，用户创建的不是数据库中的物理表，而是在系统的元数据表中添加了一条记录，这个记录描述的是用户表的逻辑定义，是虚拟的。
任何数据表、字段的变更都不会带来线上数据库的DDL，Salesforce巧妙的通过七个数据表实现这个设计，使得http://Force.com可以描述任意复杂的模型，这才使得它的CRM产品具备无限的扩展能力和无穷的生命力。

技术点和挑战

1 如何实现自定义报表？数据源有标准实体对象，也有自定义对象

2 自定义对象和标准对象的关联如何解决

3 自定义对象的字段搜索如何解决？

4 如何实现界面自定义

5 如何实现，业务流程自定义？（需要对BPM底层能力非常精通）

元数据模型

需求分析
例子
我要新增一个 Accont对象
1 要加10个字段，每个字段有他的校验规则。比如Name，要求长度不超过30字符，不允许为空。
邮箱字段，格式要求是 英文+符号+ @xx.xxx
2 能够根据类型做搜索页面，支持模糊搜索，如果是日期类型的话，范围搜索，等值搜索等。

抽象出业务模型

1 对象
2 字段对象
3 字段类型
4 字段类型的校验规则
5 字段类型的搜索控件

第一个版本物理模型

一个Field业务对象，对应一个表。 Field表设计。 C1Name，C1Type，C1Value；C2Name，C2Type，C2Value
问题：我要找一个Object对象，有哪些字段不友好。

变体：
Field 的字段定义和值分开。
Field表设计 ID，Name，Type，ObjectID，租户ID
Data表：Val1，Val2，Val3，，，

问题：如果有大对象，会影响Data表的性能

变体2：
Data表拆为大对象存储和非大对象存储

最终物理模型

Object

表存储了每个租户为它的应用对象定义的元数据，包含如下核心字段:
OrgID：应用对象所归属的租户 ID
ObjID：应用对象唯一标识，全局唯一，具有固定长度和格式，系统内部产生
ObjName：对象名称，就是通常意义的数据表名，如Account、Student等

Field

OrgID：应用对象所归属的租户 ID
ObjID：包含该字段的对象ObjID
FieldID：字段ID，对象内唯一
FieldName：字段名称，就是通常意义的数据表字段名，如Age、Gender等
DataType：字段类型，Salesforce支持的数据类型非常丰富，如：text, number, date, date/time, picklist(enum), auto-number, sequence, boolean, email, URI……
Rule：字段校验规则，对于整数类型，可以定义其最小最大值；字符串类型，可以定义正则表达式校验等。这可作为未来数据插入的强制性校验，不通过Rule校验的数据无法被插入或更新
FieldNum：字段槽位，下面在数据表设计中会提到
IsIndexed：是否被索引

Data

OrgID：应用对象所归属的租户 ID
ObjID：对象ID
GUID：数据记录的主键，全局唯一
flex列(slots)：Val0, Val1, ……Val500，系统维护了flex列和实际field的映射关系，即上面Fields表的FieldNum
同一个flex列可以代表任意数据类型，variable-length string，所有数据类型(text,int,date…)都以canonical format存储；

Clob

Clob用于存储大字符段的存储，记录超大字段(长度超过32000的字符串)，Data表只记录Clob ID。
【Guess】 如果是大对象，Field类型是大对象类型。 那么Data的valx存储的是Clob的ID列表。

元数据存储技术选型

基于 Apache Phoenix 的存储
Apache Phoenix 最初基于 Apache HBase 构建，专为处理海量结构化数据集而设计，并针对大规模 SQL 查询进行了优化。Salesforce 的大数据存储（BDS）团队对 Apache Phoenix 进行了改造，使其能够处理灵活的文档式数据，同时保留其作为高规模 SQL 数据库的核心优势。Phoenix 被用于存储 Salesforce 中的大量数据，包括与元数据相关的数据，它支持关系数据和文档数据，为 Salesforce 工程师提供了灵活性，使他们能够创建具有复杂、适应性强的数据模型的应用程序，同时仍能利用基于 SQL 的查询、多租户和高可用性。

参考资料

https://blog.csdn.net/wwd0501/article/details/136242900