22

架构师接龙:盛国军&栾义来

作者: chenqiuge 分类:CTO视点   阅读:16,526 次 添加评论

提问嘉宾:

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


回答嘉宾:

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


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


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


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


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


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


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

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

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

3.后台支撑系统部分,如供应链、WMS、财务等系统;

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


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

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

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

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


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

接龙1-1


盛国军: 当对象( 业务实体)需要通过网络传递时,需要把对象序列化和反序列化,请从性能、易用性、可扩展性的角度来谈一下可供实现的技术(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月刊)


转播到腾讯微博

----->立刻申请加入《程序员》杂志读者俱乐部,与杂志编辑直接交流,参与选题,优先投稿

9 Responses to “架构师接龙:盛国军&栾义来”

  1. gcyy0106 说道:

    我草,让我很激动,我很想成为架构师。

  2. 923ali@163.com 说道:

    长见识

  3. zhangchui 说道:

    很受用。谢谢两位。

  4. tao 说道:

    很好,团队有这种人很…

  5. 混口饭吃 说道:

    这年月混口饭吃看来挺容易

  6. huwaipu 说道:

    牛人啊 学习的典范和目标!

  7. north face outlets 说道:

    good post! thank you for share it!

  8. 李祥 说道:

    团队合作最重要。

  9. buy north face 说道:

    to check out your website.

请评论

preload preload preload
京ICP备06065162