世界格局在进入 21 世纪之后风云变幻，软件领域同样风起云涌。从硬件到软件，从单机到分布式，从孤岛到互联，程序员的创造力无比强大。但究其本质，软件工程和土木工程其实没有太大的区别，只不过一个是在码字母，一个是在码砖头。至于建筑的主体，设计缺陷，或者地基没打好，一样会垮塌，不管是楼塌了还是软件崩了，都可能成为整个世界都能感知到的大事件。

一、开发模型的演进

选择何种模型对软件工程的工作开展至关重要，甚至对一段时期的技术特点都会产生本质性影响。所以，第一节必须从这里开始讲起。

受此影响，早期的互联 Web 工程的开发也是遵从瀑布模型的组织形式来进行的，也许在执行上有所变形，但从系统架构上看，瀑布模型的痕迹非常明显。比如我们公司十八罗汉之一的一指主导的 WebX 框架（刚入职那会我有幸通过旺旺向还身在加拿大的一指请教过技术问题），通过配置和 Package 将工程切分的非常细致，让每一个工种都能找到自己应该按部就班的地方，负责写 SQL 的，负责写 HTML 的，负责写 JS 的，负责展示层模板的，负责事务层的，负责数据模型的等等，当页面上需要新增一个功能的时候，如果分工的每一层都需要一名专职程序员来做，那么很可能就要驱动 10 来位程序员进行修改，由于框架明确了这些人的工作范围和职责，所以这些人需要坐在一起讨论需求，通过文档来沟通对接细节，讨论单测和集测的展开，最终这些文档和沟通工作都完成后，武林高手们终于在一瞬间出手，页面上添加的那个活动页终于在最后一瞬间出现了，这时候，收到交付产物的运营抬起头一看日历，双十一大促已经是半个月前的事情了，忙活了大半年，大家什么都考虑到了，就是没考虑到耗时排期的漫长。

但是，互联 怎么可能静下心来慢慢欣赏你的瀑布。过程做的再好，交付出一个过期的产品都是不可接受的，所以坚持这个模型走上互联 之路的公司大多都死了，甚至有些过于注重过程的国家（比如日本）都因此在互联 时代销声匿迹。短平快地贴近用户需求进行极限开发才是互联 不变的主题，所以敏捷（Agile）开发快速在互联 的世界大行其道。因此带来的极限编程、结对编程，在 2010 年前后迅速点爆整个软件工程界，几乎不敏捷就跟不上时代了。甚至由于深受瀑布模型缺点困扰多年的一些公司，会 复性地去实施敏捷，看到谁准备工作多了点，讨论得深入了些，那些还没进入行业几年的“资深”程序员就会斥责新人们不够 Agile。而互联 时代的指数级增长，动不动一个风口，使得大家都深陷浮躁之中，激进到甚至连错误的观念都被增长所掩盖，而得不到纠正的机会。因为吸引人们眼球的永远都是成功表面的浮华，谁会进去看看背后那堆臃肿杂乱的稻草呢/p>

到 2015 年前，互联 技术风向标开始倡导全栈，对研发人员的要求也越来越多，最基本的是前后端的全栈通吃，测试、运维也转向服务化，设计了大量的测试和运维平台，围绕研发过程的自动化探索效率与质量的平衡点。而随着硬件性能的提升，虚拟机技术越来越成熟，传统运维观念逐渐改变，开发测试运维的边界也越来越模糊，DevOps 概念呼之欲出，在敏捷的基础上继续推进变革，容器、弹性扩缩容、高可用等新技术的出现，终于将软硬件在 DevOps 这个模型上结合到了一块，就像 DevOps 的经典图形 ∞ 符 那样，未来甚至还看不到这一趋势的终点。

二、技术的演进

技术是服务于开发模式的，在一种开发模式下，适配的技术体系总是与之呼应，并相辅相成。所以随着瀑布到敏捷再到 DevOps，随着硬件性能的提升，也随着大神们改变世界的驱动力，技术在各种探索和喧闹中不断演进。

1、服务框架

