业务推动技术的进步(转)

 赵海平,2007 年加入只有不到 50 个软件工程师的 Facebook,致力于软件性能和架构分析,在此期间创建了 HipHop 项目,重新编写和实现 PHP 语言,使其速度提高 5 到 6 倍,为公司节约数十亿美元。HipHop 项目之后,致力于“用异步处理来优化分布式系统”的设计理念中,并为此做了多项分布式数据库的优化研究,在 PHP 语言中加入了 yield 和 generator 的新功能,来帮助日趋复杂的 Facebook 网页设计。

  2015 年 3 月,他回到中国,加入阿里巴巴技术保障部,任职研究员,将重点攻克阿里巴巴在软件性能以及 Java 使用过程中遇到的技术问题。

  InfoQ:首先欢迎您回到中国。可以介绍一下您加入阿里巴巴的初衷吗,阿里巴巴最吸引您的地方在哪里?

  赵海平:去年机缘巧合,我和阿里巴巴的同事有了交流的机会。当时我们聊了很多技术细节,发现阿里巴巴的规模非常之大,很多技术上的难题是美国公司都没有的。比如说双十一这个问题,没有哪家美国公司单天有这么大的交易量,这是很特殊的一个问题。这个技术问题对我特别有吸引力。

  当规模大到一定程度,简单的问题也会变得复杂。有的时候软件就是这个样子,在一台或者几台机器上执行是一个情况,当机器多到一定程度时,对软件的要求就特别高了。在多台机器上,怎么才能保持很快的速度,并且节省机器,又不出问题,这是一个很难的技术问题。

  单天的资源需求是平时的好多倍,怎么计划机器,让峰值最高的那天不出现问题,平时又要做到很好的利用,这是很不容易的。我特别希望自己能够有这么一个经历,去阿里巴巴解决这个问题,这是在其他公司找不到的技术问题,而且跟我很对口,我一直在做的都是怎么提高大规模系统的性能、稳定性,所以这正是我的兴趣所在。

  InfoQ:您在阿里巴巴的新角色就是解决这些基础设施的性能问题?

  赵海平:基本上是几个方面,性能、稳定性、容量、架构,还有运维,恰恰就是我现在这个团队——技术保障部——的工作。性能提升上去,容量就增加了,随着我们监控系统的改进,系统的稳定性也会提高,运维也会更方便。如果发现架构上的问题,我们也会做些调整。

  InfoQ:谈到性能问题,定位是很关键的一点。像这种规模的分布式系统,如何实现全系统的监控,准确定位问题就非常重要,您会在这方面发力吗?

  赵海平:Profiling 特别重要。如果能有一个特别强大的 Profiling 系统,就知道整个系统在哪个地方,哪台机器上,花了多少 CPU、内存、磁盘 IO 或者网络带宽等资源,才能知道优化什么地方效益最大。

  所以我的第一步工作就是帮助完善阿里巴巴的监控和 Profiling 系统,希望能够很清楚地把软件的整个性能展现给大家,做到实时监控,同时让研发人员看到自己的代码在线上的运行情况,了解这些代码花掉了多少资源,这样有问题的话他们可以自己解决。

  InfoQ:大家对您的最初印象多是来自 HipHop for PHP 这个项目。像淘宝之前就从 PHP 切换到了 Java,而 Facebook 选择了自己改进 PHP。可以谈一下这个项目吗,当时的出发点是什么样的?

  赵海平:HipHop 也是一步步慢慢建立起来的。最初是我遇到了一个 PHP 的函数,在 C++ 里也想用。当时想,重写一下就可以。不过那个 PHP 函数不断在变,我就想写一个简单的工具,把这个函数转换成C++,这样就可以跟上 PHP 代码的变化。那时正好机器开始吃紧,大家意识到 PHP 的速度问题,CPU 消耗很大。大家就开始讨论如何提高 PHP 的性能。当时想法很多,有人想改变 PHP 本身,有人想干脆用 Python 或 Java 重写网站。

  当时也重写过,有三四个人在做这件事情,但这些人改的速度远远赶不上另外二三十人写新 PHP 业务代码的速度。所以我们就想到写一个工具,来转换这些新写的代码,既不干扰既有的开发节奏,又能大幅优化性能,跟上变化。

  当时我也读了下 Zend Engine 的代码,研究 PHP 为什么会慢。发现 PHP 速度之所以慢,是因为有很多的函数调用是动态的,而像C和 C++ 里,很多函数是静态调用,不需要在执行的过程中去查询函数指针在什么地方,所以速度才快。

  所以我们做了很大的调整,一定要改变这种方式,争取让所有的函数调用都能尽快实现,在编译的时候静态处理,执行的过程中就不需要再查询,指针已经在那儿了,这是最主要的加速思路。

  那时候就萌芽了一个想法,如果能够把 PHP 直接转换成C++,也许这个性能问题就解决了。然后就花了很多时间去做原型。我们做了很多工作,把底层的 PHP 实现都改变了,有一个自己的 Runtime Library,再就是一个 PHP 的扩展库,这个实际上是很大的一块代码。在这个上面,我们又写了一个把 PHP 转换成 C++ 的一个编译器。先将 PHP 编译成C++,然后靠底下的这个库实现功能。这是最早期的工作。

  不过这在当时只是一个副业,因为不知道这个东西到底有没有意义,是不是能提高性能。大概能拿出 30%~40% 的时间做这个。做完之后发现效果很好,就加入了其他同事一起做。后来速度不断提高,第一年提高了 2 倍,第二年又提高了 2 倍,后来提高到5~6 倍的样子。

  现在回头看,如果当时雇很多人把网站改成 Java 的,也是可以做到的,但 Facebook 的发展可能要停半年到一年时间,甚至更久,就有可能对 Facebook 的发展带来不可预期的影响。这件事情主要还是业务推动的。

  InfoQ:后来 HipHop 发展成 HHVM,从原来的静态编译变成了动态的 JIT 机制,您也参与了这方面的工作吗?

  赵海平:引入 HipHop 之后,我们也有自己本身的一些问题,比如产品环境和开发环境就是不一样的,这样多多少少会存在一些问题,也就容易出现 bug。再就是 Facebook 的代码量非常庞大,编译时间非常长,另外生成的二进制文件也非常大(超过 1G),发布也很困难。

  这时就出现了 HHVM。HHVM 不再是把 PHP 转换成C++,而是采用了一种新方法,把 PHP 转换成一个中间码,这个中间码在执行过程中再转换成机器码,不过调用的还是我们原来为 HipHop 写的底层库,它取代的主要是把 PHP 编译为 C++ 的过程。

  我并没有参与 HHVM 的编写,当时我已经离开这个小组了,另外一件事情吸引了我,这就是异步处理在分布式系统中的优化作用。

  之所以离开这个小组,原因大概有几个方面:一个是,个人认为 HHVM 不再能把性能提高更多了,后来也确实如此,两三年之后 HHVM 出来,速度并没有更大的提高,最高只比原来静态编译机制快 10%~15%,而且是因为静态编译这一块不再开发了。再就是新的课题特别有意思,具体我会在 QCon 北京上分享。

  这就是为什么去 GitHub 上看,HHVM 里面会有我的代码,主要是底层的代码还是基于 HipHop 的。HHVM 的头两个字母就是来自 HipHop,引擎还是原来的,不过上面做了很多工作,把 PHP 转换成中间代码,这个有点像 Java 的 JVM。这样的好处就是研发过程和产品过程其实是一样的,而且不会有原来说的那种超大二进制文件的问题。中间代码很小,PHP 可以直接发布到线上系统上。

  InfoQ:国外一些著名的互联网公司,在性能调整和优化的过程中,慢慢都发展出了自己的编程语言,像 Facebook 设计了 Hack 语言,Google 有 Go 和 Dart 等语言,Apple 有 Swift 等。这方面您有什么感想吗,Facebook 的 Hack 语言您是不是参与设计了?

  赵海平:Google 的 Go 语言挺有意思的,写得非常好。Hack 语言我没有太多的参与。

  PHP 是弱类型的,这是性能提高的一个瓶颈,而强类型的话就可以做很多优化。最初我们是想增强 PHP 的类型系统。强化数据类型,这是引入 Hack 的一个主要因素。

  InfoQ:PHP7 最近也有很多改变,性能提高也比较大。

  赵海平:这也是我临来之前刚刚听到的。PHP 核心开发组的力量是很强的。我也跟他们的人员交流过,他们对整个 PHP 的优化有自己的思路和想法,也做了很多工作。这是件好事。其实重要的并不是说哪个团队或小组把 PHP 优化到什么样的地步,有几个小组都在做这个事情,彼此竞争,会促进整个 PHP 生态系统的发展。这种竞争也恰恰说明了 PHP 的重要,所以会有很多人关注它的性能优化。

  InfoQ:您对公司发明创造自己的编程语言怎么看?

  赵海平:编程语言这个问题,我说两点。第一,不能把语言当成一个特别神圣、至高无上的东西。语言也是整个软件系统的一部分,只是它分割的很好,独立出来了,可以执行更多的功能,我们可以用它实现我们的功能,可是在整体架构上看,语言也只不过是软件系统的一部分,而这一部分我们完全可以做一些调整,使其更适合我们的系统。而设计语言时一般考虑的是比较通用的目标,我们拿来用,只是因为它的绝大部分特性都是我们想用的。比如我们用C和 C++ 写程序的时候,每次都要思考内存的模式是什么,是不是用 share pointer,是不是用自己写的 Object,内存的 allocation/deallocation 怎么做,一个语言帮我们把这些事情都做好了,这就是它的好处。它提供了一个很大的库,提供了一个软件执行的环境和范围,而这正是我们选择语言的初衷。

  第二,作为一个公司来讲,不能说为了研发一个语言而去研发一个语言。这是没有意义的。一定要根据自己想要做的事情,在现有的软件架构当中,我们发现当前所用的语言提供的环境和范围不太适合,或者说这个语言的很多假设和假想,和我们所期待的东西并不一样,只有在这个时候,我们怎么也找不到一个合适语言的时候,我们才会创造一个新的语言,让这个语言更适合公司的事情。如果可以通用化,提炼出来,那就是语言,否则设计成软件库就可以了。

  这是水到渠成的,不要强求。像 Google 开发 Go 语言,我认为它有自己的考量,可能在开发很多分布式系统的时候,现在的语言写法上不太直观,或者速度不够快,所以才创造了这么一个东西。Go 应该能解决公司内部的很多问题,否则是很难存活的。

  InfoQ:您可以结合自己这些年的经验,给中国开发者的成长一些建议吗?

  赵海平:在美国的时候,我跟 Facebook 的中国员工聊的很多。我给他们最多的建议就几条。

  第一,一定要提高交流能力。咱们中国人,尤其是中国搞计算机的人,很多人有个不该有的特点,就是喜欢把自己锁在黑屋子里埋头干活,跟机器交流特别擅长,跟人的交流一窍不通。这样不行,我相信在中国也是这样的,你不但要把自己的工作,技术活要做得特别好,而且要擅长表达自己的想法,擅长在工作当中讲述做的是什么,怎么样能够说服别人,怎么样能够跟别人在不伤和气的情况下,把问题解决好,这是很强的一个能力,而这个能力不是在学校里能学会的,是我们走向社会之后慢慢学到的东西,这个我恰恰认为中国的员工,尤其是在美国那样的环境,因为不是母语,可能处理得就不是特别好,有时说出来的话比较生硬,给对方的感觉不是特别好。

  第二,中国人比较谦虚、内敛,讲究内涵,自己心里有的东西不表达出来。但是在工作中,可以适度强势一点,勇敢表达自己的想法。当然这个建议是基于美国多元文化的背景,在国内大家的文化背景一致,也许可以探讨最合适的沟通方式。

  第三,掌握好英语,开拓眼界。我觉得在计算机这个技术里边能够非常了解英语,把英语的这个隔阂给去掉还是非常重要的。

  我回来的时间还不长,等和大家接触多了,可能会有新的想法,目前就这几点吧。

