主持人：冯大辉

主持人：冯大辉 孙朝晖：如果你计划在技术体系中引入开源软件，评估的过程是怎样的？关注点有哪些？ 李祎：作为互联网企业，我们讲求的是快速开发。使用开源软件能有效地缩短开发时间，而且流行的开源软件由于源码开放，比我们自己编写的代码更稳定和可靠，所以我们在说客网站的开发中经常使用开源软件。在评估是否使用一款开源软件时我更关注下面几点。 许可证(license)授权使用范围是否可商用。我们开发团队中的任何人建议使用一个新的开源软件时，都必须在邮件中写明它的授权范围。好在我们使用的都是圈内已经很成熟的开源软件，到目前还没有出现过因为违反许可证而被迫中止的情况。 确认有足够的技术经验能够解决可能带来的技术风险。这里的技术经验是指有能力配置和编译代码，能够根据项目需要定制和裁剪开源软件。如果没有足够的技术经验，在系统开发的中后期(测试期间和上线运行后)容易出现异常和不稳定，从而给公司带来经济上的损失。例如139网站的后台服务都使用了自己编译和裁剪过的JBoss开源应用服务器。因为有这方面的专家，当后台服务出现服务响应缓慢或异常宕机等性能问题时，都能准确及时地找出错误来源，避免了开发工程师只根据问题的表象怀疑是JBoss的Bug，而延误问题解决的时间。 尽量限制开源软件的使用范围，防止项目因为过度使用开源软件的某些特性而被绑架。所谓被绑架，就是面对开源软件带来无法解释的技术异常时而束手无策，或是发现系统需要迁移到其他同类型开源软件的代价异常高。最好的办法是对开源软件进行一定的接口封装，方便替换和扩展。例如139网站的后台系统大量使用到Memcache，我们在项目初期使用Danga Memcache客户端时，在它的上层封装了一层代理框架。后来很方便地将所有后台系统统一替换到性能更佳的Spy Memcache客户端。我们还计划引入Redis，那样的话在代理框架下扩展会非常容易。

回答嘉宾李祎

提问嘉宾孙朝晖

