公司产品架构有问题，在多层不同入口访问，现在我是一脸懵逼

[lh934275738]

进公司一个月，逐渐熟悉公司产品，然后开始负责自己这一块，进行需求开发和大量的 BUG 修复，简直坑爹，代码低复用性，界面不忍直视，产品竟然还卖出去很多，蛮多中小型酒店进行使用，我家乡的五星级酒店竟然也用了这套系统，不过是我现在负责的项目的另一种版本，因为那个有需求改动，也是我进行修复的，哈哈，好巧。 现在我主要负责一个能尽量高度自动化的项目，因为以后会有更多的酒店进行使用，那么不可能单项目进行维护，那样子太麻烦了，所有以后尽量是前段配置化，1 个后端处理移动这边的逻辑，数据和一些其他处理在其他部门。 场景，微信公众号访问，首页是带一个标志位进行区分，那么访问进去存道 SESSION 中，界面看不到标志位，那么问题来了，SESSION 会过期，过期了，你刷新页面，你重新进来很麻烦，如果在移动浏览器就会不知道怎么再传这个标志位。问题 2，1 个人访问 N 个酒店的公众号（因为是一个网址，映射有些酒店不愿意做，不然解决起来也简单），那么用的同一个 SESSION，标志位用的不同，造成数据混淆，简直爆炸，当然这都是极端情况。 我本意是想跟在每个链接追加参数，用参数不停的跳转，标志位就不放 session，但是有问题，1 个是风险很大，一位要改很多很多地方，因为这是上线有很多家酒店在用，80%+的订单走的移动端，所以一定以及肯定不能出问题。暂时不考虑，同时考虑了去做缓存，COOKIE，但是同时都会有各种不合理的地方，请问有什么思路可以比较好解决吗？暂时不用着急去处理这件事，不过作为程序猿，感觉不解决心里就很烦，但是没什么思路。

[tlday]

能不能分个段，善用标点符号。
公众号有个功能叫第三方平台，可以让公众号的所有者开放公众号的开发者权限给你们，基于 openId 的验证是公众号开发的正确姿势，自己实现一套鉴权机制是不靠谱的。
基于移动端的开发可以写 restful 的接口。不基于状态。你已经被状态给卡住了。
我不是专业的后端，抛砖引玉吧。

[ibegyourpardon]

痛苦的看完了毫无排版的文章，但也算是大致理解了。但从你的描述来看，你只是看到了「现在的问题在哪」，其实还可以进一步看看「为什么造成了这些问题」。

楼主说的问题其实在大多数公司应该都有，业务线拉的长，可能存在根据客户需求进行定制化的部分，不同的团队接手过，还有开发过程中业务需求发生了变动，时间紧凑等等诸多原因，都会造成相关的情况。

哪都有这问题，而且一般也都是一边填过去的坑一边不自觉的挖了新坑。

之所以建议你在下手解决问题之前先去了解下问题为什么会变成这个样子，有助于你从不单纯是技术的角度来思考，节省大量可能是不必要的开发工作。

[Lonely]

这么一大段，看着费劲

[moult]

你可以用自己的域名，给每个客户不同的子域名就好了。
或者是为不同客户的访问 URL 路径加个前缀，Session 的 Cookie 的作用路径限定在这个前缀的路径下面。

[lh934275738]

@moult 考虑过，想的是做一个映射，但是不现实，有很多用户并不进行映射

[lh934275738]

@ibegyourpardon 恩，有道理

[lh934275738]

@Lonely 感觉好奇怪，我是分段了的。。。

[lh934275738]

@tlday 现在有 2 套流程，一套是微信那种，也就是你说的那种授权，但是如果以后用户更多了，我们程序猿，维护起来太麻烦了，所以考虑自己做一套，让用户自己完成 70%的维护

[jianghu52]

作为一个曾经直接跟用户打过交道的程序员，我可以很负责的告诉你。 [让用户完成 70%的维护] 这件事想都不要想。因为这会是一个巨大的坑。
首先，用户如果发现他能用一些方法替代某些个高级功能的时候，他会毫不犹豫的那么做，这样一来的你设计好的业务逻辑就被破坏了。
其次，当用户具有了某些权限之后，他一定不会按照程序的业务逻辑去使用，一定会出幺蛾子，要么是手动插入数据，要么是物理删除某些项目。而且用的理直气壮。（你给我的权限，我当然是想怎么使用就怎么使用，用坏了反正有你这个客服么）
最后，责任的认定会非常非常麻烦。如果你掌管全部机能，错了当然责任全在你。但是当你设定了规则，但是客户他不用，可是你又没有证据（如果你想取证，那么又需要你在现有的机能里面追加各种证据保存。比如各种日志）。然后出事儿了就开始扯皮了。
所以老实儿的想第一种吧。其实自动化维护也是一门学问。微信现在的公众号已经做的比较人性化了。