上文提到我们阿里早期使用的 WebX，其实这个框架和当时流行的 SSH（Struts+Spring+Hibernate）思路差不多，发展到 3.0 版本之后，就逐渐退出了历史舞台，但是历史包袱还在，ATA 上还能看到有人在撰文写一些 WebX 的学习心得，大多数情况应该是接手了某个相当沉重的历史应用，不得不去面对这个古老的框架。WebX 在互联 还没那么复杂庞大，软件基础模块也没有封装得那么完善的年代，是一个优秀的框架，它甚至让淘宝 躲过了 Struts 的 0day 漏洞满天飞的厄运。从 PHP 过渡来的淘宝 ，正是在这个性能一般般、开发效率很低的框架下逐渐开始走上正轨。

WebX 无论是在开发还是部署上，都属于相当笨重的一套框架，而几乎是同年起步的 Spring 则轻巧灵活了许多。2017 年，我去湾区参加 Spring 大会，还有幸与 Spring 之父 Rod Johnson 要了合影，只是那会他已经淡出了 Spring 区。（Spring 的编年史见附录 1）

在 Spring 的基础之上，面向企业级的 MVC 框架 SpringMVC ，更加轻量灵活、应用约定大于配置思想的 SpringBoot，还有关注微服务整合的 SpringCloud，最终组成的 Spring 家族，完整提供了面向不同需求的服务端解决方案。

2015 年是个分水岭，我们公司 2015 年前 SpringBoot 还只是零星试点，之后几年就立即遍地开花，好像书上常说的，历史的车轮滚滚向前，框架的车轮显然也不会停歇。持久层框架也从笨重的 Hibernate 转到了 iBATIS，再到 MyBatis。前文提及的全栈工程师，到了 2015 年后，随着手持设备硬件性能的提升、浏览器 H5 标准的统一、移动端的兴起，前端三剑客 Vue、AngularJS、React 也开始逐渐引领大旗，一度被后端模板化渲染夺走的技术阵地，竟然在边缘计算这样的概念下，又复活了。本来全栈的程序员们，也重新被划分成了前端和后端两个 Job Code，而此时两者的职责和最初的定义已经完全不同了。此时的后端更加注重对业务和需求的理解，专注于性能和架构的优化，而前端则更偏向于交互和体验，尤其在一些重前端的 toB 类产品上，前端的主导性更大。后端提供零散接口，而前端更希望采纳整合后的统一接口，后来催化了多以 Node.js 语言为主开发的 BaaS（Backend As A Service）层微服务，一般也是由前端工程师来负责。个人感觉，BaaS 的引入更适合移动端的开发，对传统 PC 端浏览器应用的协作效率提升较小。前后端分离还带来了一系列新技术的诞生，例如 CDN 技术，使得前端更加独立，甚至在后端服务宕机的情况下，还能提供一定的挽留用户体验。

而在服务端技术上，中间件在过去十年间大放异彩，我们公司在中间件上做出的成绩就不用多讲了，这和当初提出的大中台小前台背景不无关系。庞大的中间件群体带来的效率提升也经常是变革性的，最初看起来一切都很美好，直到频繁升级开始带来效率反噬的时候，我们才意识到其中的问题。框架使研发能够通过代码掌控一切，而中间件则通过集中式服务来降低代码工作量。所以无论是框架的演进，还是中间件的演进，都应该有一个平衡点，完全依赖某一方都会导致失衡，从而带来工程效率上的灾难。在服务端依赖的底层基础设施上，虽然从 2003 年至今的大多数年份，电商始终处于风口上，但也依然有一些为了省钱应该要做的事情。从操作系统、数据库、计算能力等几个方向上节约成本，是效率最高的，在电商规模起来后，由章文嵩主导的 LVS、淘系的去 IOE 等重大技术变革，一方面为阿里省了钱，另一方面也让自主的技术体系不再受外部技术提供商的掣肘。进而电商系的技术自研能力逐步开始领导互联 时代。

2、编程语言

