2013 ADC阿里技术嘉年华所见所思

回来时候，发现会场听讲的会议记录的笔记本丢了，写了满满一本。就凭记忆写一些东西吧。

 

1.android插件化

 

插件化框架组开发定制了自己的dexloader，resource loader,如果发现插件或者资源有更改，就自动更新。有校验机制，母包会对子包记性校验，大概是母包对子包进行签名，接着dexloader加载时用母包的公钥解密，得到插件指纹，对插件指纹进行校验，如果插件有任何内容修改，就生成不了一致的插件指纹。校验的算法都是用C直接写的。反编译可能就不起作用了。另外子包也会对母包进行校验。

 

插件开发组 开发的包 就跟普通的apk一样，可打包到app market发布，也会作为插件发布，对于插件或者app开发组就跟平时开发apk一样，应该有用一些反射，或者其他的逻辑修改了代码逻辑。作为插件发布时，要打开插件模式，通过配置，进行测试，

 

插件发布后，打开应用时，应用会检查相关的插件是否需要升级，如果有需要升级，就可以自动download下来并加载，如果升级失败，也可以之前的状态继续运行。

 

启示：当我们作为平台，当有很多第三方为我们开发东西的时候，就需要了。一般的布局变换或者图片资源变换，要不了这么复杂的

 

2.android安全

 

activity 劫持，广播劫持，intent劫持等。

二次打包，无法解决,微信等都存在问题

进程hook等比较高级

 

 

启示：建立安全代码规范

          部分数据的通信加密 校验，播放，下载地址

 

3.百度云推送

 

猜测是启动service，运行在后台模式，通过AIDL对外提供服务，只要有应用启动了，就不重复启动了。多个应用可共享一个连接。

 

连接会有心跳机制，做连接保持，防止连接断掉。只要用户开着机，连接基本会保持着，因为一旦连接断掉后，就有重建的开销。

 

百度云推送说100w要7秒，单机可以支持到300w个连接。

 

基于LBS的推送，收集用户的地理位置信息，每隔半个小时汇报一次地理位置。地理位置用mongodb存储。

 

启示：采用百度云推送，解决我们推送扩展的问题

          以后可尝试用mongodb存储地理位置信息

 

4.去哪儿酒店搜索架构

 

模块划分：render，search，index，rank，real time rank，crawl

 

实时rank，任务拆分排序，再合并。

crawl：触发条件，memcached expire，人工，实时。线程池隔离，每个步骤（业务逻辑）用独立的线程池，线程池没有队列，启动更多的线程，直到max pool size

通信框架：douboo， kyro 序列化反序列化

多级缓存: local cache，进程缓存，客户端按照cookies来做负载均衡，散列到某台服务器，所以改用户会在一段时间内，都被访问到某台服务器，这时进程按照LRU淘汰L1缓存，就会有效果，对global cache压力比较小。

 

启示：pns服务的线程池隔离

          声音，专辑缓存不能用什么ruby独特的序列化格式

          我们爬虫的一些策略性优化

 

5.阿里巴巴分布式架构

dal层合适的时候引入呗，dal层的co processor，join等，半事务（最终一致性），事务的拆分，对查询请求的parse，如果路由到各个数据库节点。尽量还是发生在同一台服务器，避免额外的开销。

 

auto shard，自动迁移，全量到某个时间戳，停止写入，增量，完全一致，打开同步

 

启示：对我们的分类拆分有提示

          做读写分离，mysql proxy？

 

6.百度媒体云

 

各种高级算法，深奥加牛逼，我太屌丝。有个性能好的jpeg转码库。

 

实时分片转码，合并，分布式分段转码，合并

 

启示：音频的转码如何切分，降低用户的响应时间

 

 

7.淘宝彩票

 

分库分表，典型的业务场景，业务单一的好处。按照彩票的种类，期拆，无彩票开奖期的按照时间拆分。

索引表，单条数据量很小，保证单表可以条数很多（无需拆）。索引表查到对应id，再根据id到多个表中查询，不需要缓存，根据id查询足够快。

读写分离：采用注解方式，完全依赖于开发人员

 

启示：读写分离，从库要买台好的机器，跟上主库

 

8.架构漫谈

 

scale up 到 scale out，架构变迁中，各种架构模式的漫谈，一些设计中需要注意的原则。比如要注意隔离，宁愿降级使用，也不能不可用。

我想就是要问自己：当前的问题是什么，你的架构能解决当前问题吗，未来问题是什么，你的架构能应付么，或者方便扩展么，至少要保留缓存时间。

 

启示：让工程师多座设计，增强解决问题的能力

          scala不错，该在java工程师中间推广一下

 

 

9.天猫推荐

用户对item的打分

item之间的相似度计算，比如对热门声音降噪等，尽量推长尾

多维度，归到一个平面计算

决策树，实时推荐。实时收集用户的点击行为，进行决策分析。用户意图模型。

在线，离线评价：离线预测，根据历史数据校验。在线，助于导流量。AB test。

哪些页面需要做推荐，推荐什么

用户建模：用户短期，用户长期。比如用户点击以及当前意图是实时的，用户的行为数据每天算一次，用户的特征属性等一周一次

商品会有标签，根据商品的关键词提取，用户的标签来源于商品的标签。用户和商品都没做聚类算法，聚类算法算出的集合比较大，不好推荐，标签也没进行相似度计算，分词，语义应该会有。

 

启示：我们在做推荐系统的时候，先考虑业务，比如说什么页面要推荐什么。接着考虑部分架构的问题，比如推荐系统涵盖哪几个部分，被比较大层面的。接着对声音，用户建模，再补充架构中缺失的部分，最后考虑算法。

          

          我们声音的推荐算法使用item based算法，基于标签，也先不用聚类分类

 

          我们还有用户推荐，是否需要用user based，还是用用户的兴趣标签，由声音产生。

 

10. 二楼workshop酱油中

 

AB Test 灰度发布

 

 

11 360 Mysql

自动创建mysql instance，并完成数据的同步。我接着睡着了。

 

12.MetaQ

commit log的设计方法，分区，索引，hash快速定位，读取，增加吞吐量

不保证声音不被重发，收任务的业务要做到幂等，可重复处理，这样消息不会丢，会重复处理

推拉结合的方式，推的方式处理起来比较简单，拉的方式，凭能力获取，多做多得。我们现在大多采用拉的方式

Zero（direct）copy，MMap，老生长谈，刚写入的时候是在内存中，时间长了，被切换到磁盘中，接收者从磁盘获取，吞吐量大大降低，队列可能积累

有定时执行的topic，应该是该topic中的所有消息都是固定延时多少处理

 

启示：不太适合我们的业务场景，我们需要非常高的吞吐率，容许丢失，kafka

 

13.下楼讨论，玩了半个左右的乒乓，羽毛球

 

这次ADC体验不错，就是有点累。