会员通行证系统构架经验总结

一、摘要

通行证系统用于在网群和应用间实现会员系统的同步并保持一致性，对用户体验和系统整个构架的质量至关重要。

本文将粗浅的列出几种实现通行证的架构思路，并针对不同规模的需求提出建议，欢迎各位高手赐教。

[b]本文不探讨无会员中心的通行证实现方式，尽管这样做可能会获得更可靠的系统稳定性和更高的执行效率，但是显而易见，维护起来对开发人员是一种折磨。[/b]

二、通行证构架

按数据冗余程度，通行证可大概划分为：

中心式：一个会员数据中心，其它所有应用都通过会员中心完成用户验证和基本信息存取，应用自身用到的会员相关信息保存在会员中心存储模型或应用自己的数据库里（比较常见）；

半冗余式：一个会员中心，提供用户验证、基本信息存取和通知机制，负载较大的应用将所有会员信息保存在自己的数据库中，并将每次信息变化经由会员中心通知机制广播到其它所有应用，实现同步更新；

冗余式：一个会员中心，提供通知机制，所有应用将所有会员信息保存在自己的数据库中，并将每次信息变化经由会员中心通知机制广播到其它所有应用，实现同步更新。

三、通信方式

会员中心提供API接口供所有应用进行调用，通信中可采用一定的加密手段以防截获或篡改（如使用HTTPS协议）。

一个API应当提供的基本功能有：

auth 验证会员密码

get 获取会员信息

set 设置会员信息

sync 验证同步Cookie

对接口调用参数的传递，可采用xml-rpc(soap)，或直接编码的形式（如json或直接GET/POST）。

如需要提供通知机制，则每个应用也应设计API接口，供会员中心提供通知。

一个通知API应当提供的基本功能有：

set 设置会员信息

四、登录状态同步

针对于所有应用在同一域（domain，如.luren.cc）的情况，可使会员中心的auth方法返回一个全局有效的Sync Cookie，每个应用登录时，都为客户端设置该Cookie。

当应用无法找到有效的用户验证机制时，通过sync方法从Sync Cookie中获取登录信息，并加入到自身的验证机制中。

对于不同域的应用，可以统一登录入口，在每个登录和注销页面都内嵌iframe设置各个域的Sync Cookie。

当然，不同步登录入口时，就一定要修改每个应用，增加iframe同步机制。