作者 | 劉星
世界格局在進入 21 世紀之後風雲變幻，軟體領域同樣風起雲湧。從硬體到軟體，從單機到分布式，從孤島到互聯，程式員的創造力無比強大。但究其本質，軟體工程和土木工程其實沒有太大的差別，隻不過一個是在碼字母，一個是在碼磚頭。至于建築的主體，設計缺陷，或者地基沒打好，一樣會垮塌，不管是樓塌了還是軟體崩了，都可能成為整個世界都能感覺到的大事件。
本文作者劉星先後經曆安全行業和大資料領域，2011 年加入淘寶，參與了當時全球最大的 Hadoop 叢集的開發和運維，在阿裡先後擔任資料開發平台研發負責人、研發效能 Aone 研發負責人。本文中，他将從 2003 年淘寶網成立那年開始，回顧總結這些年來軟體工程體系的主線技術，探讨變化和趨勢，并從自己的視角給出一些觀點和思考。
開發模型的演進
選擇何種模型對軟體工程的工作開展至關重要，甚至對一段時期的技術特點都會産生本質性影響。是以，第一節必須從這裡開始講起。
20 年前還是以單機軟體為主的時代，以作業系統、辦公套件、ERP 系統等為代表的大型合作類型軟體工程，特點是研發周期長、進度緩慢，一旦分發到個人電腦上則不容易被召回替換。一旦軟體比較優秀，滿足了使用者的基本需求，就很難推動使用者再去更新，是以當年 Windows 更新換代替換任何一個成功版本都非常艱難。在這樣的背景下，瀑布模型是最主流的一種開發模型，幾乎壟斷了所有大型軟體的工程開展。瀑布模型的優點和缺點已經被總結的很好，本文不做展開，僅以我自身參與的瀑布模型工程體驗來簡單說一說。整個瀑布模型，就是大家經常提到的 V 字形，從需求到傳遞，位于 V 字最低端的是真正的編碼過程，V 代表瀑布模型，簡直是再恰當不過的字母，因為編碼過程在這個模型中，真的就隻占用那個端點的長度，其他時間都被各種讨論過程和文檔占據。好像一個武林高手，在擂台上做了幾個小時的準備工作，萬事俱備後，突然出手用手指點了一下目标，然後就立即收手又搞了幾個小時的收拾現場工作，大家都沉迷于這位高手出手前後的花式展示，而真正出招的那個瞬間卻都被大家忽視了。據此誕生的 CMMI 認證，專門用來衡量高手出招前後姿勢漂不漂亮，熱身動作到不到位。
受此影響，早期的網際網路 Web 工程的開發也是遵從瀑布模型的組織形式來進行的，也許在執行上有所變形，但從系統架構上看，瀑布模型的痕迹非常明顯。比如我們公司十八羅漢之一的一指主導的 WebX 架構（剛入職那會我有幸通過旺旺向還身在加拿大的一指請教過技術問題），通過配置和 Package 将工程切分的非常細緻，讓每一個工種都能找到自己應該按部就班的地方，負責寫 SQL 的，負責寫 HTML 的，負責寫 JS 的，負責展示層模闆的，負責事務層的，負責資料模型的等等，當頁面上需要新增一個功能的時候，如果分工的每一層都需要一名專職程式員來做，那麼很可能就要驅動 10 來位程式員進行修改，由于架構明确了這些人的工作範圍和職責，是以這些人需要坐在一起讨論需求，通過文檔來溝通對接細節，讨論單測和集測的展開，最終這些文檔和溝通工作都完成後，武林高手們終于在一瞬間出手，頁面上添加的那個活動頁終于在最後一瞬間出現了，這時候，收到傳遞産物的營運擡起頭一看月曆，雙十一大促已經是半個月前的事情了，忙活了大半年，大家什麼都考慮到了，就是沒考慮到耗時排期的漫長。
對于傳遞到個人電腦上的産品來說，瀑布模型可以提供品質穩定、互動良好的産物，當然也是有失敗的可能，隻能說産出優秀産品的機率相對于其他模型來說會更高。但由于多級開發其實和真正的使用者之間的溝通是完全脫節的，是以有時候使用者希望得到一個圓柱體，拿到手的卻是一個長方體，項目經理隻能敷衍使用者：“這兩個物體的截面都是矩形”。到了個人電腦上，軟體缺陷就很難再通過簡單便捷的更新來彌補。這有點像專有雲，傳遞出去了，再想更新，可能要到半年後了，那麼期間出了故障，隻能請 ISV 到現場幫忙檢測，有時候甚至隻能通過拍照提供一些資料回來，碰到軍工政府類型的專有雲項目，稽核更加嚴格，周期更加漫長。把整個專有雲想象成當年你桌上那台沒有網卡的單機電腦，還是比較形象的。
但是，網際網路怎麼可能靜下心來慢慢欣賞你的瀑布。過程做的再好，傳遞出一個過期的産品都是不可接受的，是以堅持這個模型走上網際網路之路的公司大多都死了，甚至有些過于注重過程的國家（比如日本）都是以在網際網路時代銷聲匿迹。短平快地貼近使用者需求進行極限開發才是網際網路不變的主題，是以靈活（Agile）開發快速在網際網路的世界大行其道。是以帶來的極限程式設計、結對程式設計，在 2010 年前後迅速點爆整個軟體工程界，幾乎不靈活就跟不上時代了。甚至由于深受瀑布模型缺點困擾多年的一些公司，會報複性地去實施靈活，看到誰準備工作多了點，讨論得深入了些，那些還沒進入行業幾年的“資深”程式員就會斥責新人們不夠 Agile。而網際網路時代的指數級增長，動不動一個風口，使得大家都深陷浮躁之中，激進到甚至連錯誤的觀念都被增長所掩蓋，而得不到糾正的機會。因為吸引人們眼球的永遠都是成功表面的浮華，誰會進去看看背後那堆臃腫雜亂的稻草呢？
到 2015 年前，網際網路技術風向标開始倡導全棧，對研發人員的要求也越來越多，最基本的是前後端的全棧通吃，測試、運維也轉向服務化，設計了大量的測試和運維平台，圍繞研發過程的自動化探索效率與品質的平衡點。而随着硬體性能的提升，虛拟機技術越來越成熟，傳統運維觀念逐漸改變，開發測試運維的邊界也越來越模糊，DevOps 概念呼之欲出，在靈活的基礎上繼續推進變革，容器、彈性擴縮容、高可用等新技術的出現，終于将軟硬體在 DevOps 這個模型上結合到了一塊，就像 DevOps 的經典圖形 ∞ 符号那樣，未來甚至還看不到這一趨勢的終點。
技術的演進
技術是服務于開發模式的，在一種開發模式下，适配的技術體系總是與之呼應，并相輔相成。是以随着瀑布到靈活再到 DevOps，随着硬體性能的提升，也随着大神們改變世界的驅動力，技術在各種探索和喧鬧中不斷演進。
服務架構
上文提到我們阿裡早期使用的 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 等重大技術變革，一方面為阿裡省了錢，另一方面也讓自主的技術體系不再受外部技術提供商的掣肘。進而電商系的技術自研能力逐漸開始上司網際網路時代。
程式設計語言
為什麼程式設計語言放在了架構之後，因為提及語言，必然會引起程式員們的争論，假設說一句“ PHP 是世界上最好的語言”，必然引爆此文，讓衆多讀者棄之如敝履。上文的架構已經引入了經常被我司同學鄙視的祖傳 Java，還有衆多 Python、C/C++、Golang 等語言的大拿正在摩拳擦掌，準備群毆本文的觀點。但即便如此，我還是想提出一個看法，即語言是服務于系統架構的，适配于場景來選擇我們需要的語言是一名程式員的基本素養，而不是基于愛好。軟體工程一旦發展到比較龐大的規模，即使是再先進的語言，如果不能撿拾前人的積累，都會導緻不得不重新造輪子，引發效率的下降。雖然不少語言都會有一個典型的産品來代表，比如日本人設計的 Ruby 語言的代表作是 Gitlab，但如果讓商業化公司來選用，也不得不面對冷門語言招聘困難的局面，即使招到了資深的冷門語言專家，他們的未來發展也是一個大問題。是以像 Kotlin 這樣可以直接利用 Java 積累的語言，會更容易被接受一些。最近在面試的時候，也發現快手和位元組的一些主流用 Golang 的團隊，正在重構回 Java 體系，問及原因，大多也是因為商業化企業需要的是多快好省。在風口上沒有暴露的問題，正在網際網路寒冬下逐漸浮現。
微服務起步後，給予更多小衆語言以更好的生存環境，Service Mesh 技術讓小衆語言也可以通過接口或者系統調用獲得更多中間件體系提供的便利。雖然目前還遠未到完全成熟應用的階段，尚處于前沿，但的确是一個很好的方向，讓程式設計世界的多樣性和競争性充滿了希望。但在微服務之下的 SOA，大多數還是建立在傳統語言之上。我司發展了那麼多年的 Java 體系，帶來的群體優勢是其他語言無法比拟的。不少語言，雖然在程式設計效率上優于 Java，但一旦用來做大型工程，則會在到達一定規模的時候陷入自洽性沖突：要麼放棄語言的靈活性，要麼放棄工程的可持續性。在服務端技術上，目前我司還是以 Java 為主的，這就好比引擎層，大多是 C/C++ 為主，而算法層則是 Python 為主，成體系的事情，我們沒必要多做讨論。至于更加冷門的語言，比如 Lisp、Scala 等更常見于特定的領域。
這一節就到此為止，不再引戰。
大資料
2003 年是個神奇的年份，淘寶網在這一年誕生，Rod Johnson 正在編寫 Spring 的初版，而 Google 則在這一年發表了奠定大資料基礎的三大論文的第一篇《Google File System》，随後又在 2004 年發表了 MapReduce，2006 年發表了 BigTable。有了這三篇劃時代的論文，在當時的搜尋行業老二雅虎的支援下，Hadoop 迅速發展了起來。
在 21 世紀的第一個十年，大資料體系 HDFS + MapReduce 就已經完成了奠基工作（參照附錄 2），對未來軟體工程帶來的積極影響無法估量，甚至可以說沒有大資料的發展，後來的機器學習和 AI，都将因為沒有土壤而無法順利商用。建立在這個基礎之上，計算的彈性也被明确定義，進而發展成雲計算，再到後來與資源的彈性結合，促進了世界範圍的雲廠商的繁榮。
我認為，這裡最重要的是第二篇論文 MapReduce 程式設計思想，它将複雜的問題劃分成小塊，然後逐一破解，再将結果彙總。如果一次 MR 不夠，可以使用上一個任務的輸出進行第二次、第三次、第 N 次的 MR，直到取得最終需要的結果。後來，無論是大量使用記憶體進而使計算更快的批處理産品 Spark、Impala、Spark Streaming（微批），還是流式計算 Flink、Kafka，在計算的核心思想上都沿用了 MapReduce。這有點像微積分，Map 相當于微分學，Reduce 相當于積分學，當兩者結合，就可以降低問題的複雜度，幾乎就可以解決現實中的一切難題。數學上微積分用來對付無窮，而 MapReduce 用來對付趨近無窮的海量資料，的确是最恰當不過了。
圖檔引自：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 的刀片伺服器，還留在雲智能的飛天博物館永久陳列。
機器學習與 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 領域的發展可能就會被直接引爆，人類社會的進化程序說不定都會是以而加速（也許是機器代替人類，誰知道呢）。
其他
圍繞軟體和網際網路行業，技術新進展層出不窮，還有一些相對來說沒有在聚光燈下，但也非常重要的技術領域，本文限于篇幅沒有提及。比如安全技術、測試技術、運維技術、存儲技術等。在軟體工程中，這些領域不可或缺，但往往對工程的效率影響并不一定都是正向的，比如安全技術對網際網路軟體工程進度的影響往往就是負面的，而且還做不到對程式員無感。
運維領域在最近的十年裡面發展迅猛，這一方面有賴于企業級硬體性能的大幅度提升，另一方面和開發模式的演進、思維觀念的轉變不無關聯。十年前，機房中還在使用 God 系統來對刀片機進行實體式斷電和重新開機，到後來的虛拟機技術 VMWare、Xen，再到 Docker 的出現，然後 K8s 服務編排進一步模糊了運維和研發的邊界，結合雲服務提供商的業務，最終促成如今的雲原生時代。還有區塊鍊技術、服務網格（Service Mesh）等，提升工程效率的新技術如雨後春筍一般不斷湧現。這讓我經常想起 2008 年我在日本富士通沼津市軟體工場出差的那段時光，在巨大的一望無際的地下機房裡，看到無數台密密麻麻的錄音帶陣列組成的存儲矩陣，每一台陣列中都有一隻機械手在不停的上下翻飛，快速插拔着幾百盤錄音帶，實作尋址功能。而到了今天，單塊磁盤的存儲容量都已經達到了 20 TB 以上，大量的企業級存儲已經被更快更穩定的 SSD 所替代，無論是硬體還是軟體，摩爾定律始終在操控着計算機的世界，這麼想來，軟體工程的效率應該也是遵循着每 18 個月翻一倍的速度前進的吧。
漫談軟體工程
20 年是個不短的過程，一個成長中的孩童都有可能經曆完了自己的青春，逐漸步入中年。但對于軟體技術來說，似乎永遠無法越過青春。我們能看到一個個技術從誕生到壯大再到成熟，直到被新的技術汰換而走完生命周期，但是整個技術界随着新技術的誕生，又開始再次沸騰。如果說過去的 20 年有什麼永恒的主題，那一定是圍繞着工程效能展開的。
技術領域的素材散落在各處，如果都依賴架構師和程式員的組合拼裝，效率顯然極低，且無法複制。是以軟體工程需要有一個組織體系，這就好比交響樂需要一名指揮家，郵輪需要一名舵手。下面這幅圖展示了目前雲體系下的産品地圖：
組織好這些産品，讓其在合理位置上支撐業務的發展，并引導工程師的心智，倡導正确的方向，這些掌舵的工作正是研發效能團隊應該承擔的責任。現階段的軟體工程，已經不再是過去那種簡單的圍繞着資料庫 CRUD 的編排服務，當一個工程在代碼倉庫裡落下第一行代碼，就意味着它需要和資源、網絡、中間件、離線計算、搜尋引擎、實時計算、算法、運維、測試、安全等一系列技術體系打交道。這個時代對程式員的要求越來越高，但軟體工程領域的抽象也随着這樣的要求在不斷聚合，進而使得門檻降低，複雜度也越來越簡化。持續內建、持續部署、持續釋出在軟體工程領域成為每個人都在讨論的話題，尤其當藍海逐漸轉向紅海，從燒錢轉向比拼效率，研發效能以及服務工程師的底層基礎設施的重要性尤其凸顯。最近看到一張圖很好地诠釋了研發基礎設施在組織軟體工程上的重要性。
當我們站起身來環顧世界，Google 作為技術界風向标，正在通過大庫尋找工程的穩重和靈活的平衡點，Github Actions 正在通過代碼驅動持續內建，而 K8s 社群正在努力探索 IaC 的可行性。未來的世界一切皆為代碼驅動，元宇宙正在向我們走來，而這一切都要基于一套易用好用且可靠的基礎設施，來幫助未來的工程師們高效研發。
研發基礎設施
何謂基礎設施，類比于生活中的水電煤，美好的生活離不開這些現代化的設施，但每個人都已經習以為常他們的存在，甚至感覺不到這些設施在生活中的重要性。而研發基礎設施也正是要向這樣的方向努力。
過去 20 年間，與研發效能相關的工具很多，但平台其實寥寥無幾。往往也隻有大型軟體公司才能夠自建配套的基礎設施體系，提供從需求到編碼再到釋出上線的全套輔助。作坊式的小企業，大多通過人工伺服軟體工程的開發流程。是以在 2015 年前的阿裡巴巴，雖然 Aone 不算好用，但畢業的同學大多會在别的公司懷念 Aone。直到虛拟技術的發展，K8s 的出現，終于打破了大公司才能擁有自己的釋出體系的神話，即使是小作坊，也可以快速搭建一套符合自身業務特點的釋出管控平台。釋出運維的門檻在軟硬體的配套發展下，也最終臣服于工程師的腳下。而恰恰在過去的 5 年時光裡，我司的 CICD 體系卻因為種種原因停滞不前，錯過了最好的發展時機。然而一切并未太晚，我們引以為傲的數萬工程師群體，必将鞭策我們熱愛的研發基礎設施繼續進化，并超越時代。
而好的基礎設施，最好是對使用者來說是透明的，無感的，絲般順滑的。這對于深背景類型的基礎設施來說，做到對使用者無感相對會更容易些，但對于代碼倉庫、CICD、協作、應用等前台功能為主的研發基礎設施來說，優良的體驗能夠極大的提升工程師的幸福感進而提升研發效率。程式員的日常工作沉浸在其中，代碼倉庫在評審體驗、搜尋體驗、閱讀體驗上逐漸精進，圍繞代碼做文章，引入我們想要倡導的代碼規範和度量名額，讓工程師們能夠像享受一杯咖啡一樣享受寫代碼的過程。而工程師之間的技術探讨、需求溝通，我們可以通過功能極簡的工作項體系進行互相之間的協作。到了編碼之後，所有工作通過自動化流程實作快速可靠的 CICD，我們需要的是将這些基礎設施串聯成一個有機的整體，最終還能夠通過度量洞察體系來彙總整個集團的效能。
美好的願景，在波瀾壯闊的20年中經常被提起，可以看見的未來，史詩般宏大的工程必将誕生于即将到來的萬物互聯的智能化時代。當社會的組織與研發的協作在追光燈下同頻共舞，開啟的必将是更加大氣磅礴的人類智慧之光。曾經的技術夢想在大神的努力下已經成為曆史，镌刻在博物館的石牌上，還有更多理性的憧憬和創新的火花在更加遙遠的未來閃耀，靜候着年輕的大神們踩過前人的腳印前來撿拾，待若幹年後，會有另一位記叙者重新開始漫談這個世界曾經的輝煌，記錄這隸屬于人類獨有智慧的軟體工程。
附 錄
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 釋出
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 年徹底下線
參考連結：
https://www.infoq.cn/article/hadoop-ten-years-interpretation-and-development-forecast