2010年2月28日

在做事的方法上，不好的总比好的要多，而项目规划也不例外。下表是作者曾经看过的一些不良做法，可作为分辨做法好坏的参考。目的是希望当状况发生时能协助你分辨，以及了解为何这些做法有问题。

拙劣做法	实例	为何发生	问题
做上次做过的事	3.0版就像2.0版，只是比较好	通常是因为不想回头对商业、技术和顾客议题做新的研究，或者没有资源	从2.0版以后，世界可能已经改变。没有探讨2.0是否满足其目标，规划就会变成灾难
做上次忘了完成的事	2.0版没做的功能会是3.0版的核心	上次没做完的项目可视为被完善理解，而且已部分完成，因此很容易着手	所做的功能并非重要功能。将新版聚焦在那些功能上，可能错失资源配置的最佳化
做竞争对手做的事	我们的目标是X产品有什么功能，我们就有什么功能	这些最简单的营销策略，可以满足偏执、没安全感以及惰性。不需要做任何分析	竞争对手会这么做，也许是因为很蠢的原因
做最热门、最流行的东西	5.0版以Java来做，支持移动设备，兼容RSS4.0	流行之所以是流行，因为易于追随而且有趣。人们对流行总是会兴奋，对令人厌倦和定义不明的项目而言，可以轻易增添兴奋感	革新是很少有的。科技进展总是短期高估，长期低估。顾客问题应该摆在流行时尚之上
做了，顾客就会自动上门	X项目将是当今最佳的搜索引擎/网站编辑器/窗口小部件/捕鼠器	借由把每个人的焦点转移到构建本身，而非构建的理由，人们有时可能避开真实的规划	这个世界需要更好的捕鼠器吗？人们会上门是因为所做的东西对他们有用，不是因为团队决定要做什么东西

  2010年1月15日

《论信息系统的架构设计》

