• Feeds

  • ArchSummit 2015深圳见闻

    这几天参加了ArchSummit深圳全球架构师峰会,AS深圳的地点一直都选在大梅沙,这次大会在海湾大酒店举行。

    两天的ArchSummit大会日程比较紧凑,再加上大多数时候有6个专题在并行,因此每个人能够真正去听的课程不会太多。如果刚好碰到朋友多聊几句,能真正听的场次就更少了。

    第一场是LinkedIn一个技术经理演讲Big Data Story,数据的重要性在各行各业已经体现出来,关键是每个领域需要自己去思考如何更好的挖掘及应用数据。

    下午选了一个在线教育的专场听了几个分享,基本都是围绕线教育领域的大数据应用。由于对在线教育缺少了解,不知是专题选题的缘故还是在线教育的门槛确实提高了,听到的几个案例都是比较偏大数据算法。猿题库研究部总监邓澍军介绍了拍照搜题功能中Deep Learning技术的应用,从介绍的案例来看,识别的门槛还是比较高,不知道与业界其他一大批搜题领域的创业公司技术实力是什么级别的差异。

    第二天主题也比较丰富,印象比较深的是由微信朋友圈负责人陈明的分享。朋友圈后端目前只有3个工程师,讲师以Instagram及whatsapp为例,认为目前小团队存在一定程度的优势。朋友圈的技术特色主要有分布式多机房的设计,以及由多机房架构带来的异地数据一致性问题的产生,微信采用的策略是因果一致性,主要目的是让同一个图片下不同机房回复的用户评论保证因果次序。(可参考分享的ppt进一步了解)

    有不少人参会多的人会觉得参加几次大会后收获越来越小,在某种程度,也可能跟装满水的杯子道理相似,工作多年,形成了自己的解决问题的经验及思维定势,虽然别的方法更好,但从心理的角度,可能总觉得不如自己原先的方法。

    两天的会议开完后,会议在大梅沙海边的游艇会上有一个party,运营ArchSummit(包括InfoQ)的极客邦科技的老板-Kevin Huo同学给大家组织了精彩的活动,也在演讲中讲述了他一向的观点,技术人员在社会上应该得到最好的对待。因此特地选择了在海边的游艇会,看乐队的演出,吃着烧烤,喝着啤酒,聊聊技术与人生。

    PS: ArchSummit所有slides都已经放出,可以在stu.org官网获得。

    黑客马拉松需要什么样的创新项目?

    hackathon go
    一场黑客马拉松项目,大家会首先选择那些业界做得不够完善、或者有较大潜在价值的领域。比如最近举行的Go & Docker Hackathon,参赛人员会首选Docker领域的服务发现、服务调度等领域。

    Docker是一种软件打包及运行的技术,其主要思想是将软件打包成一个image并可以到任意的机器运行,运行时候已经被打包的可执行文件被隔离在一个叫容器的沙箱里运行,并独立于系统其他服务,安全性及资源占用方面都得到了有效控制。Docker软件以及大部分Docker生态圈的软件是由Google的Go语言(也称为为Golang)编写。

    但上面提到这些Docker领域的功能需求和实现都较复杂,完成一项功能费事费力,在短时间尤其是一天的Hackathon期间内,很难较好的完成。反而是找一些技术实现简单的领域,解决一个较小的需求,不但可以快速实现,并可以有机会将体验做得更好。让项目在一个很小但又经常使用的点上打动用户,得到用户的关注及认可。比如这次就有一支队伍完成了一个Dockerfile(生成Docker镜像的配置文件)的编辑器,并且进一步可以将用户在测试环境的的操作录制下来,自动构造Dockerfile。虽然技术实现很简单,但是对很多Docker用户会带来便利。

    很多公司在选择创业项目的时候也会碰到如此的情况,如果选择了一个技术实现复杂的领域,考虑到功能的完整性,早期的开发周期就会变得不可控。创业公司通常希望每个月都有新的产品迭代,但复杂领域的开发,预期1-3个月的项目通常会拖到半年以上,这无疑是增加了公司运营的风险。

    Docker目前在实际环境中主要还是用在管理云平台上的服务,但Docker的这种隔离运行的思想也可以应用在更多领域,比如参赛中应用在硬件控制、可插拔的开放平台等领域的设想。

    黑客精神的一个重要点是程序员通过自己的编程打破已有的软件功能使用方式,给程序员自身及其他使用软件的用户带来自由及便利。参赛作品中比较能触动这一点的是挑战Siri的封闭性的一个项目,他设想通过一个个外接的容器能将智能做得更扩展,延伸到生活各方各面。有点类似微信的连接一切的概念,不过连接之后HUB不是微信,而是一个类似Siri这样的入口。

    从这个角度,大部分我观察到的程序员思想还都比较禁锢,一方面是从小缺少创新(或者改变)的氛围及引导,在被设计的道路上循规蹈矩的长大,学习成绩好就是一个好孩子。工作后比较正常的做法也是每天接受分配的任务,完成得好就是一个靠谱的成员;打破常规的改变的成本过高,也被视为不那么正常的孩子。程序员即使换工作,也经常落在在薪酬、Title等因素的考量上,较少有动力去首先考虑那些通过技术来改变一个领域的事情上去。

    软件的体验障碍与解决之道

    earl grey decaffeinated
    目前好的app会将数据存储在云上,给我们生活带来很多便利,我们可以方便的多屏之间获取到数据,也不用担心app及数据在本地删除后丢失的问题。但很多基于云平台的优秀软件到了国内就会出现一些使用上的问题。

    比如Day One是一款跨平台笔记工具,得过苹果设计奖,也得到不少人推荐,功能确实很简洁实用。白天在路上用Day One写了一些文字,回来后发现uploading一直卡住,不知道是否跟文章中某些词语相关。打开iPhone VPN后,终于上传成功,但在电脑上还是半天下载不回来。忙了一些其他事情之后,发现终于同步完成了。

    Day One底层可以选择用iCloud,Dropbox等云平台存储。这些云服务在国内访问速度及稳定性方面会存在一些问题。Day One可能出于功能简洁的考虑,将同步设计成后台进行。当同步出现问题时,界面上通常看不到相关提示,系统自动在后台重试同步。界面上也找不到任何同步按钮及菜单,也没有状态信息显示何时会进行同步,因此在同步失败时候,用户只能一筹莫展了。

    在国外,由于云平台在基础网络链路及带宽方面都具有优势,因此同步阶段不会出现这么多曲折的情况。上面的问题更多是国内特殊的网络环境造成,软件开发商也无辜的被躺着中枪了,这是app存在的一类问题。

    但并不是说国内的app就可以处身事外了,国内也有自身奇特的网络问题,比如一些厂商的DNS不定期的被劫持指向一些奇怪的IP。但开发商即使了解到这个反馈,未必有有效的手段短时间解决,这也是app存在的一类问题。

    做互联网分布式系统的通常也有这样一种情况,在主从同步等场景下,数据只能保证最终一致性;互联网业务通常不会使用transaction来保证数据提交一致性,因此可能会存在半状态的数据,用户如果碰到这种情况并且会存在困惑,但开发商通常会采用事后修复的办法,从CAP理论的角度不会首先考虑引入事务来彻底解决,这又是一类问题。

    上述问题是否能有效的解决?是否值得花大的精力解决?从“用户第一”的角度,所有用户的问题确实需要第一时间第一优先级解决,特别在影响用户范围足够的情况下。但上述这些问题都是小众群体及场景出现,而且都是在使用标准化方式的情况下出现了异常。

    从架构师的角度,我是极力赞成使用通用化技术而反对自建轮子,比如不赞成用自己维护的UDP代替TCP,不赞成使用非主流或自己开发的数据库、框架、工具包;不赞成通讯上使用自定义的协议来代替XMPP,或者为了防止DNS劫持而去搭建自己的DNS方案。可以预见,这些自建方案的决策在一定程度上打开了一个潘多拉盒子,社区通用技术体系经过5-10年或更长时间的演进,经过较多问题的修改与避免。比如上面的TCP/HTTP RESET/URL关键词错误属于一个问题的话,TCP/HTTP协议已经很好的解决了前100个你看不到的问题。自建的体系从0开始搭建系统,可能需要将大量时间放在重复业界已经完成的功能上。

    从工程师体验来说不太倾向于对各种特殊小众的环境都做一个适配方案。如果有机会能做这样一个比较,在“工程师体验第一(类似facebook的Hacker文化)”与“用户第一”做一个优先选择的话,究竟谁的成效很更好一些?老板们通常会倾向后者,类似有阿里的“客户第一,员工第二”文化;一些声称工程师文化主导的公司可能会声称选择前者,而且某些持这种理念的人也认为工程师主导产品改进的环境会激励工程师的主动参与及改进精神,而导致成效更好。另外一方面文化层面的东西很难直接比较优劣。

    感谢新买到的低因伯爵红茶,让我写完这些文字后接着睡觉不会失眠。

    123...Last