实战复盘：2B产品的多租户架构设计

编者按：本文来自微信公众号“产品微言”（ID：wuyuweiyan），作者杜松。36氪经授权转载。

上一篇中，我主要分享了产品架构设计的基本思路，探讨了如何才能“画”产品架构图的问题。本文则是对这一设计思路的具体实现，我希望能够通过一个实际的案例来描绘架构图诞生的过程。

在阅读本文前，最好能回顾下前文：

1、会 “画原型” 只是入门，能做架构才算进阶

2、如何基于用户洞察，设计2B产品的业务架构？

3、产品架构图到底是怎么“画”出来的？

（注：本文涉及到用户角色将在后续文章中详细阐述，在本文中，我们需要理解的是不同角色用户在平台上的特征、行为，有明确的边界范围和职责权限。用用户而言，我们只需要为每个用户赋予不同的角色即可完成各自不同的业务动作，驱动整个平台的业务正常的流传）。

但有一种情况是，假设整个平台内的用户和角色不发生改变，他们各自的工作技能（我们把某个角色所能完成的业务定义为技能，以便后续的区分）发生了改变将会出现怎样的情况？

也就是，在我复盘的这个O2O平台上，张三（工程师的角色）此前只能负责电视类的送、装工作，现在张三具备了维修空调的能力，李四原本是负责A品牌的客服工作，现在随着业务的发展，她也具备B品牌的客服工作。

这就意味了同样的角色，服务了不同的业务，是一种跨业务的组织型态，也就意味着不同的业务之间由于业务的特性必然带来管理上的差异化，比如流程的差异、单据的差异。

假设XYZ公司的业务模型如下所示，该公司对接了A、B两家不同公司的业务。

A、B两个公司各自有自己独立的管理流程和模式，他们要求各自的业务单据都不相同（当然前提是他们之间必然存在共性），做为产品经理，你如何规划一个支持两套完全不同公司的业务平台？

传统的做法，也是最直观的做法，自然就是构建两套不同的业务系统来满足各自的业务需求。在这种情况下，如何实现日益庞大的业务需求，如何快速响应跨业务的扩展，过去的方式是对新接入的业务重新开发一套系统，导致整个业务的效率反而随着系统建设而降低。

最显而易见的问题，这种系统应该如何为终端用户提供统一界面，如何为XYZ公司提供统一的管理平台和数据分析界面。

2B和2C产品的最大差异性，实质上是这种角色跨域组织和跨越业务所带来的复杂性和不确定性。换言之，2B的产品所需解决的问题远超“单一最终用户的局限性”。

解决这个问题的思路，就是多租户架构，并实现业务层的解耦。

它是一种架构，我们也可以在同一个服务器上运行的多个程序实例，为多个客户（租户，通常指的是企业级客户）提供服务。

形象点的说，“租户”和我们合租一套房子是类同的意思，张三和李四同租一套房子，各住一个卧室，互相不干扰，客厅、厨房为公共区域，大家可以一起公用一些生活设施。

租户的意思，从字面的理解，也就是租用房东的房子住，不具有产权，只在有限的范围内拥有使用权，且各个租户只能在自己租住的房间贴个墙纸搞点小装饰，不能拆门拆墙搞装修。房东（平台方）不但有整套房子的大门，还可能收回出租的房间。

这种架构也称之为SAAS（软件即服务），它能够支持不同租户之间数据的和配置的隔离，从而保证每个租户数据的安全和隐私，以及用户对界面、业务逻辑、和数据结构的个性化需求，而平台方，不但掌握全局的业务，可以调整业务流程，还掌握全部的数据。

也就是，在多租户模式下，完全可以实现同一个平台下不同租户的业务单据不同，流程不同，而又同时从属于同一个平台，对平台而言，租户只是平台的一个账户，依托于平台开展业务。

形成的局面就是，平台级用户管理整个平台的数据和用户，租户级别的用户只能管理该租户下的用户和业务数据，平台和租户，租户和用户之间是一种1对多和多对1的三层体系结构。

最终，整个平台的架构如下图所示。

我们套用“建筑师”的思维，想象一下我们要建造一栋房子的情形，先要打好地基，搭好框架，立好支柱，然后再有各个楼层，楼层的各个房间，门、窗等等。

构建一套“多租户”架构的平台，就类同于建造一栋房子一样的过程。这个过程，可以简述为5个步骤，或者说5个阶段：

开通租户---->配置租户资料---->配置租户业务---->配置租户表单---->配置租户权限

事实上，这种架构模型，即可从上往下看规划，也可以从下往上看业务，这也是为什么在 “解析产品的信息架构、产品架构与业务架构”时强调从架构设计的能力。

平台的业务和产品架构，我们既能从上往下看用户发起请求后的一系列动作过程，也可以从下往上看为了支撑用户的服务请求所需要构建的一系列服务。所有的设计，都能够推导出最终呈现在用户面去的产品形态，只是取决于设计者如何结合实际应用采用的方式。

这种架构的好处是显而易见的，首先是极大的降低了系统的开发、维护成本，无需针对每个细分的业务重新部署和培训，在系统升级时刻只一次更新即可完成整个平台的升级。

第二，对于O2O平台来说，业务间的用户存在既存在重叠，也存在鸿沟，不同业务间的用户需要考虑统一用户触达界面，以达成一致性的用户体验，多租户模式这种求大同存小异的特性，使得各个业务既能发挥特性，又能维护统一的设计体验。

第三，多租户的数据资源隔离机制，可以保证数据的安全性。

关于多租户架构，必须要区分“多用户”的差异，二者有根本性区别。简单来说，多用户是多个使用“共享”一套逻辑和数据，通过每个用户的权限来识别每个用户所能查看的数据范围和所能操作的功能。

形象的比喻是，多租户相当于多个住户合租一套房子，多用户则是多个住户同住一个房间的不同床位。

02

耦合的“耦”，在中文的字面含义两个人在一起耕地，各干各的事情，互相不要受影响；