昨天去车库咖啡听了 InfoQ 办的腾讯云图技术沙龙，今天又听了 CSDN 办的开源技术大会上腾讯云的宣讲(没错，就是那个发明了”内部开源”概念的意思)，总的来说，幸亏去了昨天的！

沙龙包括三个主题：

手机推送服务

手机推送其实是一个很难有亮点的服务，我之前试用过免费的 JPush 极光推送服务，应该说大家都差不多——引用SDK，通过 RESTful 接口或者网页后台发布通知。

从业务上说，腾讯云提出一个精准投放的推送概念。这其实跟后面的多维度数据是联系在一起的，腾讯因为本身(可怕)的数据收集能力，可以很容易的区分几个基础维度——年龄、性别、地域。 (今天午饭跟@刘江总编在一起，他谈到CSDN如何跟技术社区、出版社一起做技术书籍时，提到类似问题，CSDN 上也有千万级的用户，但是怎么高质量的做推荐才不透支信誉或者徒劳无功呢？)

不过在技术周边介绍中，还是聊到了腾讯的 L5 里的技术点，在这记录一下：

起因是说到服务扩容，新服务器上线时会自动根据响应质量动态调整其在集群中的权重。

这里我跟@liu点cy、@守住每一天先后猜测并推论了几种在 Nginx 的 upstream 上的实现方式及相关技术。

不过这几种方案一般常见的用途都是上下线而不是权重调整(另一个需要注意的就是在线修改upstream不会同步到nginx.conf文本文件里)。

那么就涉及到下一步问题：怎么评定响应质量？

Nginx 里是有个 HealthCheck 模块，不过还很基础。于是联想到 LVS 项目中的调度算法，常见的RR、LC、LBLC和LBLCR，少见的还有NQ、SED。这都算是根据 RS 的情况智能调整流量导向。

后来跟讲师交流，稍微了解到了 L5 内部的一点信息。

流量到应用服务之前会经过两层调度(暂称为DNS agent和local agent)；
DNS agent 负责多个 local agent 之间的流量调度；
local agent 只负责本组(原话是本机)的应用服务的流量权重调整；
一个新服务器上线，首先要经过一次镜像流量的试运行，达到5个9后才正式上线；
local agent将收到的每秒10万个请求分配 1% 给新服务器，根据平均响应延时和成功率，判定是否合格，合格就继续加流量；
如果某个服务器被判定不合格了，比如低于5个9了，也并不是直接剔除，而是减流量；除非直接成功率只有85%这样，那就是直接踢。

从流程里”本机”还是”本组”的用词，很容易让我联想到类似 docker 或者说 PAAS 平台的做法。我个人猜测确实有可能就是一组服务器，但是同时也是在一台真实主机上的多个容器。

这种做法应该适合业务运维尝试；CDN 方面，upstream 列表每次变动都会带来巨大的回源压力，反而是越少变动越好

多维度数据分析

前面提到了腾讯数据分析上最常用的几个维度就是年龄、性别和地域。但其实做数据挖掘维度是超级多的，讲师举了不少例子。

从腾讯云的概念上来说，这个数据分析主要是几个层次。

基础的经过整理和运算得到的 TopView。这个应该就是 Hive 里的表，按照讲师所说，TopView 里有 30 个左右的维度。从交流来看，这个 Hive 表内容应该就是以 QQ 号为中心的用户行为数据。每天从原始数据里花点时间更新这个表。
选取需要的维度信息做 RollUp。也就是从 TopView 的30个维度数据中选取几个维度做统计分析。这个就是排列组合问题，挨个硬算了。
合作用户如果有自定义维度，并且勾选这个维度做统计分析，就要先退回到计算 TopView 这步，把自定义维度按照 TopView 的处理方式来做。

因为对 Hadoop 的 Map/Reduce 稍有了解，也用过 Hive，所以这里的东西不算太难理解。其实整个重点是在如何用用户行为日志整理得到 TopView 这块，从讲师透露信息看，全腾讯的日志提前清洗过滤到一天只有几个 TB ，不到一百台的小集群几个小时就可以完成全部分析任务。但是这块属于纯 coding 问题，没什么太多可讲的。

