多项目背景下的用户中心的架构设计

jonas401 2012-12-19 06:32:11

背景：
1 有项目A, 项目B，项目C(有客户端，有Web)
2 需要架构一个跨跃3个项目的用户中心
3 用户中心需要包含帐户系统，用户增值系统
4 各项目之间要能共享登陆状态

困惑：
1 用户中心的接口设计
2 服务于三个项目的增值系统怎么设计，比如VIP，虚拟货币消费
3 会话ID的过期机制

...全文

1630 10 打赏收藏转发到动态举报

写回复

用AI写文章

10 条回复

切换为时间正序

请发表友善的回复…

发表回复

jonas401 2013-01-05

打赏
举报

感谢sp1234和Kshatriya，跟我的思路差不多 btw, 我喜欢Kshatriya的总结，简单，直接

Kshatriya 2013-01-04

打赏
举报

支持sp1234，用户中心必须与增值系统隔离，让增值系统作为上层的一个系统进行构建。用户中心的职责必须脱离业务，只负责用户、部门、用户属性及关系、单点登录。其他任何与业务有关的职责必须从用户中心剥离，与用户中心的接口只有单点登录和数据接口。

以专业开发人员为伍 2012-12-26

打赏
举报

不管是设计什么CMS、人潮、权限还是什么别的子系统，其实都需要比较专业。这就好象是一个配钥匙的人，他不能连人家家务事（谁有权利拿哪一把钥匙）也多管闲事，他就应该把自己当作是一个服务于人家配钥匙的工具、而不是管理人家钥匙。

以专业开发人员为伍 2012-12-26

打赏
举报

你的各种业务系统，既可以接上自己的超级简单的用户中心，又可以接他负责设计的“系统”。这样你就可以一边做好自己的开发工作，一边静观好戏上演。

以专业开发人员为伍 2012-12-26

打赏
举报

“要求用户中心把所有项目的业务逻辑全放在用户中心处理”这往往来自于“人品问题”而非“技术问题”，所以你辩论不过他。当他感觉技术上把握不了、而时间很紧，那么你设计的任何方案都可以很容易被采纳。反之，当他觉得只要招聘两个稍微懂一点编程的人已经可以“支撑”下去了，他可能很以为已经不需要设计技术、只要功能分解分解给新人这样就能把设计责任推卸给新人了，他此时不需要在关键时刻能够力挽狂澜的人了。我给你的建议，做个超级简单的“用户中心”作为备用，同时让他随便去设计（你不要参与设计）。专心做好你自己的专业业务系统，突出业务重点和技术创造力，而跟那种抄袭OA权限管理系统的所谓“设计”形成鲜明对比。剩下的，就不是你所能把握的了。也许有一天，你通过几个赚钱的系统的开发经验，最了解是那么样的“用户中心”才是开发周期最短、（一年内）价值最高的方案。这时候你可以考虑跳出之前的圈子，找到自己的开发人员。

我不懂电脑 2012-12-26

打赏
举报

用 biztalk做门户

ycproc 2012-12-26

打赏
举报

其实放在哪儿没有那么多争执的，不管放在哪儿都要解决和保证一致性、可用性等原则。如果只是物理的存放位置差异而设计上没有太多依赖那样就更好了。

jonas401 2012-12-25

打赏
举报

其实呢，自己是有实现思路，只不过，以前没做过，而且也没经验可以借鉴，心里对自己的实现方式没有多大的信心。我的实现方式，跟fengyarongaa推荐的方式差不多，只不过，我的需求里，有客户端软件，有网站，还涉及到客户端软件向网站的登陆状态的共享。目前，用户系统的打通以及会话的维持和过期也有了可行的方案并已实现。凝惑的另一个问题，基于用户系统上的各项目的用户增值业务和业务数据，到底是放在用户中心，还是放在各项目自己的服务端。依照普遍性和特殊性的原则，我坚持各项目通用的业务放用户中心，项目特殊页面放在各自项目的服务端，这样就尽可能减少用户中心对各项目业务逻辑的参与，减少用户中心没必要的复杂度。但是，公司的产品总监基于以前的技术经验，要求用户中心把所有项目的业务逻辑全放在用户中心处理，这种方案我视之为不可理喻，可以想像，以后的用户中心将成为一个超级复杂的大杂绘。但是，因为没有可以现成的项目经验和案例来提供有效的说服务，以QQ的用户架构来参数，他又以人家是大网站，业务复杂度不在一个层次为由，拒绝接受我的方案。所以，就困惑了。。。

ycproc 2012-12-20