2014QCON参会小结

上周听了qcon感觉还不错，小结一下以备忘。

1. 一号店个性化架构

我对个性化策略方面了解太少，能理解的不多。一号店的个性化数据流是常用的模式：用户原始特征数据 --> 数据分析引擎 ---> 场景/产品线所需要的特征数据。

如果我来做这个系统架构部分可能会选择的方案是：利用Flume采集原始数据，根据业务场景来实现一个分析引擎。这个分析引擎应该分两类，一类针对批量处理，这时数据可以灌入HDFS然后通过MR模型计算；另一类对实时性有较高要求，这可以考虑基于storm来做（也可以自己做一个简单的）。最终产出数据如果是用于在线架构就需要一个对稳定吞吐友好的模块，比如redis。但redis的全内存模式成本太高，而leveldb还缺少开源的分布式框架。我认为比较快速的模式就是先用redis，然后同步开发一个基于redis协议、存储引擎是leveldb的分布式系统。等开发完成后替换原来的redis系统。

2.聚石塔

聚石塔这个产品属于阿里系的云平台类型，纯技术方案上的介绍不多。但以下几个部分的介绍很到位：

设想一下我们到了一个新部门（公司），部门原有产品的问题太多以至于很多人精力消耗在解决问题上。现在你作为主管来接手这个项目，应该如何做？演讲者给出了自己的理解：

1）还债：分析业务流程，做裁剪优化。逐步减少这块儿的人力投入；

2）定标准：一般大公司的面向用户的产品都是依托基础平台部门的支持，在产品初期，自己都不知道自己的未来将是什么样，基本上是怎么快怎么来。随着产品路线逐渐明朗，业务逐步增多。这种怎么快怎么来的模式就会非常消耗人力，系统稳定性也成问题。这时就需要由业务部门主导，建立对基础平台/外接服务的需求规范。后续各种对接模式必须按照规范来，这样才能把对接成本降低下来。

3）打基础：对核心模块的易用性、稳定性、灵活性重新review，以便未来可以更快的适应业务需求。这包括设计API、监控、控制台等。

4）监控：曾经我觉得监控这块儿的通用性很强，通过他的介绍发现这部分的业务性很强。所谓通用性强是指比较粗粒度的系统级监控，比如网络、内存、CPU、IO等。但随着多种业务混布后，这种粗粒度监控就不行了。比如，一台物理机上有多种业务模块，每种业务模块在用户量、用户消费量等都不通时，发生异常了如何评估损失和指定止损方案？这就非常依赖细粒度的监控，而细粒度监控就与业务模型有着较强的耦合。

另外，他介绍的其他几个点我也蛮喜欢的：

1）作为平台，应该提供的是服务。如果仅仅是提供基础组件，那就跟中关村卖内存的商户没啥差别。注：做PM时有一句话叫“用户的体验是完整的”，阿里面对的诸多用户核心是做生意，不是做技术。从他们的角度来看，你给我一堆基础组件有啥用？我还要去雇人做技术，而我关注技术仅仅是能否支撑住双十一，给我将那堆存储、云有啥用？但告诉我这东西可以帮我生成订单、让我看到销量我就会理解。

2）OP与RD的分工：在Amazon的时候，上线、异常处理等工作都是RD在做，OP的职责是为RD的运维类工作提供技术支持。比如，你RD觉得上线太费事儿，你别让我OP给你搞，你只需告诉我哪里不爽我给你做工具来提高你的效率。总而言之，让我替你做这种基础运维类工作，门儿都没有。国内没听说哪个公司采用这种模式，要么公司太小，RD兼职OP全搞；要么公司太大，RD仅负责开发，OP负责上线、异常处理。这种分工不仅不利于OP的技术成长，也不利于RD在系统方面的理解（包括稳定性、运维的思考）但想改变这个现状真的不容易，业务只有从一开始就这么搞才有可能。这个哥们也没有在阿里内部去推广这种模式:-(

3. QQ架构的演变

演讲者是即时通信部门总监韦彬，他主要介绍了从千万级别用户量到亿级别用户量时，系统架构所面临的问题：

1）负载问题：在千万量级的时候，QQ的号段与物理部署存在耦合，即一个号段对应一个物理机（假设无副本）。这个方案存在如下问题：a）新号的活跃度高，而新号在号段上的集中度也较高，这就形成了热点；b）号段的部署上未考虑跨机房带宽问题。具体解决思路是比较传统的：首先将号段与物理部署解耦，引入了一个叫bucket的逻辑单元。建立QQ号与bucket的映射逻辑（这个逻辑应该是比较有技巧的，但可以不用太话心思研究。有了bucket这层映射后就比较灵活，后续根据实际执行情况可以case by case的解决就好了）。对于跨机房带宽，则做好局部性。按照演讲者的意图来看，QQ号间的通信应该是在地域局部性上比较明显。所以他们的预算按照区域活跃度来做，将相同区域的号码上下文信息存储在本区域的IDC。这样可以大幅降低跨区域的带宽消耗。（我猜也会遇到个别区域IDC机架位不足的问题，这就要做折中了）

2）单一端登陆到多端登陆的问题：

我认为QQ之所以从单一端到多端存在问题，是由于最初做架构的那帮人采用了“贪心算法”，即在当时看起来既能满足需求又可以低成本实现的方案。显然这样的方案里会做出假设，而该假设在多端登陆时被打破了。（但我不反对这种方式，在互联网行业只要一个方案能支撑2年就是一个好方案）

• 状态系统：在单一登陆端的时候，只需维护PC端状态即可。从节省资源的角度（存储、带宽）可以利用bitmap实现，预先定义好各个状态对应的bit位。显然换成多端后，这个bitmap架构就让人崩溃了。我猜刚开始的时候会预定义几个bit位端，预订好从第几位开始之后是移动端的bitmap。而移动是一个快速发展的领域，如果真用了这方法估计也支撑不了多久，要么就是以资源浪费来换取。解法儿依然是很传统的，为状态存储系统制作一层schema，这样扩展性就非常好了。

• 消息系统：我很诧异的了解到，之前QQ的消息通信居然是采用同步模式，果然是简单粗暴高效。但这种方法在多端时也郁闷了，同步模式的消息通信本身就相当于假设A-B的交互模式很单一。多端时，A的消息可能的sink点存在多个B、C、D。如何在BCD间决策消息的路由？同步模式是很难搞的，显然采用发布-订阅模式的话架构就很灵活，可以方便的做策略。比如，优先发给B，如果B已经阅读则C不再接收之类。

3）从桌面到移动的问题：

• 接入层：
  • 由于移动接入层要面对多种运营商、OS，所以接入层对适配性要求比较高；
  • 域名：传统DNS方式容易被劫持、延迟还大，于是开始自己做域名解析服务；
  • 网关协议：不同运营商对协议内容可能做修改、端口可能做封禁等，要想保障这个过程的稳定非常需要经验，目前是case by case的搞
• 客户端：
  • 移动时代很多需求在迁移到云上实现，这就意味着服务端架构要具有很高的迭代效率，QQ正在推动RPC架构改造。