孙朝晖：你们做灰度发布和A/B测试吗？如果做的话，在架构上是如何支持的？ 李祎：A/B测试也是一种灰度发布方式，让一部分用户继续用A，一部分用户开始用B，如果用户对B反应良好，那么逐步扩大范围，把所有用户都迁移到B上面来。现在比较通行的实践方法，是在用户登录网站完成认证后，根据用户ID Hash后均衡地重定向(Redirect)到A服务器和B服务器。为了分析用户对A和B的反馈，在页面表单(Form)中用户可能和网站产生交互的地方都加上标签(Tag)，根据统计Web服务器的访问日志(Access Log)中URL所带的不同Tag来分析A和B上用户的反应。 在这方面我们做了一些简单的尝试。在改版的新版本上线前，邀请一些用户参与评测和反馈调查。具体做法是在用户PC上配置hosts文件的方式，将域名指向新上线版本的目标服务器IP。我们在灰度发布框架上没有进行更深入的开发，主要是由于开发资源不足、投入产出比不高而搁置。另外，灰度发布和A/B测试存在一个很大的问题—它极度依赖收集到的A/B用户群反馈结果的精确度。互联网的产品总是会不断升级，页面上的变化如果不是大的改版，很难在A/B用户群的反馈结果中明显区别出来。而且，在进行大的改版时，由于开发时间紧迫，开发团队往往会忽略加上统计需要的Tag，导致统计结果不尽如人意，不能完全起到指导产品升级的作用。 孙朝晖：随着系统规模的不断扩大，自动化部署成为必备武器，在你的组织内是怎样解决自动化部署问题的？都采用了哪些技术？ 李祎：自动化部署能有效地减少上线过程中的人为出错，增加系统稳定性，减轻开发工程师工作量。建议在有人力允许的情况下尽量实施自动化上线部署。当网站进入运营阶段新功能开发逐渐减少后，架构师的工作重心就要移到如何保证系统稳定的运行上。除了建立有效的监控和预警机制外，梳理上线流程、减少人为犯错的可能性以及灾难发生后的快速恢复，都离不开自动化部署。 先举一个自动化部署的极端例子。我在2006—2008年担任源讯公司(Atos Origin)的开源软件专家全程参与了北京奥运会IT集成工作。由于奥运会IT系统“不会有第二次机会”的特殊性，IT系统的自动化部署是我见过规格最高的。我们所面临的任务，是对奥运会包括10000台计算机、1000台服务器、1000多套网络设备和4000多台打印机在内的所有IT设备进行配置、分发，并配送到北京、天津、青岛、中国香港等70个奥运场馆。17个工程师组成的软件分发团队，用了近两年时间，对每一类服务器需要安装的系统和应用软件都进行了电子化配置。如果需要安装一台比赛用的服务器，比赛场馆的IT经理只要登录配置管理系统，点击鼠标，选择需要的服务器编号就能完成。在奥运比赛期间，如果信息中心或全国任何一个比赛场馆的服务器出现故障需要替换，新的服务器从硬件上架、插电、自启动、安装软件，到上线提供服务，全程只需要两个小时。 在139网站的这几年，我们也在一直努力摸索适合自己的自动化部署方式。复杂的后台系统在上线，需要由开发部门向运维部门移安装部署手册，不然运维部门有足够的理由拒绝接手。我们对用到的系统和应用软件都做了统一的rpm包和配置管理工具。系统工程师根据部署手册中配置定义的描述和安装步骤，按要求进行服务器安装，全程不需要开发工程师干预。对于前端PHP代码上线，使用统一的上线系统进行上线管理。开发工程师通过svn提交的代码统一由上线系统复制到线上的PHP服务器群，保证所有服务器上代码的一致性。后端JBoss服务器应用war包的更新，也由测试人员提交到svn服务器，运维人员使用脚本进行系统更新和重启。 自动化部署并不深奥，关键是要求架构师有很强的协调力和执行力。完成自动化部署的工作通常介于开发团队和维护团队的中间地带，由于它所能带来的好处对双方都不明显，通常在两个团队间会遇到很大的阻力，都不愿意去做这件事。推进这件事情的关键就是如何说服双方的领导，协调好资源，拿到尚方宝剑推进这件事。 孙朝晖：目前你的组织内是否具备了根据性能需求动态伸缩的应用部署基础架构？如果有的话，是怎样建设的？如果还没有，你怎样看待这个问题？ 李祎：关于可动态伸缩的应用架构，现在比较流行的架构是：多台REST服务器做后台服务，前端PHP负责页面展现，用户和页面的交互请求通过Nginx做负载均衡后分发到后台服务。139的说客平台就是基于上述架构(参见图1)。由于后台服务器所有操作都和用户状态无关(stateless)，就不必考虑用户的会话(session)和上下文(context)的一致问题。用户和网站页面的每次交换，通过Nginx分发到任意一台后台服务器进行处理。配合合理的系统监控，例如对服务器CPU等基本情况或接口响应速度等指标，就能很方便地发现系统现有能力是否满足需求，是否该通过向集群中添加服务器达到扩展之目的。 孙朝晖：在你们的系统中，是否在设计与开发阶段就预留功能降级的接口，以应对突发故障？请举例说明设计的原则和实施方法。 李祎：我们后台系统提供的接口，都带有version字段，以确认调用的接口版本，新的接口向下兼容老版本。不过到现在为止我们还没有遇见过因为故障强制降级的情况，有两方面原因：一方面后台系统上线时对接口都会进行详细的功能、性能测试；另一方面，突发故障多半是由于新功能的上线引起，最好的方法还是直接回滚到稳定版本。 在稳定版本中遇到突发故障，多数原因是调用第三方接口时由于对方接口效率原因而严重影响网站自身的服务。例如用户在网站注册时需要通知第三方游戏也开通账户，而第三方开户接口效率太低，导致网站的通知队列堵死，很多的第三方调用线程挂死导致网站服务宕机。我们吃过几次这样的亏，后来要求调用第三方接口时，如果不能异步处理，都必须有开关配置，并对第三方接口加上监控和预警，当发现调用对方响应太慢时直接修改配置以关闭第三方访问。 孙朝晖：如果你已经选用了NoSQL数据库，请问你是如何解决数据老化问题的？ 李祎：在这里介绍一下我正负责的一个图形数据库项目Skull DB是如何解决数据老化问题的。 相对于其他类型的NoSQL数据库，我们的方案也有一定借鉴作用。图形数据库是专门用来存储例如社会关系这样复杂的网络结构的NoSQL数据库。我们用Skull DB存储用户的收听关系、评论和转发数据。使用Hadoop的MapReduce框架来访问这些海量数据、计算亲密度、关系度、HITS等指标。关于图形数据库以及Skull DB具体实现细节，我以后再写文章详细阐述。 简单地说，Skull DB的技术实现是使用Memcache作为核心数据缓存，底层用Solr和Lucene负责物理存储和索引，用MemcachQ来保存Database中数据变动消息(Event)的一个集成系统(参见图2)。 当Skull DB被访问时，先访问Memcache，如果找不到数据，再访问Solr。当Skull DB 中数据发生更新时，它将更新消息(Event)提交到MemcacheQ中，由负责监听的事件后台进程(Event Deamon Processor)处理更新消息，更新Memcache和Lucene索引。事件后台进程(Event Deamon Processor)提供订阅接口(Subscriber)来监听各类消息。Skull DB通过订阅接口(Subscriber)注册监听数据更新消息，发现数据项A有更新后，检查A相关的所有数据，找到已经过时的数据项进行物理删除或者归档。 嘉宾寄语： 在写这篇文章之前拜读了前几期《架构师接龙》栏目的几篇文章，总体感觉还是很有收获的，不过部分文章理论多，实际的项目例子少，让我读着稍觉乏味。其实国内外IT圈子的技术，有心的读者通过互联网或书籍，大致已经有所了解。大家阅读《架构师接龙》，关心的还是这些技术在实际项目中运用效果如何，了解同行是怎样用这些技术去解决实际问题，从中相互学习和借鉴，获得更多的项目经验。所以真心希望《架构师接龙》将来的作者，少一些空谈，多一些实际项目的解决方案。写文章不必过分担心泄露公司机密而遮遮掩掩。我个人认为，国内的IT项目所使用的技术大都是学习国外项目的经验，再根据自身的需求进行定制，并没有那么多高精尖的东西需要保密。希望国内的IT技术人员通过《程序员》形成一个氛围良好的圈子，互相交流，共同进步！ (李祎) (本文选自《程序员》杂志11年06期，更多精彩内容敬请关注06期杂志) 《程序员》6期精彩内容：移动应用的成功法则