微服务起步后，给予更多小众语言以更好的生存环境，Service Mesh 技术让小众语言也可以通过接口或者系统调用获得更多中间件体系提供的便利。虽然当前还远未到完全成熟应用的阶段，尚处于前沿，但的确是一个很好的方向，让编程世界的多样性和竞争性充满了希望。但在微服务之下的 SOA，大多数还是建立在传统语言之上。我司发展了那么多年的 Java 体系，带来的群体优势是其他语言无法比拟的。不少语言，虽然在编程效率上优于 Java，但一旦用来做大型工程，则会在到达一定规模的时候陷入自洽性矛盾：要么放弃语言的灵活性，要么放弃工程的可持续性。在服务端技术上，当前我司还是以 Java 为主的，这就好比引擎层，大多是 C/C++ 为主，而算法层则是 Python 为主，成体系的事情，我们没必要多做讨论。至于更加冷门的语言，比如 Lisp、Scala 等更常见于特定的领域。

这一节就到此为止，不再引战。

3、大数据

2003 年是个神奇的年份，淘宝 在这一年诞生，Rod Johnson 正在编写 Spring 的初版，而 Google 则在这一年发表了奠定大数据基础的三大论文的第一篇《Google File System》，随后又在 2004 年发表了 MapReduce，2006 年发表了 BigTable。有了这三篇划时代的论文，在当时的搜索行业老二雅虎的支持下，Hadoop 迅速发展了起来。

在 21 世纪的第一个十年，大数据体系 HDFS + MapReduce 就已经完成了奠基工作（参照附录 2），对未来软件工程带来的积极影响无法估量，甚至可以说没有大数据的发展，后来的机器学习和 AI，都将因为没有土壤而无法顺利商用。建立在这个基础之上，计算的弹性也被明确定义，进而发展成云计算，再到后来与资源的弹性结合，促进了世界范围的云厂商的繁荣。

图片引自：https://www.oreilly.com/library/view/distributed-computing-in/9781787126992/5fef6ce5-20d7-4d7c-93eb-7e669d48c2b4.xhtml

最初我们使用 MapReduce 的时候，是直接通过编写 MR Job，通过 Split、Map、Shuffle、Reduce 等过程完成一个任务的设计开发。这对程序员的要求还是比较高的，编写过一些 MR job，就会意识到这样的任务在编程开始前，就要在头脑中形成数据全局观，从结果数据倒推初始数据的切分，稍有不慎就可能造成长尾计算或者数据倾斜。上手难度大、调试成本高、开发周期长，这一切到了 2010 年使用 MySQL 解析引擎的 Hive 出现后，终于通过简单易学的 SQL 语言避开了上述难题，数据开发的效率像坐上了火箭一般迅速提升。也是到了此时，全球范围随着数据量的积累，大数据的威力逐步展现，数据开发工程师这个全新的 Job Code 也在此时诞生。

当时的中国，能够使用这些大数据产生商业价值的，只有百度和淘宝。而作为承载数据开发的平台，从云梯 1 时代的天 ，到当前的 DataWorks，进一步降低了数据开发的门槛，就算没有什么基础，产品和运营也都可以通过简单的学习，就能在 DataWorks 之上具备基本的 ETL 能力。而 DataWorks 通过其核心的调度系统，组装了千万级任务，通过每晚 0 点到早晨 9 点的大规模集中计算，实现了阿里巴巴体系下所有离线数据的生产。海量数据领域的门槛降低，效能却大幅度提升，轻易就可以将数据间的交互计算任务挂载到我司数百 PB 的商业大数据中，从而通过数据来激发工程能力。此外，还可以通过 UDF 函数，在 DataWorks 平台上能够快捷的实现复杂计算逻辑，再通过 Function Studio 进一步提升编码调试效率。此外，由于数据开发语言具备一定的通用性，因此在 OLTP 和 OLAP 领域，为提升数据的利用率和复用开发人员的产出，流批一体（一条 SQL 既可以跑在流也可以跑在批）和数据湖（同一份数据可跑多种计算引擎）技术在持续演进。至此，到了 21 世纪的第二个十年结束前，大数据领域的核心工作基本上已经全部完成，如今只剩下在前人基础上的修修补补，以及不断的压榨集群硬件的利用率和提升运维效率这几件事了。

