真的能1个用户帐号登陆所有网站，问U盟？

真的能1个用户帐号登陆所有网站，问U盟？

    “1个用户帐号登陆所有网站”，这是笔者在U盟网站首页看到的醒目提示。

    是真的能实现吗？如何实现的？好用吗？安全吗？。。。。。。

    带着一连串疑问，笔者继续打开U盟网站http://1users.com，一探究竟。

    发现UID和登陆码，是U盟用来让持有UID的用户得以登陆所有支持UID登陆网站的关键，
也就是说，当某个用户注册了UID，然后用登陆码做为密码就可以登陆其他所有网站了。根
据笔者现在所看到的理解就是这样的。

    这让笔者联想起曾经也在倡导这一理念的“开放ID(OpenID)”的兴起和衰落，或许很多
业内人士都根本没听说过开放ID是怎么回事。

    开放ID(OpenID)是什么？
    OpenID 是一个以用户为中心的数字身份识别框架，它具有开放、分散、自由等特性。
    OpenID 的创建基于这样一个概念：我们可以通过 URI （又叫 URL 或网站地址）来认证
一个网站的唯一身份，同理，我们也可以通过这种方式来作为用户的身份认证。由于URI是整
个网络世界的核心，它为基于URI的用户身份认证提供了广泛的、坚实的基础。OpenID 系统的
第一部分是身份验证，即如何通过 URI来认证用户身份。目前的网站都是依靠用户名和密码来
登录认证，这就意味着大家在每个网站都需要注册用户名和密码，即便你使用的是同样的密码。
如果使用 OpenID，你的网站地址（URI）就是你的用户名，而你的密码安全的存储在一个OpenID
服务网站上（你可以自己建立一个 OpenID 服务网站，也可以选择一个可信任的 OpenID 服务网
站来完成注册）。
    登录一个支持 OpenID 的网站非常简单（即便你是第一次访问这个网站也是一样）。只需要
输入你注册好的 OpenID 用户名，然后你登录的网站会跳转到你的 OpenID 服务网站，在你的
OpenID 服务网站输入密码（或者其它需要填写的信息）验证通过后，你会回到登录的网站并且
已经成功登录。 OpenID 系统可以应用于所有需要身份验证的地方，既可以应用于单点登录系统，
也可以用于共享敏感数据时的身份认证。

    这就是开放ID(OpenID)，以上解释来源于OpenID官方网站。http://openid.net.cn/
    笔者理解：OpenID就是依靠URI（一长串网站地址）到一个可信任的 OpenID 服务网站来验证身份的。
    那一长串URI很是难记忆，基本上要靠你自己Copy来贴上去，提交后再弹出个OpenID服务网站
来让你输入密码，来完成登陆过程。首先不说那一长串很难记忆URI，有多麻烦，那些众多的
OpenID服务网站是否就真的可信任吗？谁可以做OpenID服务网站？有什么审核过程吗？我们的
密码都在各些OpenID服务网站上，恐怕很难保证安全吧。种种不便与不信任，导致OpenID渐渐
衰落。或许要等全国人民都讲诚信的时候，OpenID兴许就能为我们服务了。值得期待。

    要不要再来聊聊：我国的诚信体系啥时候健全，笔者看还是不在这里讨论了。

    还是说回就笔者目前了解到的U盟UID吧。先来比较下UID和OpenID。

    1.帐号：
    >>OpenID这边叫：URI,（又叫 URL 或网站地址），他是由OpenID给出的，难于记忆，不能自由组合。
    >>U盟这边叫：UID，由用户自己注册申请的，可以自由组合，例如用自己名字的拼音。
    2.密码：
    >>OpenID这边：弹出个验证窗口，到众多的OpenID服务网站之一去验证密码。（很多人有你的密码）寒。
    >>U盟这边:密码就是登陆码，只由U盟生成，通过后台接口访问，是随机的，一次性的，设有效时限的。
    3.适用领域:
    >>OpenID这边：非金融。
    >>U盟这边：任何领域，甚至更安全于现有金融系统登陆认证方式。

    笔者看出，OpenID比较聪明的是：自己只制定标准，服务则由众多的OpenID服务网站来提供。
    而U盟完全由自己提供验证（接口）服务，虽然这样做相对安全，但如果数据流量一大了，U盟能顶得住吗？
    使用中java服务会不会突然蹦掉？
   
    在J2EE群集部署方案中，虽然目前的企业应用都强调了应用服务器提供的Session复制功能，EJB调用的负
载均衡能力，但是考虑到目前J2EE潮流发展的趋势，已经不再使用EJB的负载均衡，同时Session复制也被证明
为影响cluster水平扩展的主要障碍之一。因此对于大容量的J2EE水平扩展群集而言，保持每个节点的无状态性，
不再使用Session来保持全局状态是必经之路。因为只有每个JVM进程不保持全局状态，才能够保证n个JVM节点
的幂等性，那些所有涉及到全局状态的，必须放在JVM进程之外，例如用户ID可以使用cookie，session可以放
入数据库，文件可以放在共享存储系统中。 这样的方案做下来，前端的apache也仅仅是一个HTTP请求代理，后
面的应用服务器实例几乎是可以无限水平扩展的，瓶颈永远不会出现在应用服务器层，只会出现在apache端，
或者数据库端。当然apache不行，还可以用lighthttpd，甚至使用四层交换机硬件进行请求的分发工作，后端
的单台数据库不行，还可以使用多个数据库同步复制，甚至使用Oracle Grid。这种群集部署方案下面，
web server退化成为一个请求分发代理，找不到任何理由使用apache了，对，是lighthttpd出场kick off apache的时候。
如果网站容量大到连lighthttpd都无法及时分发请求的时候，你还可以用四层交换机来分发请求，那lighthttpd也该被kick off了。
只有硬件管够，不管是J2EE，PHP，.NET，还是Rails，都有近乎无限的水平扩展能力。或许U盟根本不担心如何保障服务
稳定性的问题，因为解决方案已经很成熟了。

    再来展望下U盟的命运几何呢？
    目前国内的大型网站大鳄云集，新浪有新浪通行证，网易有网易新浪通行证，腾讯有腾讯通行证，盛大有盛大通行证。。。
但凡大鳄都有自己的通行证，似乎都想把网民们禁锢在自己的王国里。U盟在夹缝中如何动作？求存，还是被吃掉，
笔者也不帮他去想了。

    总的来说U盟的UID对于我们广大的网民来说，总算是有用处的。