(封面图送给技术人的小福利,也是来源于网络勿怪)
然而从产品的角度出发,更希望是对接的时候就能够拿租户对接。
我原本想反驳,但是惯于辩证思维的我,立即明白了其中利害。如果是拿租户对接,那么我们对接的身份维度就有两个:平台 及 平台上的租户。
试想如果只是对接平台,那么平台成了咽喉,我们与其他平台对接的话,关键要素还是租户信息而不是平台本身。
按平台对接的话, 我们需要给三方平台分配一个 appid + secret 即可完成签名。
如果是平台 + 租户的话, 我们需要给三方平台分配 appid + secret + 租户id 完成签名。
因此,我们表设计就有了以下的调整 :
有人可能问了不过是一张表加个字段而已, 跟技术架构有什么关系?
接下来我们讲下远程登录的事。平台与平台的合作有不同的层次和深度,浅点的 只是做数据对接,深点的可能还要 session 打通,即实现免登录跳转。
免登录一般有 Oauth、远程登录、等思路,session 是用户相关的,我们可以通过 auth、远程登录把 session 打通,但是如何统一租户呢?
假设按照平台对接的话, 我们可能需要双方做数据同步,把租户信息同步到彼此通过这种方式来统一租户。
假设按照平台 + 租户对接的话,我们就完全不需要同步租户了, 因为根据 appid 我们各自就能确定各自系统的租户了。反而是免去了租户同步的步骤:
这个案例很好的说明了,产品策略对技术架构的影响,我从中得到的领悟是:作为技术人一定不能太过于自我,多听多思考跟我们的逻辑思维能力一样, 是我们的重要能力