http://news.cnblogs.com/n/518111/

时间: 2024-10-22 04:39:47

业务推动技术的进步(转)的相关文章

如果你将业务与技术能进行非常好的结合,那么你就是专家了(转)

声明 首先声明,这篇文章不是什么心灵鸡汤,也没有满满的正能量,可能还捎带点负能量.就是因为各种媒体传播的正能量太多,把大家搞的不知所以然,飘飘乎,都觉的自己很牛逼. 如果你觉的我说的不对,不喜勿喷,但是可以交换看法,禁止一切人生攻击.下面就开始一篇接地气,正常的,没有弘扬任何社会主义价值观的文章.我也希望你能带着想法,带着思考来把这篇文章好好的看完. 我的经历 个人履历稍欠,并没有多少可以多说的,这里把我的工作经历,职场生活总结一下,也是为大家做一个参考,提供一个比对的平台. 2012年7月,本

由三张图说业务、技术和实施的差别

前几天突然紧急要写个方案,要求也比较明确,写出应用服务模式,数据资源组织,以及系统功能组成和部署配置方案,10来页就行.手上也有些现成的材料,后面几点也很熟悉,10页自然不在话下,晚上花1,2个小时也就整出来了,唯独第一点应用服务模式,晚上写得时候就有点纠结,果然第二天被要求重写,重画一张图还是说太技术,又在公司总工的细细指导下,画了第三张图,才勉强通过.经过这么三个回合,自己仔细一思量,发现从业务和技术的角度去描述同一件事,描述的重点和方式确实是有区别的,在这里写下我的感受,希望对像我一样从技

