今日Talker：杜松2021

来源：产品微言(ID：wuyuweiyan)

编辑：yun

toB产品，面临着更为复杂的跨越业务、跨越组织的复杂性和多变性，“定制化”需求使得很多产品深陷泥潭。

文  |  人人都是产品经理专栏作家  杜松

本文则是对这一设计思路的具体实现，我希望能够通过一个实际的案例来描绘 架构图诞生的过程。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

01

多租户，解决的就是让多个客户“共享”统一使用一套程序界面，且保证不同客户之间的数据各自独立。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

02

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

耦合物理学上则指两个或两个以上的体系或两种运动形式之间通过各种相互作用而彼此影响以至联合起来的现象。简单说，就是两个东西交织在一起了，互相牵扯，藕断丝连的状态。

解耦，就是回归到各自独立不受影响的状态下。在技术实现上，为了保护和维持代码的健壮性，尽可能的减少模块之间的关联关系，使得各个功能模块各自尽可能的独立，一个地方出错，不会影响全部，更能提高代码的重用性。

由此有一个词叫“高内聚，低耦合”，高内聚就是模块内的活干活干仔细了，低耦合就是别人模块的事情少搅和，接受你应该接受的数据，输出你应该输出的结果就好。

业务的解耦实质是同样的思路，不同在于它更抽象。

以业务表单和操作流程为例，如下图所示。

我们把整个平台中“业务流程动作”(业务层，也可以理解是逻辑层)和“结果表单”(表现层)，进行分拆出来，这样分拆以后的好处是：

其一、表单的格式，样式，甚至内容不再受业务流的限制，能够使得各个租户的表达实现完全的自定义，租户之间的业务表单完全根据租户本身的业务独特性而配置；

其二、表单与表单的之间的关联不随业务的流转过程而强绑定，而是根据业务的结果进行展开，能够实现各个表单之间差异定制而不影响主干业务；

其三、由于高度抽象了整个业务过程中的核心节点，使得小范围内的业务流程调整不影响主干业务的流转，只要保障主干业务的始终闭环性就能确保整个业务过程的闭环受控；

其四、经过高度抽象后的业务过程，简化了平台对租户的管理，也由此带来平台的高度伸缩性，具备随时调整业务的能力；

其五、对用操作员来说，由于统一了整个平台的界面，使得平台内的租户操作员具备跨业务跨组织的业务技能，降低了平台的使用成本和组织的培训成本。

03

对于企业级产品而言，多租户架构是一种较好的松耦合的业务解决方案，它能够有效的支撑不同业务单元和不同组织的差异化需求，从而提升整个平台的效率，减轻企业的成本负担。

但这个模式，确实不太容易被理解和有效实践，整个产品在前期的分析和设计阶段，需要耗费非常多的且短期内不容易见效的工作。

很多时候，我们都不能单纯脱离应用场景来评价某种架构模式的好坏，每个产品都有自己独特的差异化优势。

对“平台”本身而言，比如追求更为灵活可伸缩的模型架构，以适用快速变化的业务需求，在具体的产品落地过程，仍然需要根据周期内的可预见的业务边界，来设计相匹配的产品架构，不能过于超前，否则容易带来不必要的研发成本，特别是拉长了整个研发的周期可能最终的结果反而得不偿失。

对产品经理而言，规划复杂的平台级产品是巨大的挑战。

PMTalk产品经理社区4月、5月产品活动报名链接

公众号：PMTalk产品经理社区

PMTalk年中产品经理大会即将召开，这里有4场产品人不能缺席的产品活动推荐给你！(点击跳转至原文报名)

将PMTalk产品经理社区设为星标

每天为你送上产品圈子资讯

你的在看是小编持续更新的动力???

关注www.ipmtalk.com，开启你的产品世界。