作者：郭云斗(http://guoadou.cnblogs.com/)

【摘要】
　　本文讨论多网站集成单点登录(SSO)系统的架构设计。该系统主要实现了对同一企业集团旗下多家互联网站不同用户系统之间的集成，用户只要登录其中一个网站，无需再次注册，即可使用集团旗下其他网站的服务，在改善用户使用便利性的同时，提高了各个网站的用户访问量，更大大降低了新加入网站的推广费用。

　　在集成单点登录系统设计架构中，整个系统分为管理中心与 CP 两个部分。管理中心是整个系统的核心，负责保存旗下所有网站用户账号之间的对应关系(Mapping)，以及颁发认证 Ticket；CP即是各个网站。在架构设计中，充分考虑了系统的可扩展性、稳定性、安全性、可维护性、灵活性等因素。

　　作为集团旗下某社区网站的技术负责人，我参与了本系统的需求分析和架构设计工作，并主持了为接入系统而对本网站的改造工作。

【正文】
　　我在一家互联网企业工作，母公司某集团把信息服务当作主要的发展方向之一，互联网业务成为了发展的重心。2009年集团已经拥有包括社区、文化、娱乐、音乐、网络游戏、B2C网上购物、票务、电子地图等行业在内的10个网站。2008年下半年集团投资4000万美元新成立一家B2C网上购物电子商务网站，该网站于2009年4月正式发布，但刚一上线就遇到了推广的问题。目前国内电子商务网站平均推广一个新会员的成本超过30元，广告投放效果不尽如人意，高额的广告支出费用与带来的用户及销售额形成巨大的反差。如果能把其他已经运营多年的兄弟网站的数千万用户成功引导到新成立的电子商务网站，无疑将大大降低广告推广的成本，而且对于已经对一个网站非常信赖的忠实用户来说，也更愿意尝试使用由自己信赖的网站所提供的“新服务”。鉴于此，集团领导决定建设一个能把旗下各个网站无缝结合起来的系统，以达到以下三个目的，第一，原网站中的用户可以非常方便地转化为新网站用户，降低推广的成本；第二，新网站所投放广告带来的流量可以很方便地延展到其他网站，提高推广的效果；第三，系统需要是非常容易扩展的，集团目前正在洽谈收购一家国内领先的娱乐资讯网站，要非常方便地集成未来可能的更多网站，达到滚雪球的效果。这样的话，就能更方便地为用户提供一站式的服务，在激烈的互联网竞争中体现集团规模优势。

    作为集团旗下某社区网站的技术负责人，我有幸参加了该项目的需求分析和架构设计工作，与另外几个公司的技术负责人组成项目小组，经过多次讨论，决定采用单点登录(SSO)的方式来构建本系统，在架构设计中，充分考虑了系统的可扩展性、稳定性、安全性、可维护性、灵活性等因素。

　　通过系统分析，我们发现该系统建设中主要需要解决以下问题：

　　1)各网站是不同时期由不同团队创建，分属不同的子公司运营，采用的开发语言与技术架构平台不尽相同，有php、java、.Net，还有asp。操作系统有windows、linux、HP Unix等，数据库也是各不相同，分别有mysql、SQL Server、Oracle、Sybase 等等。
    2)各网站业务和用户政策不同，有的网站使用email、手机号作为用户账号，有的使用英文数字字符串，也有用中文的。
    3)各个网站加起来共有近五千万注册用户，每天活跃用户上百万，SSO系统需要能够承载每天数百万次的访问量。
    4)为了SSO 系统今后联动更多网站的可行性，需要确保系统的扩展性和稳定性。
    5)发生SSO 故障时，各系统可以独立运行。
    6)最小化各系统连接时可能发生的用户信息泄露。
    7)各子公司为接入本系统的改造成本不能太高。涉及底层的改造工作，需要抽调多名对自己系统最有经验的技术开发人员，一旦各子公司由于自身项目受到影响，未能全力支持配合，SSO 项目势必延误。

    基于这些问题，我们把整个系统分为分为管理中心 与 CP两个部分。管理中心是专门为SSO服务的一组服务器，CP即是各个网站。

    为了避免单点故障及降低系统改造/维护的难度和成本，并没有把所有网站的账号/密码全部集中到一个地方进行管理，而是由各个CP自己进行验证，管理中心负责保存旗下所有网站用户账号之间的对应关系(Mapping)。CP为管理中心提供验证用户ID/密码的接口，通过管理中心的转发，即可实现跨站点登录。一旦管理中心出现故障时，只是SSO部分的功能不能正常使用，各个网站自己的用户登录/注册并不受影响。

    管理中心和CP之间通过Server to Server 的方式进行通讯，各CP之间通过http cookie来共享信息。CP在用户本地登录成功时，将用户的唯一标识及用户名/昵称发送给管理中心，然后把管理中心返回的 Ticket 信息以http cookie的方式写入需要进行联动的网站根域，这样当用户在来到其他网站的时候，网站根据cookie中的Ticket 信息向管理中心查询得知当前用户的身份，然后自动替用户登录，这样旗下所有其他的网站就成了该用户的“增值服务”。整个系统中所有通讯都是基于标准http协议完成，编码采用UTF-8，与具体开发语言及系统平台无关，各网站只需要和管理中心打交道，不直接与其他网站进行通讯，这就保证了架构的松耦合与扩展性。
   
    为了降低各CP工作量、开发难度及调试时间，由负责管理中心的开发小组开发了client lib 提供给各 CP, client lib 包装了加密/解密以及与管理中心通讯的API接口，CP只需要关心自己网站的业务逻辑，使用管理中心分配的 SiteId/PW 即可与管理中心进行通讯，无需关心底层的具体实现。目前开发了c和java两个版本的client lib，同一套源码在windows和linux/unix下均可正常编译使用，足够满足现有10个网站的需求。

    为了最大限度保护用户信息，防止用户信息的泄露，所有的用户详细信息都是保存在各个CP自己的数据库中，管理中心仅保存唯一标识。管理中心与CP之间的通讯信息以及http cookie内容均进行了加密，每个CP的密钥不同，CP的内部员工也无法解密另一个CP加密的信息。当用户在任意网站进行登出(Logoff)操作的时候，通过调用管理中心的综合Logoff Process ,会同时删除所有关联网站域下的cookie。另外用于跨站点登录的sso cookie的有效期设置为 session 级，这样cookie就只会存在于用户电脑的内存中，而不会被缓存到硬盘上，只要关闭浏览器，cookie就消失了。即使cookie信息被破解，得到的Ticket也只是一串无意义的字符串，超过一定时间期限后，管理中心会把Ticket设为过期。

    管理中心由一台L4交换机做负载均衡，后端是Web服务器集群及数据库服务器。管理中心应用程序采用J2EE架构开发，数据库使用Oracle，在性能、稳定性、技术成熟度及开发人员熟练度方面都有保障。

    该集成架构以松耦合的方式对多个网站进行了整合，复杂度都放到了管理中心端集中进行管理，具有良好的扩展性，新网站通过少量的改造即可加入，并通过各种安全措施最小化用户信息泄露的可能性。在开发途中遇到一个之前未考虑到的问题，其中一个网站采用了http session的方式来进行登录验证，而不是cookie，导致其他网站在进行Logoff的时候无法通过清除cookie的方式来同步退出，造成了安全隐患，目前是通过由该网站提供一个接口特殊处理的方式临时解决，最终还是需要该网站把自己的登录验证机制从session改为cookie方式。

    该项目于2009年5月立项，经过需求分析、设计、开发，管理中心于2009年9月完成测试上线，第一期包括电子商务网站在内计2个网站完成接入改造。经过上线一个多月以来的观察，整个系统响应快速，运行稳定，各网站的用户访问量均有明显提高，通过SSO系统引导到电子商务网站并消费的用户数量与质量远远超过同期广告推广的效果，基本达成了系统的目标。