尘归尘,土归土——业务归业务,技术归技术。

随着分布式.微服务的火爆,跨系统的服务调用也变得常见起来.这使得我们在线上追查问题的时候,常常要查阅多个系统的日志.    这时候,问题就出现了.如何确定服务A中的某条日志,对应的是服务B中的一个操作呢?    我们的开发人员提出了一个简单的方案:每次服务调用时,调用方都将一些技术性的数据封装在header中:服务方从header中获取到数据后,记录到日志中(或者做其它必要的操作). 初版 这个方案的思路无疑是正确的.不过其最初的实现方式么,我实在不敢苟同.因为它要求每次调用服务,都按这个格式来

架构师之路--搜索业务和技术介绍及容错机制

今天和搜索部门一起做了一下MQ的迁移,顺便交流一下业务和技术.发现现在90后小伙都挺不错.我是指能力和探究心.我家男孩,不招女婿. 在前面的文章中也提到,我们有媒资库(乐视视频音频本身内容)和全网作品库(外部视频音频内容),数据量级都在千万级.我们UV,PV,CV,VV都是保密的.所以作为一个合格的员工来说………………数值我也不知道.总之,这些数据作为最终数据源,要走一个跨多个部门的工作流才最终出现在用户点击搜索按钮出现的搜索框里.大体流程图如下: 这个流程图之所以没像以往一样手绘,嗯,那是因为