在边听演讲的时候我也边思考了一下如果这个问题用 Elasticsearch 做，会怎么样？

由于ES不需要定义 schema，所以类似 TopView 整理这段应该更轻松一些； RollUp 计算就是写 bool query。这个效率如何我不太了解。

(今天的会场上有介绍腾讯大数据平台的，应该跟这个多维度分析不是一个平台，今天的讲师说到他们的平台除了Hadoop这套还用到了pgsql)

移动动态加速

这一部分是个人比较关心的部分。移动来源占比越来越大，移动网络质量却一如既往的复杂和烂。如何有效提高移动访问质量现在也是大家都关心的问题，本周网宿也刚发布了他们的私有协议加速产品。

腾讯的做法是也提供了 SDK，但本质上没有做完全的私有协议优化而是尽量利用可靠的自建私有网络，软件的部分应该是今天宣布开源了，地址在：https://code.csdn.net/Tencent/mna。

SDK 的主要工作流程如下：

APP 初次运行，正常访问流程的同时，调用 SDK 开始运作；
SDK 内置有 3 个主要运营商一共 9 个默认 ANS(应该是 application name service 的意思吧)的 IP 地址，同时向这 9 个地址发送 HTTP 请求；请求内容包括应用使用的域名、 SDK 获取到的本机 IP 和接入运营商(后二者如果获取不到，其实 ANS 通过 HTTP 本身也没问题)；
ANS 根据请求，返回尽量近的 OC、RS 和 TEST 三个 IP 地址信息；
SDK 根据最快返回的那个 ANS 的响应结果，开始并发测试本机到 OC 和 TEST 地址的链路情况；其中，OC 应该是跟 SDK 地址在同省同运营商，并且是负载最低的；TEST 应该是跟 RS 在同机房，作为 RS 的替身来参加链路测试工作；
如果 TEST 测试结果占优，那 APP 继续直连 RS，走正常访问流程就可以了；如果 OC 测试结果占优，那么 APP 之后的请求，将改为发往 OC 的地址，由 OC 转发给 RS；
在 APP 运行过程中，链路测试是定时每十分钟做一次；当然类似推送这样的长连接服务，不会因为链路测试结果切换而被主动断开。

OC 方面的主要工作包括：

TCP 代理

TCP 代理就是 sock5 代理。不过针对移动环境做了一些优化，去除了sock5里的一些验证算法；
在 TCP 方面，去掉了 nagle 算法，也就是打开了 TCP_NODELAY 参数。 nagle 算法本身是做小包合大包，提高传输效率的；不过在移动环境下，某个包的丢失或者延迟是个很常态的情况，而 nagle 算法中一个包延迟，所有包都要等在后面的情况就会被放大了，所以打开 TCP_NODELAY 应该可以避免这个情况(个人尚未测试验证过，或许可以相信腾讯)。

HTTP 代理

没细说，应该就是 squid 或者 nginx 之类的。

集群层面

每个机房都做了集群，通过 VIP 统一发布。这方面跟@守住每一天浅聊了一下通过 MPLS 协议实现 Anycast 来在多机房间维护统一的 VIP。不过看起来大家系统运维跟精通 BGP 的网络专家联系都比较远，这方面还处于有所耳闻的状态。

最后还有一个小问题，就是上面我们看到过好几处，提到”并发”、”同时”这样的字眼，于是当时产生一个疑问：“三个演讲中，都反复强调为了手机省电我们做了这做了那的，为什么为了优化级别的测试工作，却这么频繁和高密度的做并发请求呢？比如 ANS 请求，我只给本运营商的2个ip发请求也可以接受啊？”

这个问题正好被旁边围观的另一位听众解答了：手机内的 3G 通信模块，一次大批量的数据发送跟几次小批量的数据发送相比其实更省电。

讲师则从实际效果角度证明，目前的频率和策略，从使用上看，确实看不出来对电量的影响。