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