架构师问答系列001

提问嘉宾：

盛国军，上海麦考林信息科技有限公司首席架构师。曾历任8848软件架构师、光芒国际磊客中国技术总监。具有10年互联网和电子商务开发经验，5年软件架构师经验，3年两千万美金投资的大型网站技术总监管理经验。

回答嘉宾：

栾义来，凡客诚品(北京)科技有限公司项目管理&架构总监，领导技术项目管理部门和架构师团队。曾在金山软件、我有网、FastMobile中国担任技术总监、资深架构师等职位。在电子商务、移动互联网、ERP等领域有丰富的架构和技术管理经验。

 

盛国军：我们知道缓存能够提升性能，但缓存有个致命的问题，就是对事实数据的改变不敏感。如何保持和协调缓存数据和事实数据的一致性？

栾义来：首先要理解“业务敏感度”的问题，也就是说从业务的角度对于缓存和事实数据不一致的容忍程度，不同数据对于一致性的要求是不同的。举例来讲，用户评论对不一致是不敏感的，可以容忍相对较长时间的不一致，这种不一致并不会影响交易和用户体验。而产品价格数据则是非常敏感的，通常不能容忍超过10秒的价格不一致。

对于MemCached的远程的集中式Cache，在高负载下序列化和反序列化的开销是很大的，所以我们设计了本地进程内Cache和MemCached两级缓存的支持。例如分类数据、促销规则数据等都可以放入本地Cache。

对于事实数据变动与缓存的一致性问题，不敏感数据可以依赖“缓存过期”，根据不同的业务敏感度设置不同的过期时间，属于被动更新策略。也可以使用主动更新策略， 事实数据变动后将变动的“业务ID”放入“过期队列”， 各缓存节点通过Polling的方式定时读取数据变动通知，并将Cache对象删除或直接更新。在下次访问的时候，就可以保持与事实数据同步了。

盛国军：从架构的观点讲，目前正在解决的主要问题领域有哪些？

栾义来：从业务的角度，我们可以简单的把电子商务分为几个部分：

1．订单的购买达成阶段可以称为体验购买系统，如购物网站的商品展示和导航、购物流程、商品搜索、互动交流等；

2 ． 订单达成后的订单处理系统，包括订单在生命周期的各个流程处理，如订单在仓库的各种处理、配送管理、退换货流程等；

3．后台支撑系统部分，如供应链、WMS、财务等系统；

4．数据分析和运营支持部分，包括运营管理平台、商业智能等。

这里先从前两个部分介绍一下我们的经验，在体验购买阶段，架构关注的是访问速度和用户体验。对于这个阶段我们主要关注以下三个方面：

1.缓存的使用，如上题中提到的本地分布式缓存框架；

2.购物流程、商品展示、其他部分的隔离和异步化处理；

3.内容搜索和购物推荐。订单处理系统，它的性质是一个复杂业务逻辑系统，架构关注的是领域模型的有效规划、处理流程的引擎化、SOA业务治理。

我们是这样理解的，首先这是一个基于任务队列的工作流引擎，订单在整个生命周期中都是处于工作流程上的某个状态上，每一个处理环节都是一次状态迁移，这种迁移或是主动的或是被动的。还有一个核心的概念就是关于“资源”和“资源移动”的抽象，我们可以将在流程处理中涉及的各个要素都称之为企业的资源，如：企业拥有的商品，需要处理的各种支付和收款账户。我们大部分的处理流程都是围绕着这些资源的“移动”。

盛国军： 当对象（ 业务实体）需要通过网络传递时，需要把对象序列化和反序列化，请从性能、易用性、可扩展性的角度来谈一下可供实现的技术（XML 、JSON、二进制等等）的优缺点。

栾义来：首先尽可能不要分布你的对象，避免你的业务实体在网络中传输，如果非要进行传输不要去传送细粒度的业务实体，而是把他们“压扁”组合成DTO。从性能角度来说，经过测量，二进制当然是无可争辩的性能王者， 二进制序列化对CPU的占用和对网络的占用都是要小于XML和JSON的序列化模式的。从易用性角度来说， 每一种序列化模式都有良好的流行框架的支持，XML更适合与旧系统和异构系统交互，JSON更适合AJAX应用，而二进制则更适合在内部网络中使用。从可扩展性角度来说，二进制格式受制于具体的平台实现， 几乎没有扩展的余地，而XML和JSON是基于文本的，扩展性不错，XML更是生来就是为了扩展用的，可以自定义XSD、NameSpace等。除了流行的几种序列化格式，通常在对象结构不复杂的情况下实现者还会自定义一些序列化方式。比如，把一个用户对象序列化为类似“user_id|user_name,user_nick|user_level|user_address”的格式。这样做的好处是非常Handy，序列化和反序列化都非常简单。但是，对象结构变得复杂之后，就会遇到很多的问题，比如分隔符的转义等，并且如果自定义格式设计不好的话，扩展性也不高，所以要限制这种自定义格式的使用。

盛国军：对一个流量较大的网站来说，用户访问行为这部分的数据量很大，请问有什么好的方式来记录和分析？

栾义来：用户访问日志有两种，一种是Web Server自有的日志，如IIS的日志，另一种是企业或第三方公司单独记录的日志。要能分析对企业有价值的信息，只通过Web Server的日志是不够的。例如分析用户购物车产品添加和删除的变化过程，就必须自己记录了。

从记录上来讲，以IIS为例说一种解决方案，可以编写一个“用户行为记录”的Http Module，拦截用户的Http Request并根据自己的需要生成“用户访问行为”数据，如用户是否登录，当前购物车里的商品ID列表等。发送到日志服务器上的MSMQ日志消息队列中。在日志服务器上的日志记录监听线程读取消息后写入的txt日志文件。对于MSSqlServer可以定期的buck insert到日志分析数据库中，对于其他方案可以分发到日志分析服务器上。

从分析上来讲，对于中小网站，利用传统数据库使用SQL进行分析还是比较简单高效的方式，省去了分布式计算环境部署和维护的麻烦。对于超大容量的日志分析问题，就只能使用Hadoop这种MapReduce分布式计算环境进行处理了。关于这方面的内容，网上有很多参考资料。

盛国军：对于一个周期较长的项目，会面临很多风险，如人员离职、架构选型、需求变更等等，作为架构师应该如何把握和协调，以降低可能出现的风险？

栾义来：首先是人的问题，必须是靠谱的人才能干靠谱的事情。任何一个项目每天都会面临各种风险，有效的风险控制机制是项目成败的关键。需要明确架构师在组织中的职责范围，如果是在项目经理负责制的公司里，架构师通常只需要专注在技术架构的设计和评估，其他的风险因素是项目经理需要解决的问题。但在做架构设计时，不能只从技术的角度考虑，还必须综合考虑项目组技术水平现状、项目在公司业务层面的地位和影响、是否按技术路线图规划等因素。“每日风险评估”是个很好的控制风险的方法，针对可能出现的风险要清楚地将“影响范围、重要程度、应对策略、解决时限、负责人”列出来，并进行每日复查。必要时升级警报级别，及时让更有权威的干系人进行协调和干预。有时候我们更多的应该是做减法，重要的是我们不做什么而不是要做什么。

对于激烈竞争的电子商务领域来讲，在可控范围内尽快将项目完成并交付市场检验，接受反馈然后再持续改进，远比交付一个虽然“架构完美”但错失市场良机的项目要好。

（本文来自《程序员》杂志2010年1月刊）