还有 NoSQL 领域，代表作 HBase 在 2010 年成为 Apache 的顶级项目，我是在 2009 年跟随我当时的同事，身为 HBase 区 Committer 的“Andrew Purtell”进入了 NoSQL 的世界。当时的 HBase 还完全是个玩具，动不动就彻底崩溃，回想起来，当时 Base 在美国的 Andrew 绕过大半个地球跑来中国满头大汗地给我讲解 NoSQL 的实现原理，虽然这项技术当时还很挫，但很快 HBase 就成熟并实现了商用。NoSQL 成为当前主流的能够提供在线服务的 BigTable，也和 Google 的搜索引擎的实现技术有很大关联，尤其记得当年第一次来杭州面试阿里云的时候，当时的面试官问我 Google 如何实现海量数据索引，当我回答 NoSQL 的常规实现方案后，面试官甚为不解，进而和我为是否需要 NoSQL 吵了一下午。当年的云计算和大数据的前沿性可见一斑，领域内的行家屈指可数，虽然那次争吵非常不愉快，最终不欢而散。但在半年后，我还是参加了淘宝的面试，最终来到了杭州。

我在 2011 年加入淘宝云梯 1 团队的时候，当时的 Hadoop 集群只有一千多台机器的规模，到 2014 年云梯 1 的 Hadoop 集群下线前达到了单集群双机房 1 万台物理机（当年的单体规模全球最大）。当时的 C 和 Java 性能之争，开源和自研之争，激烈的观点冲突放到现在来看都是上乘的技术探讨典范。然而时过境迁，斯人已去，唯有当初那台签满研发人员名字，承载过 Hadoop Master 的刀片服务器，还留在云智能的飞天博物馆永久陈列。

4、机器学习与 AI

数据到了海量之后，机器学习才有了生根发芽的土壤，通过机器学习的积累，人工智能的威力在最近的 5 年间开始爆发。2010 年 Hadoop 上的机器学习工具 Mahout 成为 Apache 的顶级项目，但真正在深度学习领域发挥实力的还是大神贾扬清的 Caffe 和他参与的 TensorFlow。这个领域在商业上的应用相对来说起步很晚，基本上到了 2015 年后，才在千人千面、猜你喜欢、无人驾驶等领域开始大放异彩。对于 21 世纪第三个十年的软件工程来说，可以看得见机器学习与 AI 必将成为产品上不可分割的一部分，算法工程师不再沉迷于和人类对战国际象棋，而开始深度参与到直面用户需求的过程中。

但是，当前承载算法，如神经 络、深度学习的平台还不够优秀，距离 Hive 之于 Hadoop 这样的效率提升还有不小的差距。我司的 PAI 平台已经在探索算法优化的道路上前进了一大步，它将数据和算法当做材料，通过 DAG 组织算法序列，在易用性上已经提升了不少，但对于普通开发者来说还是过于复杂了。Jupyter Notebook 则另辟蹊径，将论文与代码相结合，可以让算法研究者一边写论文一边写代码，待论文完成后，就可以在 Jupyter 平台上执行新的算法验证效果，因为算法大多属于文档远多于代码的一种开发过程，因此 Jupyter 的创意带来的沉浸式体验提升了学者的创新效率，也降低了他们进入工程领域的门槛。

更早的时候，淘系搜索推荐采用效率更高的线上分桶方式，快速验证算法的效果，类似于工程上的灰度，将不同算法灌装到不同的桶里提供给用户，通过用户的成交率、客单价等指标快速优选出合适的算法，这样的产品比如 TPP（The Personalization Platform）。虽然业界已经在快速发展，但整体来说，算法还是相对于工程之外相当独立且门槛还没降到足够低的一个领域，如果能够出现类似 Hive 这样跳跃式降低大数据门槛的产品，那么机器学习与 AI 领域的发展可能就会被直接引爆，人类 会的进化进程说不定都会因此而加速（也许是机器代替人类，谁知道呢）。

5、其他

