《ArchSummit深圳2014大会》所见所闻小结

参加了2天的AS2014，回来累得像猪一样，晚上9点多倒头就睡了！

既然去了，好歹总要有一点收获吧，这不，现在就在造总结了，趁现在头脑还清醒，多少还有些记忆，赶紧记录下来！

（1）18号上午

1、18号上午，第一个是章文嵩博士的《 构建大型云计算平台分布式技术的实践》，这个太高大上了，与我的领域有距离，不过，最前沿的东西还是能提供指导意义的。他主要讲述了，在各种存储环境下，调优IO的策略与性能比对数据，总之就是利用好缓存来提高应用的IOPS了。CPU有缓存、磁盘有缓存、单节点有缓存、分布式文件系统也有缓存，都是把缓存利用到极致。

2、18号上午，第二场是AWS的一个布道师将的，是个老外，貌似还是市场方向，分享的题目《 使用亚马逊Web服务(AWS)构建高可用架构》，听是没听懂多少，但是PPT还是能看懂的，多半是大家都知道的东西，水分有点多，说不定AWS给@infoq捐款了，否则哪能这样来浪费近1000人的时间。

3、18号上午，最后一场，是来自携程的叶亚明分享《 六种有效的开发模型》，他把软件的架构提炼为6种模型，说的有点道理，是那么回事，但是我不知道会场那么多人，有谁是为听这个而来的，连这些都不懂的人来参加会议也太奢侈了，有点浪费钱。不过，话说回来，初学者还是有些帮助的，我可以考虑用他的PPT给大家分享下，给他推广推广。

上午总体看，水分有点多，帮助不大。

（2）18号下午

18号下午，我参加了《 随机应变的SNS》这个分会场的分享，期间还顺带去听了一会《 唯品会技术架构面临的挑战和应对策略》。

1、下午的第一场，《 高可用即时通讯架构》，来自陌陌的CTO分享，主要讲的是实时通讯的协议，有点犹抱琵琶半遮面的姿态，本是要讲讲陌陌的即时通讯框架和协议的，结果讲了一堆Redis的协议，美其名曰是差不多，意思意思，说白了就是采用长连接，但是协议是类似Redis的自有协议，推送内容精简，能只推ID最好，具体内容还是由APP来主动拉取。这东东，人家企鹅早在2年前就分享过了，思路应该是公开的，只是又为这种方案添加了一个具体的案例而已。

2、下午的第二场，《 Qzone在移动网络所面临的挑战与解决方案》，来自QQ空间的前端和后端同学的2人讲师分享的，最开始是纯APP开发的东西，听不太明白，我溜出去听了下《 唯品会技术架构面临的挑战和应对策略》。唯品会的技术层次还是道行尚浅，6年前阿里做的事情，它现在开始搞，不过站在前人的肩膀上，他们进展还算说的过去，干起来也放心多了。总结起来，就是SOA化，自检类似Dubbo的框架，协议采用的是Thrift，支持多语言。唯品会的分享虽说技术指导意义比较弱，但是也让我们看到也就之前的那么个烂烂的架构，人家也支持了几十亿的年度销售额，技术架构不在好与坏，够用就行，能满足业务需求就是王道。唯品会的分享很快结束了，我又回来听《 Qzone在移动网络所面临的挑战与解决方案》，刚好是APP同学讲完，后端同学上场，来得正是时候。

---夜深了，明晚再继续---

放下了就很难开始了，不过我的总结得从流水帐的模式换成读后感了！