业务驱动技术

当一名程序员技术达到一定水平后,这时限制他成长的,往往已经不再是技术了,而是业务思想! 在当今这个网络发达的时代,网上的技术资源可以说是取之不尽用之不竭,应有尽有,现在的框架封装的也是越来越彻底.越来越全面.也越来越傻瓜,程序员的门槛也因此越来越低.随着IT的发展,渐渐的考查一名程序员水平的标准便不再是技术,而是业务. 十几年前,软件开发还处于萌芽期,谁能及时推广自己的产品占领市场,谁就是赢家,就跟抢“地”似的,谁抢到算谁的,腾讯.金山等就是最为明显的例子,到如今,软件涉及的范围已经很广泛,“地

BAT解密:互联网技术发展之路(9)- 业务层技术剖析

互联网的业务千差万别,不同的业务分解下来有不同的系统,所以业务层没有办法提炼一些公共的系统或者组件,但抛开业务的差异,各个互联网业务发展最终面临的问题都是类似的:就是复杂度越来越高,也就是说,业务层面对的主要技术挑战是"复杂性". 幸运的是,面对业务层的技术挑战,我们有一把屠龙宝刀,神挡杀神,佛挡杀佛,不管什么业务难题,用上屠龙宝刀一试都迎刃而解.这把屠龙宝刀就是"拆". 复杂性的一个主要原因就是系统越来越庞大,业务越来越多,降低复杂性最好的方式就是"拆&

抢购(秒杀)业务的技术要点

本文为原创文章,转载希望注明出处. 抢购业务数据库需要考虑的点如下: 一.超卖现象 场景如下: 库存数是5.现在3个用户来购买,a用户购买2个,b用户购买3个,c用户购买1个.合起来就是准备购买6个. 如果三个用户是同时并发购买,会出现怎样的情况呢? 每个用户进行减库存的时候,语句类似于: update goods set amount=amount-购买数量 where goods_id=xxx. mysql会锁定这一行数据(使用innodb存储引擎),数据库加的是排他锁.根据排他锁的特点:其

需求推动技术的产生

需求推动着技术的发展,技术的发展本质上是为了解决现在技术无法解决的问题.无论计算机技术如何发展,都离不开这几个核心架构:采集数据.处理数据.输出数据,本质上是对数据的处理,技术只是不同的实现方式,但处理数据的手段和数据多而杂乱之间的矛盾越来越激烈,一种新的处理技术就会响应需求而生. 原文地址:https://www.cnblogs.com/2bjiujiu/p/9114269.html

业务系统技术架构的方法论

业务类系统(通常称为To B 类产品),一般包括crm,供应链,物流等.系统的架构设计非常具有挑战性. 面向用户的To C 类前台产品,无论产品经理还是用户都已经培养起了使用习惯,对功能有一定程度的理解,见过的模式足够多,能够建立起一定的产品模型,也容易找到参照物去模仿.但是业务类的系统,常常是没有参照和模仿,一些业务流程的不同,一点公司组织结构的不同,你家的CRM和他家的CRM可能完全没有参考性.所以在搭建产品架构的时候则要求产品经理非常懂业务,考验PM能力的同时,对技术架构也具备很大的挑战.