运维领域在最近的十年里面发展迅猛，这一方面有赖于企业级硬件性能的大幅度提升，另一方面和开发模式的演进、思维观念的转变不无关联。十年前，机房中还在使用 God 系统来对刀片机进行物理式断电和重启，到后来的虚拟机技术 VMWare、Xen，再到 Docker 的出现，然后 K8s 服务编排进一步模糊了运维和研发的边界，结合云服务提供商的业务，最终促成如今的云原生时代。还有区块链技术、服务 格（Service Mesh）等，提升工程效率的新技术如雨后春笋一般不断涌现。这让我经常想起 2008 年我在日本富士通沼津市软件工场出差的那段时光，在巨大的一望无际的地下机房里，看到无数台密密麻麻的磁带阵列组成的存储矩阵，每一台阵列中都有一只机械手在不停的上下翻飞，快速插拔着几百盘磁带，实现寻址功能。而到了今天，单块磁盘的存储容量都已经达到了 20 TB 以上，大量的企业级存储已经被更快更稳定的 SSD 所替代，无论是硬件还是软件，摩尔定律始终在操控着计算机的世界，这么想来，软件工程的效率应该也是遵循着每 18 个月翻一倍的速度前进的吧。

三、漫谈软件工程

20 年是个不短的过程，一个成长中的孩童都有可能经历完了自己的青春，逐渐步入中年。但对于软件技术来说，似乎永远无法越过青春。我们能看到一个个技术从诞生到壮大再到成熟，直到被新的技术汰换而走完生命周期，但是整个技术界随着新技术的诞生，又开始再次沸腾。如果说过去的 20 年有什么永恒的主题，那一定是围绕着工程效能展开的。

技术领域的素材散落在各处，如果都依赖架构师和程序员的组合拼装，效率显然极低，且无法复制。因此软件工程需要有一个组织体系，这就好比交响乐需要一名指挥家，邮轮需要一名舵手。下面这幅图展示了当前云体系下的产品地图：

组织好这些产品，让其在合理位置上支撑业务的发展，并引导工程师的心智，倡导正确的方向，这些掌舵的工作正是研发效能团队应该承担的责任。现阶段的软件工程，已经不再是过去那种简单的围绕着数据库 CRUD 的编排服务，当一个工程在代码仓库里落下第一行代码，就意味着它需要和资源、 络、中间件、离线计算、搜索引擎、实时计算、算法、运维、测试、安全等一系列技术体系打交道。这个时代对程序员的要求越来越高，但软件工程领域的抽象也随着这样的要求在不断聚合，从而使得门槛降低，复杂度也越来越简化。持续集成、持续部署、持续发布在软件工程领域成为每个人都在讨论的话题，尤其当蓝海逐步转向红海，从烧钱转向比拼效率，研发效能以及服务工程师的底层基础设施的重要性尤其凸显。最近看到一张图很好地诠释了研发基础设施在组织软件工程上的重要性。

图片引自：《一文看懂云原生时代 DevOps 如何选型》

当我们站起身来环顾世界，Google 作为技术界风向标，正在通过大库寻找工程的稳重和灵活的平衡点，Github Actions 正在通过代码驱动持续集成，而 K8s 区正在努力探索 IaC 的可行性。未来的世界一切皆为代码驱动，元宇宙正在向我们走来，而这一切都要基于一套易用好用且可靠的基础设施，来帮助未来的工程师们高效研发。

四、研发基础设施

何谓基础设施，类比于生活中的水电煤，美好的生活离不开这些现代化的设施，但每个人都已经习以为常他们的存在，甚至感知不到这些设施在生活中的重要性。而研发基础设施也正是要向这样的方向努力。

过去 20 年间，与研发效能相关的工具很多，但平台其实寥寥无几。往往也只有大型软件公司才能够自建配套的基础设施体系，提供从需求到编码再到发布上线的全套辅助。作坊式的小企业，大多通过人工伺服软件工程的开发流程。所以在 2015 年前的阿里巴巴，虽然 Aone 不算好用，但毕业的同学大多会在别的公司怀念 Aone。直到虚拟技术的发展，K8s 的出现，终于打破了大公司才能拥有自己的发布体系的神话，即使是小作坊，也可以快速搭建一套符合自身业务特点的发布管控平台。发布运维的门槛在软硬件的配套发展下，也最终臣服于工程师的脚下。而恰恰在过去的 5 年时光里，我司的 CICD 体系却因为种种原因停滞不前，错过了最好的发展时机。然而一切并未太晚，我们引以为傲的数万工程师群体，必将鞭策我们热爱的研发基础设施继续进化，并超越时代。

