2016北京QCon随感
上周四到周六参加了北京QCon,总体感觉,有1/3是比较实在的干货,相比前几年,一个是分会场多了(9个),另外讲师的水平也有点参差不齐(每个分会场都是出品人自己去想办法找讲师),感觉最近一两年国内技术圈子有点娱乐圈的意思,这个扯远了。主要还是和像七牛许式伟,Oracle范学雷这些讲师做一对一沟通,探讨一些问题,然后了解下行业动态,看看外面的人都在做什么事情,避免闭门造车。
这次比较火的几个议题方向:
- Docker
- 大数据处理
- 音视频处理(点播/直播)
- 移动开发(动态化/热加载)
- 微服务
下面是这几天听下来我觉得比较有意思的几个Topic,分享给大家:
1. Docker 应用:如何设计超大规模容器调度系统
主要讲DaoCloud如何用Swarm做容器编排调度,比较倡导Cloud Native App,为云设计的应用,还有经典的12-factor法则。目前Docker官方给出的编排设施排名是Swarm > k8s > AWS ECS,官方肯定是想推Swarm的,k8s目前Docker版本特性上只支持到了1.8的样子。
然后介绍了一个比较典型的Docker实现微服务架构的例子,用compose up起来的,然后在DaoCloud平台上演示了1000台AWS虚拟机启动10万个容器的演示,比较在意的是从他的例子和讲解中,一台AWS ECS启动只需要不到30秒的时间,这个似乎比阿里云要短一些,不过这种演示属于纯YY了,在1分钟内启动10万个容器,然并卵。
最后开始给他们的DaoCloud Enterprise打广告,不过还是比较简单的一个系统,Agent + Controller + Swarm + etcd,用分布式锁做了管控系统的HA,负载均衡和故障迁移(无状态)做用户系统的HA,这个相比EWS还是弱了好几个级别。
讲师自身在Docker方面积累比较深,有源码级的水平,提问环节时间关系就问了两个问题:
-
有状态如何迁移(不推荐放有状态)
-
Docker是否已经适合跑MySQL这种有状态节点了(官方来不及解决,三方没人解决,不适合)
存储和网络就没再问了,感觉他们目前还是NAT+本地存储的方案。另外一个感觉是,一直在强调高可用,但感觉他们本身在构建大型高可用系统方面的经验比较少,所以很多功能点都不痛不痒的,这可能也是外面创业公司做Docker的一块公共短板。
2. 云直播平台架构与实施
又拍云的场子,主要内容是直播在CDN上新的挑战,因为又拍云自建CDN,所以有这个能力,这个七牛倒是不具备的。
主要从硬件和软件两个维度。
硬件上,主要关注源站的网络质量,即推流服务器的质量,以及他L1/L2/源站之间的网络链路,这块主要也是用BGP和专线来解决。他们的推流服务器现在和阿里云CDN做的直播最大的区别在于,阿里云目前是都往上海ET2机房推,而又拍云是往几个主要城市边缘节点推,相当于直接往L1推,这个方案的问题在于播放回源比较复杂,又拍用Redis来做全局的回源信息的同步。
软件上,了解了下GOP Cache,几场做音视频相关的讲师都提到了,主要是减少回源量,降低卡顿率,这里只Cache 1秒,不需要落盘。
容灾上主要靠客户端SDK做负载均衡解决,由于他们是多Region的方案,一个Region挂了只通过LVS的容灾满足不了需求。
码率、格式的转换在L1边缘节点做,效率最高。
最后拿了一个延迟的例子来结束,同样是北京播放,分别在北京和杭州推流时,同城的延迟在1.1s,跨城就到2.7s了,差别还是挺大的。
3. JDK 9,变化与未来
这场的讲师是Oracle的,主要了解下语言的新特性,以及Oracle对Java未来的路怎么走的一些看法。JDK 9目前的话特性基本冻结了,也就是现在想尝试的可以在本地写写demo玩了。早前Oracle把自家的JDK和OpenJDK路线彻底合并了,所以未来都会基于OpenJDK来做,这块Oracle和社区推进Java发展的方式,在特性上主要靠JEP(Java Enhancement Proposal),JEP可以是Oracle自己实现也可以是外部比较牛逼的人来实现并提交(比如一个Reactive Stream,讲的时候他说是Java界一个很有名的并发专家,但名字想不起来了,我第一反应是Doug Lea,回来查了下就是他)。
新的典型特性包含像版本号区分feature和security(有点像iOS,9.3,9.3.1就是安全更新),便于运维升级;REPL的实现(终于可以像Scala、Python一样不用写main函数做调试了);日志(用户的logging代替JDK自己的logging)、HTTP 2的支持。
Reactive Stream,是Java社区向akka学习,有点类似于在一个JVM里可以比较方便做消息传递了,来提高异步的并发度。
Module System,感觉有点像重新搞的一套OSGi,实际推起来有点复杂,不太看好。不过可以实现JDK瘦身,发布出去的时候只引入需要的Module。
最后讲了下如何参与到JDK的开源社区去,一些流程。总体感觉Oracle在这方面有点迷茫,Java语言本身的历史包袱有点大,外面的一些语法糖又看不上,特性上落后一些新型语言5年左右,他们也很希望外部给他们多提些需求。会后和讲师聊了会儿,感觉人和团队都比较踏实稳重,对需求也比较欢迎,目前JDK开发团队大约在400~500人的规模。
4. OS 造成的长时间非典型 JVM GC 停顿:深度分析和解决
LinkedIn的topic,发现LinkedIn很喜欢分享这些比较实际出现的案例。其实这个TOPIC在阿里应该不算太新颖,因为我们自己团队就遇到过很多次因为JVM之外的原因导致的问题,比如swap。他这里主要也是讲因为OS导致的问题。
这场主要是三个收获,一个是了解一些概念,比如DMS(Direct Memory Scanning),THP(Transparent Huge Pages)。解决问题的方式和我们之前比较类似,像改swappiness这种。还有一些JVM的坑,比如GC日志里面GC的时间其实包含了打GC Log的时间,可能GC并没有那么久,是内存压力比较大的时候OS要尽快回收可用内存来,然后就要flush刷盘,但看起来就是GC时间太长。另外当内存的HugePage被换入换出swap时,会导致严重的性能下降,因为swap只能处理小Page,需要不断做拆分和合并的操作。
第二是排查问题的方式,这块讲师做的比较好的就是能把一些偶发的现象分析大概原因之后,用简单的demo代码复现出来,然后比较针对性解决。通常来说sys time增加而user time增加时都是内存压力导致的。
第三是Java程序员对OS这块的了解确实还不太够,例如mmap在内存紧张时候频繁换入换出的缺点,一些比较新的内存分配策略,最后讲师强调了对multi-layer交互的认知,确实很多疑难杂症,了解计算机分层系统每一层的交互再去一点点trace就比较容易解决了,这个对基础要求也很高。
5. 移动互联网的音视频传输挑战
一个创业公司声网的topic,主要做实时视频和音频通话的,开场思路不错,讲了几个不同的音频场景:微信、YY、创业公司(用他们产品的客户)。黑了一把其它做WebRTC的公司(比如野狗),表示WebRTC只解决了最基本的音视频处理,但是网络等方面没有做优化,像802.11g之前的协议里不支持实时通信。
互联网不是为实时通信设计的,这个讲得比较有道理,公网还是比较注重吞吐量。另外一个比较好的地方是他们的质量评估比较科学,比如看分布不看均值(保障95%以上的用户体验是好的),比如在延迟上排序,横坐标95%的位置对应的纵坐标就是你承诺给客户的最差延迟,如果不能接受,就把这个延迟降下来,如果你在纵坐标上划一根线表示能忍受的最差延迟,那么横坐标就是你能保障的客户百分比。这样讲的时候听众感官上比较直接,比较容易理解。
不过感觉他对网络这块其实不是太懂,问了下如何解决跨国的延迟和丢包,只说了物理链路的延迟只占很小一部分,感觉他们跨大洲的通信效果应该也一般,全球拉专线这个成本不是一般创业公司能承担的。
6. 从 InfluxDB 看时序数据的处理
时序数据库一般强制要求把时间戳作为主键,这样天然有顺序并且能做到顺序写,性能比较好,类似的产品基本都是做了一些内置的函数,用SQL比较方便做一些聚合分析。continuous queries能做一些定时查询并汇聚计算记录的事情,有点类似将每分钟的日志算一个均值、最大值出来展现在监控图上。
还有就是一些坑,比如官方的InfluxDB的Cluster方案,开源了一阵后又闭源了。中间七牛也对比了一些存储引擎,最后选了一个TSM,比较有特点的是它的每个Data File元数据里有个最小时间戳和最大时间戳,查询的时候类似B+ Tree,很高效,但又没那么多随机读写。
我们说到CAP一般说只能选其二,P是必选的,剩下就是你选A还是C。不过其实可以把元数据实现CP做强一致性,数据做AP,这样又有可靠性也有性能。
最后打了下广告,只谈做了啥没有太细节的东西。有人问了下如果自用InfluxDB怎么做集群,目前他们比较推荐用Relay做主备,Cluster还是要自己实现调度器。
7. 谈谈服务治理
许式伟的topic,主要想看看他们做的和阿里做的有什么不同。核心观点是不管做监控还是限流,要把「好」请求和「坏」请求区分开来,这点TAE做的不错,直接能告诉用户你的URL里有多少200,多少4xx,多少5xx,还能逆向倒排反查原始日志。他认为好请求和坏请求的增量反应了你的系统到底是因为业务增长还是异常的,只有好请求增加才需要扩容,坏请求增加时,根本上需要排查故障了。
会后交流了下,主要是如何培养新人在写代码的时候有稳定性的意识,以及问题排查时的效率。这块七牛有点像每年双十一的稳定性保障小组,或者说更像Google的SRE,专门有个团队保障稳定性,然后业务的人也要配合他们做改造,新人培养上他也没有太好的办法。不过这倒让我想到,是否可以模拟一个故障演练场景(有别于真实的演练),像培养飞行员一样,在一定程度上也能提升这方面能力。
8. 移动端音视频应用优化之道
网易的人讲的,场景主要也是点播+直播,主要了解一些音视频转码相关的东西,H.264和HEVC/H.265、VP8/9,目前全平台兼容性最好的还是H.264 + AAC + MP4的封包,H.264推荐的编解码器还是x264,H.265只在高清(2K以上)的场景下比较有优势。也提到了GOP的配置,减少网络抖动的时候的尖峰,另外他们对于跳帧是比较激进的,不行就把I帧以外的按一定顺序都丢了。
监控上做的还不错,码率、帧率、带宽、延迟相关都有比较全面的监控,来指导不断优化迭代。
iOS的图像内存拷贝做得比Android好很多,所以大部分视频和图像处理软件在iOS都要比Android流畅很多。
9. Apache Eagle: eBay构建开源分布式实时预警引擎实践
Apache Eagle的创始人的topic,听下来感觉和AliAPM的分析架构很类似,也是基于Storm和Kafka,存储用HBase(也支持像OpenTSDB这些时序DB),我们用的是JStorm和ONS,存OTS。
他们支持SQL直接扔进去做查询,这个动态性相比Storm要写Topology再发布要好一些。
目前这套框架在eBay每天处理200PB+/Day的数据,使用了8台物理机的资源。
最后讲了一些Apache开源如何孵化的东西,类似JDK那场,讲的是开源社区的玩法。
10. 老树新花——Lua 在聚划算 App 动态化中的应用
了解下无线动态化开发的东西,相比南天那场可能细节更多一些。主要构建了一层Lua虚拟机扩展层,来做lua和Native交互,所有的LuaView可以直接创建Native的组件设置交互,中间会经过一层虚拟机的翻译,不过性能还是不错的,第一次加载会多个200ms左右,但获得的是和Native完全一样的体验,因为加载的组件其实都是Nativede。
和WeeX有点类似,都能在不发版的情况下直接更新客户端的展示。目前也开源了,缺点主要在调试工具和开发环境上,工具链有待完善。
11. 点线面,一个安全人员的漏洞世界
第三天听了几个安全相关的topic,了解到一些安全工程师看问题的视角,比如看到输入框就要XSS一下试试,看到跳转URL就要看看有没有校验可信域名否则可以被利用(这个想到tbpass好多年前就做了跳转域名的校验)。
提醒了我们作为后端开发除了对比较熟悉的XSS/CSRF防范外,针对需要验证的场景,还要考虑诸如同一个来源的频率限制(否则存在被暴力破解的可能性)。有一个比较有意思的case是把手机用USB插电脑上充电,其实这个手机OS把自己模拟成外接键盘,就可以在这台电脑上做输入了。
对于你认为可信的来源,也必须做校验,否则他有漏洞就可能导致你也被bypass过去了。
谈到了关于漏洞修复时间的黄金窗口,1小时,最长不能超过1天,这个和我们故障处理时间是类似的。
另外像ElasticSearch, MongoDB, Redis这些,其实都有可能因为漏洞直接被提权了,放公网上还是挺危险的。