参加《ArchSummit深圳2014大会》期间听到一些业内公司的技术分享，业界也碰到过很多与我们同样的问题，甚至部分问题的解决办法也与我们曾经想过的一些办法类似，只是他们早已经落地并且做到极致了。 有很多东西对我们有参考意义， 可以说从产品和技术形态上很多公司远远走在我们的前面了。

       现在把我觉得可以借鉴的地方列举出来：

       1、APP与服务器的交换数据采用User级别的加密Key。

       QQ空间的做法是，APP与服务器端第一次通讯采用对称加密，服务端为用户生成一个用户唯一的密钥，后续客户端与服务端的任何通讯都采用非对称加密算法来加解密，保证请求和响应数据的正确性和可靠性。这一点，目前来看，我们的需求不强烈，但是如果后续充值相关业务做的比较重一些的话，可以考虑借鉴。

       2、APP与服务器的交互，采用长连接的方式。

       APP与服务端交互，常规的是采用HTTP+JSON的方式，APP与服务端的一次交互，涉及域名解析、建立连接、交换数据、关闭连接等过程，在弱网络的场景下消耗比较大，通常在1-5s的范围内，并且建立短连接非常耗电。包括QQ空间、微信、陌陌、淘宝手机客户端在内的一些APP都已经普遍使用长连接来减小手机的电量消耗，也改善用户在弱网络环境下与服务器交互数据的体验。这个确实能增强用户体验，但是对后端的开发有更高要求，后续我们可以考虑借鉴。

        3、将用户与APP的交互以及对APP与服务端的交互，记录完整日志，并且将用户行为按不同策略上传到服务端。

       就这一点分别与 QQ空间、微信、携程的同学沟通过，他们都已经做了，好处是能快速定位APP与服务端交互的故障。其中，携程网的案例非常好，他们不光在APP上有上述行为日志与交互日志，还做了一个强大的后台，可以在延迟分钟级别范围内看到一个近实时的用户正是的访问性能数据，有问题即时暴露出来。长久以来，我们后端服务器上，每天都有30万次左右的请求会失败（nginx的499错误），服务端看到的现象是客户端关闭了网络连接，但是无法确定具体是APP端真的关闭了，抑或超时了，再或者是被网络服务商关闭连接了中的哪一种错误，如果我们建立这个体系的话，不光是可以定位类似上述的前后端错误，还可以根据用户在我们APP上的访问路径来优化客户端的用户体验，也可以更加精准的对用户画像，为后面的广告系统提供数据准备。这个点上我们大有可为，需要早做准备。

        4、应用与数据都采用多IDC方式，写主、读备，提升用户体验。

        QQ空间的应用分布在深圳、上海、天津的三个IDC中，用户就近访问最近的IDC，IDC之间采用专线连接，数据写入统一为Master，但是读数据可以读各自IDC的数据，延迟控制在200ms左右。腾讯采用这种方式大大超出我的意料了，本以为是要采用其它的高大上方案的，但是这个方案确实简单高效，配以他们独有的IDC专线，确实能解决问题。其实最近几个月，我也一直在考虑这个问题，甚至在应用级别都做了一些准备工作，想根据后续网络测试性能数据来判定这个的必要性。我们的应用也可以考虑采用类似方案，在北京、上海布一组应用服务器，让用户访问就近的应用服务器，来提高用户的读取数据体验。

        5、APP预埋应用IP，直接使用IP来访问后端应用服务器，避开域名解析。

        新疆用户不能访问我们应用服务器的时候，我就提出过这个方案，但是没有最后执行下去。QQ空间、淘宝手机客户端都使用了这种方案，APP预埋应用服务器的种子机器IP，在域名不能访问的时候，直接使用预埋的应用IP来访问，并且APP会自动记录上次访问的应用服务器的IP地址，下次接着用，IP如果不能访问才去使用域名来访问后端应用服务器。记得前春节前全国范围的DNS解析失败的时候，淘宝还是可以正常访问的，就有这个原因。我建议尽快采用该方案，可以避免新疆用户不能访问后端的应用服务的故障再次发生。

        6、进行用户生命周期分析、用户画像来挖据数据的价值。

        收集尽可能详尽 的 用户行为数据，对用户使用我们的应用后的行为进行分析，给用户进行画像，将用户群体用不同属性、标签来归类，找出共性与差异性，有准对性的提升用户的体验。来自珍爱网的同学的对婚恋推荐的分享，以及豌豆荚同学建立知识库的分享，对我们也很有参考意义，毕竟我们后面要做广告平台，有些东西可以提前进入日常安排了。我这里已经把春节后，所有的用户访问日志都使用Hadoop保留下来了，可以利用Hive来进行常规的分析，但是这些还远远不够，由于有太多东西是APP缓存处理了，所以用户行为数据不完整，对广告系统来实现精准推荐有较大影响，这个痛点需要我们从产品和技术角度来先行解决掉。

         7、运维自动化。

         运维自动化是目前各大公司的核心竞争力了，私有云和公有云无一不是奔着这个点走的，腾讯游戏、百度贴吧等都有分享他们的运维演变的过程，大家都经历了脚本化-》配置化》作业话》故障处理自动化，类似的历程。我们目前是停留在脚本化的入门阶段，大部分是还是人工处理，随着我们业务的发展和机器的增多（目前已经有40台左右服务器），也需要制定一个我们自己的运维规范出来。这个任重道远，不过确定现在可以开始了。

       

         还有很多其它的点，比如后台架构和客户端架构，我这里就不一一列举了。总之，参加了2天的会议， 我感受最深的就是，很多想法我们也有，甚至很类似，但是没有落地，而业界同行们已经把它实现了，并且做到极致了。这样一来也好，现在我们也可以放手去把一些想法变成现实，因为我们的方向是对的，前面的榜样很多、很多。