而好的基础设施，最好是对用户来说是透明的，无感的，丝般顺滑的。这对于深后台类型的基础设施来说，做到对用户无感相对会更容易些，但对于代码仓库、CICD、协作、应用等前台功能为主的研发基础设施来说，优良的体验能够极大的提升工程师的幸福感从而提升研发效率。程序员的日常工作沉浸在其中，代码仓库在评审体验、搜索体验、阅读体验上逐步精进，围绕代码做文章，引入我们想要倡导的代码规范和度量指标，让工程师们能够像享受一杯咖啡一样享受写代码的过程。而工程师之间的技术探讨、需求沟通，我们可以通过功能极简的工作项体系进行相互之间的协作。到了编码之后，所有工作通过自动化流程实现快速可靠的 CICD，我们需要的是将这些基础设施串联成一个有机的整体，最终还能够通过度量洞察体系来汇总整个集团的效能。

美好的愿景，在波澜壮阔的20年中经常被提起，可以看见的未来，史诗般宏大的工程必将诞生于即将到来的万物互联的智能化时代。当 会的组织与研发的协作在追光灯下同频共舞，开启的必将是更加大气磅礴的人类智慧之光。曾经的技术梦想在大神的努力下已经成为历史，镌刻在博物馆的石牌上，还有更多理性的憧憬和创新的火花在更加遥远的未来闪耀，静候着年轻的大神们踩过前人的脚印前来捡拾，待若干年后，会有另一位记叙者重新开始漫谈这个世界曾经的辉煌，记录这隶属于人类独有智慧的软件工程。

五、附录

1、Spring 编年史

• 2004 年 03 月，1.0 版发布

• 2006 年 10 月，2.0 版发布

• 2007 年 11 月，更名为 SpringSource，同时发布了 Spring 2.5

• 2009 年 12 月，Spring 3.0 发布

• 2013 年 12 月，Pivotal 宣布发布 Spring 框架 4.0

• 2017 年 09 月，Spring 5.0 发布

2、Hadoop 编年史

• 2004 年— 最初的版本（现在称为 HDFS 和 MapReduce ) 由 Doug Cutting 和 Mike Cafarella 开始实施

• 2006 年 2 月— Apache Hadoop 项目正式启动以支持 MapReduce 和 HDFS 的独立发展。雅虎的 格计算团队采用 Hadoop

• 2008 年 9 月— Hive 成为 Hadoop 的子项目

• 2008 年— 淘宝开始投入研究基于 Hadoop 的系统–云梯 1。云梯总容量约 9.3PB，共有 1100 台机器，每天处理 18000 道作业，扫描 500TB 数据

• 2009 年 3 月— Cloudera 推出 CDH（Cloudera’s Dsitribution Including Apache Hadoop）

• 2009 年 7 月— Hadoop Core 项目更名为 Hadoop Common

• 2009 年 7 月— MapReduce 和 Hadoop Distributed File System (HDFS) 成为 Hadoop 项目的独立子项目

• 2010 年 5 月— HBase 脱离 Hadoop 项目，成为 Apache 顶级项目

• 2010 年 9 月— Hive (Facebook) 脱离 Hadoop，成为 Apache 顶级项目

• 2010 年 9 月— Pig 脱离 Hadoop，成为 Apache 顶级项目

• 2011 年 1 月— ZooKeeper 脱离 Hadoop，成为 Apache 顶级项目

• 2011 年 7 月— Yahoo! 和硅谷风险投资公司 Benchmark Capital 创建了 Hortonworks 公司，旨在让 Hadoop 更加鲁棒 (可靠)，并让企业用户更容易安装、管理和使用 Hadoop

• 2011 年 8 月— Dell 与 Cloudera 联合推出 Hadoop 解决方案——Cloudera Enterprise

• 2012 年 6 月— 单机房 5000 台容量上限即将引起数据增长撞墙，云梯 1 开始研发跨机房 5K+，并在次年成功

• 2013 年底 — 阿里巴巴云梯 1 达到单集群双机房 1 万台机器后，开始逐步下线。登月计划启动，云梯 1 过渡到云梯 2（ODPS）上，最终于 2015 年彻底下线

文章知识点与官方知识档案匹配，可进一步学习相关知识算法技能树首页概览34189 人正在系统学习中