下载文档原格式
【转】元数据驱动的SaaS架构如何设计？作为业务系统技术开发同学，⾯向当下：⾸先应该是快速搭建业务通路，让线上业务跑起来，快速试错，解决⽣存问题；第⼆步是在链路通了，业务基本跑起来的基础上如何⽀撑业务跑更快，解决快速增长问题；第三步，在完成⽀撑业务快速增长的基础上，要进⾏精细化提升，通过在⽀撑业务快跑间隙挤时间打磨系统功能和体验，踏踏实实花时间，抽象能⼒，沉淀产品，提升效能。
同时，我们也必须⾯向未来，如何在抽象能⼒以及沉淀了产品的基础上，如何把所承载和沉淀的业务能⼒快速输出，贡献给整个⾏业，抑或为整个社会商业⽣态提供基座⽀撑。
那么⾯向未来，将平台产品进⾏SAAS化升级真正将能⼒进⾏有价值开放输出是我们提前要布局的核⼼⽅向。
那么将平台产品进⾏SAAS输出，需要解决那些问题呢？这⾥尝试把核⼼问题列举⼀下：1. 如何根据不同⽤户需求进⾏计算能⼒按需调度分配？（IAAS/PAAS）2. 如何满⾜⽤户数据安全性要求，严格隔离不同⽤户的数据，使⽤户只能看到⾃⼰的数据？（PAAS）3. 如何⽀持不同⽤户在标准的数据对象/数据模型上按需添加定义⾃定义的数据对象/扩展模型？（PAAS & SAAS）4. 如何按照不同⽤户进⾏按需功能搭配组合，满⾜不同⽤户从基础到专业级不同业务场景需求？（SAAS）5. 如何统⼀对平台产品进⾏升级⽽不影响⽤户已有数据及功能？（IAAS、PAAS、SAAS）通过以上问题，我们可以看出产品SAAS化输出的关键是如何对不同的⽤户通过标准+扩展能⼒按需进⾏算⼒、数据、安全、功能有效定制，⽀持多⽤户共性和个性的问题，也暨多租户的问题，同时也涉及到计费和服务⽔平等相关问题。
我们下⾯来聊下上述问题的解题关键和解题思路1. 第1个算⼒的问题核⼼是调度问题，弹性计算提供在IAAS层的统⼀算⼒调度能⼒，⽽Serverless则可以在PAAS层提供更⾼层次的算⼒调度能⼒。
2. 第4个问题的核⼼是业务流程的抽象和业务功能的拆分，领域驱动的设计以及服务化(微服务)在平台功能抽象拆分提供了相对成熟的思路，催化了以纵向业务功能细分作为域划分的依据的服务化⽅案以及组织结构，主要诉求是在细分的业务功能服务基础上，能按需快速灵活的组合⽀撑不同的业务模式，提供业务敏捷性，⽀撑业务创新求变。
元数据驱动的Saas架构与背后的技术思考21 CTO 1周前以下文章来源千阿里巴巴中间件，作者程彦．凡，w.:ire 阿'II归””“道冲而用之或不盈，渊兮似万物之宗。
—老子引言作为业务系统技术开发同学，面向当下：•首先应该是快速搭建业务通路，让线上业务跑起来，快速试错，解决生存间题；•第二步是在链路畅通、业务基本跑起来的基础上，如何支撑业务跑得更快，就需要解决快速增长问题；造成的不可用，同时系统平台提供了一个高效的机制来减少对平台多租户应用总体性能影响。
当用户修改了一个表字段列的数据结构，从一种数据类型改成另外一种不同存储格式的数据类型时候，系统会重新分派—个新的弹性列给到这个字段列的数据，将数据从原来的存储弹性列批量拷贝到新的弹性列，然后才会更新此字段列的元数据，暨在Fi e lds表中更新这个字段列的元数据，将数据类型更改为新的数据类型，并将Fi e ldNum更新为新的Valu e X列对应的X值。
同时，在如上对用户逻辑表结构调整生效过程中，原来的数据结构和对应的数据访问正常进行，直到逻辑表结构变更生效，对应用系统可用性不会造成影响，用户对此无感知。
八、多租户架构对于研发人员意昧着什么对于研发人员来说，多租户结构最多意味着两个版本：当前版本，以及下—个版本。
没有遗留版本需要维护。
所有人不用操心旧的技术，旧的版本，所有只有最新的版本，只需要关心最新的版本。
这样就给敏捷开发带来极大的好处，每年做个位的发布，每次发布几百个新的特性新的版本也不会改变用户的体验，新的特性可以根据用户需要开启，通过特性管理来开关。
新版本发布前，提供沙箱环境来允许用户提前试用新版本的系统。
如果做bug修复，则是在所有租户层面上进行统—修复的。
对于用户应用的发布进行严格管理，防止对其他租户产生影响，通过提供沙箱环境来让用户验证新应用发布，并通过成干上万的自动化测试保证用户的正常功能。
在运行期间，不作任何底层DDL操作，不会做表的创建，也不会做表的变更，只可能在极少数的更新周期时候进行。
SaaS架构设计SaaS成熟度模型分级依照SaaS应用是不是具有可配置性、高性能、可伸缩性的特性，SaaS成熟度模型被分成四级。
每一级都比前一级增加以上三种特性的一种。
Level1定制开发:有一个客户项目，就按客户需求定制一个版本，每一个客户的软件都有一份独立的代码，不同客户软件之间能够共享和重用的只有少量的可重用组件、库和开发人员的体会Level2可配置:客户能够通过简单的配置，让通用型的软件能够知足自己的一些个性经需求。
为每一个客户独立部署一个运行实例，只只是每一个运行实例运行的是同一份代码。
Level3高性能的多租户架构:多租户单实例的应用架构才是通常真正意义上的SAAS应用架构，也确实是咱们通常所说的Multi-Tenant架构。
Level4可伸缩性的多租户架构：在用户数大量增加情形下，不必更改架构，而仅通过硬件设备的增加，支撑应用规模的增加SaaS平台的应用企业内部治理办公自动化（OA）、客户关系治理（CRM）、供给链治理（SCM）、人力资源治理（HR）、项目治理（PM）、内容治理（CM）等治理系统大量应用在企业内部的治理中。
外部展现效劳动态网站、网站商铺、在线定单、产品目录、会员注册、下载中心、物流跟踪等应用系统借助互联网的普及和阅读的方便性使得SaaS平台取得式的普遍应用。
工具软件E-MAIL、短信、QQ、MSN、彩信、即时通信、在线应用开发工具、在线客户化工具、在线自主建站等工具软件也迅速地取得进展。
3. 应用处景分析企业注册、开通进程应用处景分析企业要利用SaaS平台系统，但是SaaS平台所提供的效劳不只一个，因此应该明白他是需要利用哪个软件。
软件是分为模块的，有些模块是用户所需要租用的，有的可能用户是不关切的，不同模块功能不同，访问权限及访问方式不同，同时价钱也不同，因此，企业注册时应该清楚自己注册的是哪级模块。
不同企业有不同要求，如企业1要求数据要独立寄存，咱们就应该为企业1开辟独立的数据库。
SaaS架构设计SaaS架构设计 (1)SaaS成熟度模型分级 (1)RUP “4+1”视图模式（逻辑视图/过程视图/开发视图/物理视图+场景视图） (2)MDA(Model Driven Architecture)模型驱动架构 (2)RUP “4+1”视图模式（逻辑视图/过程视图/开发视图/物理视图+场景视图）●场景视图：用例图，描述用户的业务场景，从用户的角度标识出业务需求，它是架构设计的起点和终点；●逻辑视图：就是对象模型。
逻辑视图重点在于功能，功能包括可见的业务功能，也包括不可见的系统功能（如日志、权限、事务等）。
同时更重要的是确立逻辑分层、模块划分和模块之间的依赖关系；●开发视图：用于描述开发环境下的静态组织。
从开发环境、技术架构、分层策略和目录结构4个方面阐述；●过程视图：聚焦在进程、线程等运行时概念，以及相关的并发、同步、通信等问题。
如果本系统不需要考虑这些方面，本视图可以省略；●物理视图：也叫部署视图描述软件如何映射到硬件，反映系统在分布/部署上的设计。
MDA(Mod el Driven Architecture)模型驱动架构MDA利用元数据模型，可以方便灵活地实现可配置化。
MDA(Model Driven Architecture)是模型驱动架构，它是由OMG定义的一个软件开发框架。
它是一种基于UML以及其他工业标准的框架，支持软件设计和模型的可视化、存储和交换。
和UML相比，MDA能够创建出机器可读和高度抽象的模型，这些模型独立于实现技术，以标准化的方式储存。
MDA把建模语言用作一种编程语言而不仅仅是设计语言。
MDA的关键之处是模型在软件开发中扮演了非常重要的角色。
SaaS的安全性设计一般常见的安全性设计分为两类：系统级和程序级。
系统级：●使用HTTPS协议以SSL（Security Socket Layer）交换数据，增强通信安全；●通过数字签名防止传输过程篡改；●对用户身份识别的UserToken使用DES算法数据加密；●业务数据定时自动备份；程序集：●完整的权限配置，包括功能权限和数据权限；●客户端输入校验，防止JS攻击、XSS攻击、SQL注入等；●辅助安全设计，比如密码控件、图片验证码、手机确认码等；安全性安全压倒一切。
软件开发中的SaaS架构设计随着云计算技术的快速发展，SaaS（软件即服务）作为其中的一种形态已经逐渐成为了企业用户的首选之一。
SaaS架构设计是软件开发中需要高度关注和研究的领域，因为只有在合理的SaaS 架构下，软件开发才能更加高效、可靠和安全。
本文将从产品架构、应用架构、数据架构三个方面来探讨SaaS架构设计的相关内容。
一、产品架构产品架构是整个软件系统的基础架构，它决定着软件的技术路线、产品功能和用户体验。
对于SaaS产品来说，产品架构尤为重要，因为它关系到用户能否快速、便捷地接入产品，同时也关系到产品的可扩展性和可定制性。
1. 前端技术选择SaaS产品的前端技术主要包括用户界面设计、交互功能、布局样式等方面。
为了让用户可以随时随地通过浏览器或移动设备来访问SaaS应用，前端技术选择需要满足以下几点要求：（1）兼容性：优秀的前端技术要能兼容各种浏览器和移动设备，确保用户可以在任何平台下都能顺畅地使用应用。
（2）易用性：一个良好的前端技术不仅需要美观，还需要符合人性化设计原则，让用户可以快速上手，减少使用门槛。
（3）性能：前端技术的速度、响应能力以及稳定性等方面也需要保证，以保证用户的使用体验。
2. 后端技术选择SaaS产品的后端技术是整个系统的基础，它需要提供数据持久化、任务调度、服务治理等一系列核心服务。
因此，后端技术选择需要考虑以下几个方面：（1）稳定性：后端技术需要长期稳定运行，尤其是在高并发、大数据量情况下，系统也需要正常运行。
（2）扩展性：后端技术需要支持横向扩展，以支持大量用户同时使用系统。
（3）可维护性：后端系统需要方便快捷地维护和管理。
二、应用架构SaaS应用架构是指产品服务的流程和架构，它关系到整个系统内部的各个子模块以及系统外部与其他服务的交互层面。
在SaaS应用架构中，需要注意以下几个方面：1. 服务架构在SaaS应用架构设计中，服务架构是一个非常重要的方面。
服务架构涉及到服务设计、服务治理等方面。
论云计算环境下的SaaS架构与设计随着云计算的发展和应用的普及，SaaS（软件即服务）已经成为了一种重要的架构和设计模式，它是云计算中的一种应用服务模式，它是将软件应用程序作为一种服务进行提供，而不是直接在用户终端上安装和运行。
SaaS架构主要包括用户界面、业务逻辑、数据存储和安全性等方面，本文将从这几个方面对SaaS架构进行探讨。
一、用户界面SaaS应用程序存在于云计算环境中，与传统的桌面应用程序不同，在SaaS架构中，用户通过浏览器等客户端访问SaaS服务，而不需要进行安装和配置。
因此，SaaS应用程序的用户界面必须相应地进行设计，以便能够适应不同的客户端和设备，并且能够在不同的浏览器和操作系统上运行。
为了实现这一目标，SaaS应用程序必须采用响应式设计，即能够动态地调整页面的布局和内容，以适应不同的设备和视口大小，同时还要保持一致的界面风格和用户体验。
这涉及到各种设计技术和方法，例如流式布局、自适应布局、CSS媒体查询、JavaScript响应式框架等。
SaaS应用程序的用户界面还需要考虑到多语言、多主题和自定义化等问题。
因为SaaS服务可能面向不同的用户群体，在不同的国家和地区使用不同的语言和文化，需要支持多语言和本地化。
同时，用户可能会有不同的需求和偏好，需要提供多种主题或者自定义化选项，以便满足不同用户的需求和喜好。
二、业务逻辑SaaS应用程序的业务逻辑主要包括数据管理、业务规则、工作流程和集成等方面。
在SaaS架构中，数据存储通常采用多租户模式，即将不同用户的数据存储在同一个数据库中，但通过不同的租户ID对数据进行区分和隔离。
这需要在数据模型和数据库设计上进行特殊处理，以确保数据的安全性和可靠性。
SaaS应用程序的业务规则和工作流程通常是由业务逻辑层（BLL）和数据访问层（DAL）来实现的。
BLL是SaaS应用程序的业务逻辑核心，它负责业务逻辑的处理、数据模型的转换和数据校验等方面。
SaaS架构设计的参考指南为什么需要 SaaS？软件即服务（SaaS）是一种灵活的软件分发模型，可以由少到一个人或多至上千人的组织来运作。
云服务的问世让任何人都可以独立运行自己的 SaaS，并在此基础上建立免费增值模式的业务。
与其他类型的软件服务相比，它的系统设计相对简单。
但是，由于没有合适的基准架构，如果我们在设计 SaaS 时没有认真思考，其结果可能会变得一团糟。
我见过的一些例子中，SaaS 平台最终成为一个庞大却脆弱的单体 Web 应用程序，其中遍布冗杂的功能。
本文的目的是为你提供一种参考架构，为 SaaS 实现可伸缩性和可维护性。
SaaS 平台的需求产品需求•用户和用户组的访问控制。
•向用户和组织提供订阅层，其中每种订阅类型都可以访问一组产品。
•托管内部管理工具的能力。
•可扩展的功能。
我们应该能轻松添加新的产品和功能集。
设计目标•隔离的服务带来清晰的责任归属与关注点分离。
•减小任何更改的影响半径，比如说分析仪表板中的错误不应该影响管理仪表板。
•隔离运行 Web 应用程序。
每个Web 应用程序都提供一组相关的功能来服务我们的客户。
在大型公司中，每个 Web 应用程序都可以有自己的专门团队来构建和运行。
解决方案：隔离和重用将服务隔离到逻辑组件中的设计可以让我们的 SaaS 有更好的可扩展性。
我们应该针对我们的架构作出改进，在规模扩展时打破常规：规模越大，架构却变得越容易管理。
就算只有一位孤独的车间开发人员，他也可以很容易运行并管理多个服务，尤其是现在我们已经拥有了各种各样可以编排微服务的云服务，这种事情做起来就更简单了。
因为计划在 SaaS 平台上运行这些功能 Web 应用（feature Web app），所以我们应该先思考“我们可以重用什么？”这个问题。
隔离隔离的Web 应用程序是将相关功能分组在一起形成的一个Web 应用程序，或是代表一款产品的一组 Web 应用程序。
具体而言，我将其称为“产品 Web 应用”，后文将做更进一步的介绍。
一、Saas平台的简介二、多租户架构三、元数据架构Saas平台：软件即服务是一种通过Internet提供软件应用的模式，服务提供商将应用软件统一部署在自己的服务器上，用户无需购买、构建和维护基础设施和应用程序软件，只需根据自己实际需求定购应用软件服务，按定购的服务多少和时间长短向服务商支付费用。
在多租户架构中所有用户和应用程序共享一个由中央维护的单独共用的基础设施和代码库，即多个用户共享相同的物理实体和应用程序的版本。
实现多租户数据存储有三种方式：分离数据库、共享数据库，分离Schema、共享数据库，共享Schema。
HiServiceCRM系统采用的是共享数据库，分离Schema的方式。
主要考虑下面一些因素：●系统要支持多少租户●平均每个租户要存储数据需要的空间大小●每个租户的同时访问系统的最终用户数量●是否想针对每一租户提供附加的服务，例如数据的备份和恢复等共享性越高，对技术的要求越高。
元数据降低了创建应用程序的难度，用户通过简单的点击配置，不用代码就能创建复杂的应用程序。
HiServiceCRM元数据的设计采用动态表单的方式。
四、HiServiceCRM是基于Saas的可配置平台HiServiceCRM是一套基于SaaS模式的业务流程管理系统，具有灵活、便捷和高效的特点，用户可以根据企业自身的业务特点自定义数据模块、业务流程、系统用户和角色等等，系统可以最大限度的满足用户的业务需要和使用习惯。
HiServiceCRM实现了多租户架构，所有租户共享一个基础设施和代码库，而基础设施和代码库由服务提供商统一维护。
多租户的实现方式上，主要考虑下面一些因素：●系统要支持多少租户。
HiServiceCRM将面对成千上万个的大量租户。
●平均每个租户要存储数据需要的空间大小。
HiServiceCRM每个租户存储数据需要的空间大小根据租户的用户数来决定，但是不能超过256M。
●每个租户的同时访问系统的最终用户数量。
SAAS架构设计模式SAAS（Software as a Service）是一种软件交付模式，指的是将软件作为服务来提供，用户通过互联网访问软件，并按需付费使用。
SAAS 架构设计模式是为了有效构建和交付可靠的SAAS应用而产生的一种设计方法。
本文将介绍SAAS架构设计模式及其主要特点。
1.多租户模式多租户模式是SAAS架构设计的核心思想，它允许多个用户共享同一套应用程序的资源和基础设施。
在多租户模式下，每个用户都有自己的数据隔离和配置，以确保安全和隐私。
多租户模式可以提高系统的可扩展性和灵活性，减少资源浪费，并且更容易为用户提供定制化的产品和服务。
2.分布式架构SAAS应用通常需要处理大量的用户请求，并且需要保证高可用性和可扩展性。
因此，分布式架构是SAAS架构设计中的常见选择。
分布式架构将应用程序分割成多个服务，每个服务运行在独立的服务器上，通过互联网进行通信。
这样做可以提高系统的吞吐量和并发能力，并且可以更好地实现系统的容错和故障恢复。
3.微服务架构微服务架构是一种分布式架构的变体，它将应用程序划分为一系列较小的、独立部署的服务。
每个微服务负责完成一个特定的业务功能，它们之间通过轻量级的、独立的通信机制进行协作。
微服务架构可以提高系统的灵活性和可维护性，方便团队独立地开发和部署各个服务，并且可以更好地实现持续交付和快速迭代。
4.弹性计算SAAS应用需要根据用户的需求动态扩展和收缩资源。
弹性计算是一种根据负载情况自动调整系统资源的设计模式。
它可以根据用户的请求量和系统的负载情况，动态分配和释放计算资源，以提供高性能和高可用性的服务。
弹性计算可以基于自动化的监控和调度算法，在系统负载高峰期提供额外的计算资源，在负载低谷期释放多余的资源。
5.可扩展性设计为了应对不断增长的用户和数据量，SAAS应用需要具备较好的可扩展性。
可扩展性设计是在系统中预留扩展空间以容纳未来的增长，使用可扩展的硬件和软件架构以支持新的需求。
浅谈SaaS系统中的数据模型设计在如今的中小企业管理软件市场中，特别是在中国，应用企业管理软件来优化运营及提升企业生产效率的需求一直在持续上升，而其中基于软件即服务理念的SaaS模式也为很多企业所青睐，但由于目前市场上这一模式的解决方案所能覆盖的范围有限，而且有些开发实施运营中的关键问题迟迟得不到很好的解决，导致这一市场还没有能被真正被开发起来。
本文尝试通过对国内外对于基于SaaS模式的数据模型的几种常见思路及其适用场景的研究，对这方面的若干关键问题进行初步的探讨和分析。
一．SaaS系统常见数据模型在设计SaaS系统的数据模型时出于服务客户及减低开发成本等考虑，在数据的共享和隔离之间求得一定的平衡是必须考虑的一个重要因素。
因此一般在设计对应数据模型时不仅要考虑到技术因素，例如怎样构建一个弹性架构以支持数目不定的客户、怎样消除大容量并发访问数据库对系统性能造成的压力以及怎样允许用户按需扩展自定义数据等；同时也必须将商业因素纳入考虑范围之中，例如架构在该SaaS系统上的业务应用主要面向哪些行业的客户、目标客户对于数据存储方式是否有基于一定法律法规的要求等等。
一般而言，SaaS系统的数据模型有如下三种形式：1.1独立数据库将每个客户的数据单独存放在一个独立数据库是实现数据隔离的一种最为简便的解决方案。
在应用这种数据模型的SaaS系统中，大部分系统资源和应用代码还是由所有的客户所共享使用，但物理上每个客户有自己的一整套数据，而且单独存放。
系统将借由元数据（Metadata）来记录哪一个数据库属于哪一个特定客户，与此同时也可以部署一定的数据库访问策略来确保即使系统处于异常状况下，客户数据也不会被其它客户意外访问到。
显而易见的是，一旦每个客户拥有其独立数据库，那他将可以轻易的对其做个性化的修改来符合其实际业务需求，而且如果系统出现异常情况需要将历史备份数据重新恢复的话，也将是一项轻而易举的工作。
但是，这种数据模型的最大问题是对应的部署和维护成本非常高，硬件资源的消耗将明显高于其它两种方案，一台服务器将只能支持有限数量的客户。
未来社会模型中 SaaS 的位置与分量上图是一个从连接这个透视角度抽象出来的社会模型，其中的家庭、人、组织、物都是相互连接的，它也是一个从软件架构抽象出来的社会模型。
SaaS 是对软件的获得和使用方式的革命，早在 2004 年就已有端倪（当时称为 ASP，Application Service Provider）。
笔者认为，可以将 SaaS 放在社会运行机制、发展趋势这样的大格局中定位其社会作用。
SaaS 企业也需要这样的格局与信念，虽然在中国还没有出现非常成功的 SaaS 企业，但终究会出现的，信任、习惯、规范、与能力都需要进化，需要时间。
在没有电之前，人们就有传递信息的需求，这也是为什么微信能够存在的本质根由。
同理，各种组织都离不开软件，而且软件的渗透越来越广泛与深入，因为整个世界的数字化是不可阻挡的趋势。
而 SaaS 在大部分情况下是必选之路，会越来越成为标配，除非特殊原因，或者不在乎成本、或者已经拥有某种等效的软件、或者其他原因。
只要这种本质性的需求存在着，社会的发展终究会以越来越先进的方式来满足它。
这里分享一个关于云的小故事，笔者曾经算过一笔账，如果在云上订购托管机房中约 500 台机器的同等算力，每年需要支出 5000 万，相当有悖于流行认知，其实对于稍微有些规模的 IT 资源诉求，云相对是更加昂贵的，但来的快、方便，两方面都是事实。
这里只想传递一个观点，长远来看，SaaS 有它存在与发展的必然性。
结构上讲，它是社会运行机制中不可或缺的一部分。
同样或者类似的软件，显然没有必要每个人、每个组织都各买一套或各自开发一套，这是社会资源的极大浪费，有悖于社会发展的基本规律——既然是必需的，必然选择物美价廉。
而且组织支出比个人支出更理性、更注重实用价值，有利可图的需求终究会达到稳态的、某种主流服务的满足。
从架构角度看 SaaS 面临的挑战如果说 SaaS 在大部分情况下将会成为必选之路，那么它面临的最大挑战又是什么呢？概括来讲，SaaS 面临的最大挑战是满足客户的个性化需求。
从架构角度看，它体现在如下图所示的几个方面：其中最有挑战性的又要属多变的后台逻辑与数据模型。
对于 SaaS 供应商而言，这种需求显然不能通过项目的方式来定制满足，而只有通过提供灵活的自服务平台才能满足，这种灵活性就需要用 PaaS 来生产客户想要的软件。
这一点笔者在2013 年做一个 SaaS 项目的架构工作时就深有体会：一开始的目标也是做 SaaS，但是后来还是走上了 PaaS 的道路，不过是专为生产 SaaS 而自用的 PaaS，而不是定位于 PaaS 供应商。
如果一个 SaaS 企业从一开始就只是聚焦某个业务，而没有着手 PaaS 的建设，那说明它在满足个性化需求的道路上一定是在某个局部、某个层面解决问题，而不是系统、全面、可复用地解决问题。
同时，从中国 SaaS 市场现状来看，它的成长比较慢，环境的综合成熟度还不够高，聚焦单一业务成长的加速度不够，因此企业后续很可能会从最开始聚焦的核心业务向外扩展，到时候又要面临种种个性化需求问题。
因此，一个成功的 SaaS 企业必然要去寻求 PaaS 的支撑。
从这两个意义上讲，PaaS 可能也是 SaaS 企业提高生产力的必经方向。
据有关数据表明，在企业弃用 SaaS 的原因中，无法满足个性化需求占了 23%，可见 PaaS 的支撑多么重要。
如何做好 SaaS 架构？1 业务数据库SaaS，特别是 To B 的时候，业务数据库必然是存储的核心，这里笔者针对业务数据库总结了一些架构层面的建议。
建议一：对于任何 mission critical 的场景都要使用 RDBMS企业应用与 To C 的使用场景有一个明显的区别是，绝大部分情况下，它对正确性、准确性的要求更高，而且 SaaS 提供方需要对此承担相应的责任。
因此，支撑一线黄金业务流程的数据库目前来看还是得使用关系型数据库。
目前来看有两个开源可选项，分别是 MySQL 和 PostgreSQL。
建议二：分库支持多租户可以有多种方式，这里所说的分库并不是指每个租户一个独立的库（当然产品销售时可以作为套餐的一个选项），而是指多个数据库实例，每个实例包含多个租户的完整数据。
说到多租户，需要提个醒，通常大家都会想当然地认为租户之间是隔离的，但是事情都有另一面，对于大集团客户，在某些业务上，它的分公司、子集团之间可能还是有连接的。
另外，人员组织机构建模上，也要考虑一个人任职多个子集团或公司的可能。
建议三：Partitioning即使是一个数据库实例，也可以再继续分区，MySQL 和 PostgreSQL（至少版本 11 以上）都支持在一个实例内部分区。
对租户进行 Partitioning 可以在一定程度上提高性能，因为把一个查询限制在更小的数据范围内进行，而非全量数据空间，效率自然会更高。
建议四：元数据驱动，Salesforce 不是标杆一个民族、一个国家如果没有非权威精神，是不会有根本性创新的。
动则大厂是如何做的，好像大厂总是做的最好的，那是不行的，盲目崇拜只能是 follower，不可能是 creator，当然也不能盲目忽视，最要紧的是把业务架构搞清楚、明确定义到底要什么。
心里要有谱，但是技术本身绝对不是谱，而仅仅是可选的手段。
以下是根据 Salesforce官网资料整理的的核心数据模型：其业务数据表本身是没有物理索引的，真正的索引主要在MT_Indexes 中，但是这有点让人困惑，为什么不在MT_Data 上直接建立物理索引呢？难道列和索引太多了会影响性能？而反范式地单独以列的方式、按数据类型建立很少的索引就好？为此，笔者动手做了验证。
1）实验条件为了聚焦在问题本身，图 3 中只采用了绿色的两张表，而省略了红色的字段，本实验所使用的字段名和图 3 不一样，但是思路是一样的。
OS，Windows 10；DB，MySQL 5.7；两张业务表，有物理索引的 =bizdata，没有物理索引的 =bizdata2，结构如下：bizdata 和 bizdata2 都灌入了 10 万条数据，字符型长度为 4，它的值基于给定的一个长度为 10 的字符串随机生成，数值型的则为 100 以内的随机数；索引表为 pivot_index，其中 rowid 的值等于业务表中 id 的值，col 是列名，它们可能的值是 c1c5、n1n5，string_value 和 int_value 分别容纳的是字符型和数值型的业务数据值，总的数据行数是 100 万行。
2）实验结果以下比较，除了 SQL 形态上不一样，从语义上讲，条件与期望的结果都是完全一样的。
汇总如下：#方式结果（秒）5.391MT_Data（自身无物理索引） +MT_Indexes，Salesforce 方式2MT_Data（自身有物理索引）0.053MT_Data（自身无物理索引）0.130.164MT_Data（自身无物理索引），且字符字段都采用条件 like ‘%xxxx%’使用 Salesforce 索引表（相当于业务数据表 MT_Data 上没有物理索引，红框部分为行变列的 pivot 逻辑，其实红框外的条件在都是 or 的情况下是可以省略的，否则不可以，这里仅仅为了体现逻辑完整结构，Salesforce 后台用的是 Oracle，也许性能比 MySQL 好不少，也许 Oracle 有 pivot 的核武器，不过从逻辑上讲，就算给 Oracle 更大的想象空间，行数倍增也是不争的事实）的结果：直接使用物理索引（相当于业务数据表 MT_Data 上有物理索引）的结果：直接使用没有物理索引的业务数据表（相当于不考虑 MT_Indexes）的结果：在没有使用物理索引的 bizdata 上用’%xxx%’，看情况如何：3）实验结论结论是不要采用 Salesforce 的元数据使用方式，因为其行列转换的性能损失相当大。
此例相当于把数据行数放大了 10 倍，显然在业务数据表上直接建索引更可取。
当然，Salesforce 的情况可能有其历史原因，或者它有某种未知的核武器。
本文建议采用如下模型：其实，Salesforce 对于查询是有限制的，如果它消耗的资源太大，会直接抛异常。
很可能它是依据提取数据的行数的阈值或者时间（governor limits，资源裁判的角色）来限制的，因此它的性能还是有一定的局限性。
官网对此表述为：“被优化器认为资源开销过大的个别查询会抛出异常给调用方，尽管这听起来有点严格，但为了保护数据库系统总体的可伸缩性和性能，这是必要的。
”建议五：索引所有字段Salesforce 的做法是让租户自己决定一个字段是否要索引，但笔者认为在硬件越来越廉价的今天，如果要在用户体验与成本之间平衡，用户体验更可取。
不过 Salesforce 也会自动为特定字段建索引，参见这里。
其实软件这东西，从用户接受层面上讲，在根植于中国文化的市场上是有点障碍的。
例如：字段field，这个词对于中国大部分普通人来说是很陌生的，但是对于以英语为母语的市场而言，说“请把这个表格填一下”，然后说“包括每一个field”，则是一件很普通的事情。
当我们交付一个产品的时候，需要站在用户的角度去体验、思考、感受，而不能假设所有人都有和软件开发人员一样的认知背景。
建议六：PostgreSQL 优于MySQL这里不是要对二者做详尽的比较，而是瞄准一个核心点，元数据驱动的定制能力。
由于MySQL 的row size 是有限制的，65535 字节，而PostgreSQL 的限制则为1GB，显然后者有更广阔的空间，这也是推荐图 10 业务数据模型的原因之一。
建议七：深挖数据库本身的优化空间对于PostgreSQL，相信还有很多潜力可以挖掘，笔者暂未对其做过深入研究，这里只给出一个方向。
例如：它支持subpartition，假设在用OrgID 分区的前提下，再进一步用年来分区，对于有些数据的性能可能会更进一步提升，不过无法保证这个可行，凡有得必有失。
再比如，在MySQL 中，通常可能认为插入一条数据没啥可优化的，就是通常见到的那种写法，但是，insert into table_1 set a=a1,b=b2 这样的写法据说是最高效的。
诸如此类，结合多租户、元数据驱动的特点，可能还有很多值得挖掘的地方，最可靠的方法是完整研读官网、对多种值得关注的选项动手试一试。
2 搜索搜索是 SaaS 必须具备的一种能力，例如：输入关键词，希望系统能找出附件中出现这些关键词的合同，不管附件的格式如何。
搜索和通常 RDBMS 的全文检索是完全不同的，尽管在某些技术思路上是一样的，但具体实现的能力差别很大。
