軟件歷史上有過兩次危機(jī)，有危機(jī)就有變革契機(jī)，第一次引出了“結(jié)構(gòu)化編程”，第二次引出了“面向?qū)ο缶幊獭保⒅苯訉?dǎo)致軟件工程的誕生。今天我們且不用“第三次軟件危機(jī)”這樣的表述，但可以看到的是，從 2010 年左右開始興起的云計(jì)算是程序的運(yùn)行環(huán)境繼“大型計(jì)算機(jī)”轉(zhuǎn)變到“客戶端 - 服務(wù)器”之后的又一場巨變。與前兩次軟件危機(jī)帶來的變革契機(jī)一樣，現(xiàn)有的許多軟件架構(gòu)和開發(fā)方法，一定也會(huì)在以十年為計(jì)數(shù)單位的時(shí)間段內(nèi)逐漸被顛覆，而今天你我所談的云原生、微服務(wù)等話題，僅僅是這次變革浪潮的開端。那么，軟件開發(fā)的下一個(gè)核心矛盾將會(huì)是什么？下一個(gè)時(shí)代的軟件架構(gòu)會(huì)具備何種特征？在今天由極客邦科技舉辦的 ArchSummit 全球架構(gòu)師峰會(huì) 2021（深圳站）上，華為 SaaS 首席軟件教練、《深入理解 Java 虛擬機(jī)》系列書籍作者周志明發(fā)表了主題演講《從軟件的歷史看架構(gòu)的未來》，以下為演講內(nèi)容整理。
1972 年，Edsger Dijkstra 在為圖靈獎(jiǎng)?lì)C授典禮所寫的感言文章中說到：“在沒有計(jì)算機(jī)的時(shí)候，也就沒有編程問題；當(dāng)我們有了簡單的計(jì)算機(jī)，編程就變成了小問題；而現(xiàn)在我們有了算力規(guī)模龐大的計(jì)算機(jī)，那編程就成為一個(gè)同樣復(fù)雜的大問題了。”半個(gè)世紀(jì)前，Dijkstra 已經(jīng)敏銳洞見了機(jī)器算力的提升是編程方法發(fā)展的直接牽引，每當(dāng)人類掌握了更強(qiáng)的算力，便按捺不住想去解決一些以前甚至都不敢去設(shè)想的新問題，由此引發(fā)軟件設(shè)計(jì)模式的重大變革。
計(jì)算機(jī)剛誕生的年代，硬件規(guī)模還很小，甚至程序員僅憑大腦就足夠記住數(shù)據(jù)在幾 KB 內(nèi)存中的布局情況，理解每條指令在電路中的運(yùn)行邏輯。此時(shí)的計(jì)算機(jī)盡管運(yùn)算速度比人類快，但其內(nèi)部卻沒有什么人所不知道的事情；此時(shí)的軟件開發(fā)并沒有獨(dú)立的“架構(gòu)”可言，軟件架構(gòu)與硬件架構(gòu)是直接物理對(duì)齊的。
隨著計(jì)算機(jī)的快速發(fā)展，直接面向硬件進(jìn)行的軟件開發(fā)很快觸碰到了瓶頸，人腦的生物局限顯然無法跟上機(jī)器算力前進(jìn)的步伐，當(dāng)機(jī)器強(qiáng)大到世界上最聰明的人都無法為它編寫出合適的程序了，那計(jì)算機(jī)科學(xué)還能繼續(xù)發(fā)展嗎？這便是歷史上第一次軟件危機(jī)的根源。
第一次軟件危機(jī)，同時(shí)也是結(jié)構(gòu)化編程發(fā)展的契機(jī)，結(jié)構(gòu)化編程扭轉(zhuǎn)了當(dāng)時(shí)直接面向全局?jǐn)?shù)據(jù)、滿屏 Goto 語句書寫面條式代碼（Spaghetti Code）的編程風(fēng)氣，強(qiáng)調(diào)可獨(dú)立編寫、可重復(fù)利用的子過程 / 局部塊的重要性，讓軟件的每個(gè)局部都能夠設(shè)計(jì)專門的算法和數(shù)據(jù)結(jié)構(gòu)，允許每一位程序員只關(guān)注自己所負(fù)責(zé)的部分，從而在整體上控制住了軟件開發(fā)的復(fù)雜度。此時(shí)，軟件的架構(gòu)才開始獨(dú)立于硬件物理架構(gòu)而存在，軟件業(yè)開始出現(xiàn)把控全局設(shè)計(jì)的架構(gòu)師與聚焦局部實(shí)現(xiàn)的程序員的角色分工。
將軟件從整體劃分成若干個(gè)局部，人類能夠以群體配合來共同開發(fā)軟件，使得人與計(jì)算機(jī)又和諧共處了十余年。不過，機(jī)器的算力膨脹仍然在持續(xù)，人類群體的溝通協(xié)作能力卻終究有極限。人畢竟不是可復(fù)制的程序，每個(gè)人都有自己的理解與認(rèn)知，如何讓各個(gè)模塊能準(zhǔn)確地協(xié)同工作成了一場災(zāi)難，這就是第二次軟件危機(jī)的根源。
《人月神話》中有一個(gè)幾乎每位程序員都聽過的案例：IBM 公司開發(fā) OS/360 系統(tǒng)的投入成本達(dá)到了美國“曼哈頓”原子彈計(jì)劃的 25%，共有 4000 多個(gè)模塊，約 100 萬條指令，超過 5000 人年，耗資數(shù)億美元，即使如此，結(jié)果還是延期交付，在交付使用后的系統(tǒng)中仍發(fā)現(xiàn)大量的缺陷。
渡過第二次軟件危機(jī)的過程中，面向?qū)ο缶幊讨鸩饺〈嗣嫦蜻^程的結(jié)構(gòu)化編程，成為主流的程序設(shè)計(jì)思想。這次思想轉(zhuǎn)變宣告“追求最符合人類思維的視角來抽象問題”取代了“追求最符合機(jī)器運(yùn)行特征的算法與數(shù)據(jù)結(jié)構(gòu)”成為軟件架構(gòu)的最高優(yōu)先級(jí)，并一直持續(xù)沿用至今。這次危機(jī)還直接導(dǎo)致軟件工程的誕生，如何以系統(tǒng)性的、規(guī)范化的、可定量的方法去高質(zhì)量地開發(fā)和維護(hù)軟件成為一門獨(dú)立的科學(xué)。
如果說歷史上的第一、二次軟件危機(jī)分別是機(jī)器算力規(guī)模超過了人類個(gè)體的生理極限，超過了人類群體的溝通極限的話。那么在今天，在云計(jì)算的時(shí)代，數(shù)據(jù)中心所能提供的算力其實(shí)已經(jīng)逼近人類協(xié)作的工程極限。與此算力相符的程序規(guī)模，幾乎也到了無論采用何種工程措施去優(yōu)化過程、無論采用什么管理手段去提升質(zhì)量，都仍然不可避免會(huì)出現(xiàn)意外與異常的程度。
大家都相信只要軟件系統(tǒng)由大量人員共同研發(fā)，并使其分布在云中大量節(jié)點(diǎn)協(xié)同運(yùn)行，隨著項(xiàng)目規(guī)模的增大、時(shí)間變長，就肯定會(huì)有人疏忽犯錯(cuò)，會(huì)有代碼攜帶缺陷，會(huì)有電腦宕機(jī)崩潰，會(huì)有網(wǎng)絡(luò)堵塞中斷，總之，必然會(huì)受到墨菲定律的無情打擊。
軟件架構(gòu)要與硬件算力規(guī)模對(duì)齊，目前用來適配云計(jì)算與分布式的主流架構(gòu)形式是微服務(wù)。微服務(wù)興起之時(shí)，曾涌現(xiàn)出各類文章去總結(jié)、贊美微服務(wù)帶來的種種好處，諸如簡化部署、邏輯拆分更清晰、便于技術(shù)異構(gòu)、易于伸縮拓展應(yīng)對(duì)更高的性能，等等。
這些當(dāng)然都是重要優(yōu)點(diǎn)，可是，如果不拘泥于特定場景的某個(gè)問題，以宏觀的角度來看，前面所列這種種好處都只算是“錦上添花”、是屬于讓系統(tǒng)“更好”的動(dòng)因，肯定比不上如何確保系統(tǒng)的“生存”來得關(guān)鍵。在我看來，從單體到微服務(wù)的最根本的推動(dòng)力，是為了方便某個(gè)服務(wù)能夠順利地“消亡”與“重生”，局部個(gè)體的生死更迭，是關(guān)系到整個(gè)系統(tǒng)能否可靠續(xù)存的關(guān)鍵因素。
舉個(gè)例子，在很長的時(shí)間里面，企業(yè)應(yīng)用中采用單體架構(gòu)的 Java 系統(tǒng)，其更新、升級(jí)都必須要有固定的停機(jī)計(jì)劃，必須在特定的時(shí)間窗口內(nèi)才能按時(shí)開始，必須按時(shí)結(jié)束。如果出現(xiàn)了非計(jì)劃的宕機(jī)，那便是生產(chǎn)事故。但是軟件的缺陷不可能遵循停機(jī)計(jì)劃來“安排時(shí)間出錯(cuò)”，為了應(yīng)對(duì)缺陷與變化，做到不停機(jī)地檢修，Java 曾經(jīng)搞出了 OSGi 和 JVMTI Instrumentation 等復(fù)雜的 HotSwap 方案，以實(shí)現(xiàn)給奔跑中的汽車更換輪胎這種匪夷所思卻又無可奈何的需求。而在微服務(wù)架構(gòu)的視角下，所謂系統(tǒng)檢修，充其量只是一次服務(wù)滾動(dòng)更新而已，灰度部署新的程序版本，然后導(dǎo)流、測(cè)試、發(fā)布即可。
流水不腐，有老朽，有消亡，有重生，有更迭才是生態(tài)運(yùn)行的合理規(guī)律，如何采用不可靠的部件來構(gòu)造出一個(gè)可靠的系統(tǒng)，是軟件架構(gòu)適配云與分布式算力發(fā)展的關(guān)鍵所在。如果系統(tǒng)中局部能擁有獨(dú)立的生命周期，在整體架構(gòu)上有物理隔離的設(shè)計(jì)，那么即便采用了不可靠部件，在系統(tǒng)外觀察，整體上仍然有可能表現(xiàn)出穩(wěn)定健壯的服務(wù)能力。
我們繼續(xù)順著“軟件架構(gòu)的演進(jìn)由人與機(jī)器的矛盾所驅(qū)動(dòng)，逐漸與算力規(guī)模對(duì)齊”這條線索，思考軟件開發(fā)的下一個(gè)核心矛盾將會(huì)是什么？窺探下一個(gè)時(shí)代的軟件架構(gòu)會(huì)具備何種特征？
我認(rèn)為，軟件發(fā)展的下一個(gè)關(guān)鍵矛盾將會(huì)是算力規(guī)模超過人應(yīng)掌握合理知識(shí)的極限。經(jīng)過良好設(shè)計(jì)的分布式系統(tǒng)，擁有局部的可再生性，確實(shí)能在整體上展現(xiàn)出可靠的服務(wù)能力。然而，“良好地設(shè)計(jì)”一個(gè)分布式系統(tǒng)很不容易。今天無限火熱的云原生、微服務(wù)、不可變基礎(chǔ)設(shè)施、彈性計(jì)算、服務(wù)網(wǎng)格、無服務(wù)器架構(gòu)、高低零代碼等等，背后都能展開成一整套成體系的開發(fā)或者設(shè)計(jì)方法。這些新的技術(shù)在為人們解決了更復(fù)雜軟件問題的同時(shí)，也正在把編程這件事情本身的復(fù)雜度推向更高層次。
一名剛剛走出校園的大學(xué)生，要掌握計(jì)算機(jī)與程序執(zhí)行的基本原理，要消化完所用編程語言的核心細(xì)節(jié)，要掌握領(lǐng)域中常用的類庫、框架和工具，要理解分布式系統(tǒng)的服務(wù)彈性、容錯(cuò)、限流等設(shè)計(jì)技巧，要接觸容器、云原生、函數(shù)計(jì)算等運(yùn)行架構(gòu)層面的知識(shí)，耗費(fèi)上十年時(shí)間都絲毫不奇怪。
在哲學(xué)里，有人曾經(jīng)嚴(yán)肅研討過“知識(shí)膨脹”的問題，說的是人類科學(xué)的前沿在不斷拓展，觸及前沿所需的基礎(chǔ)知識(shí)也不斷增加，是否會(huì)陷入后來者終其一生都無法攢下足夠基礎(chǔ)，導(dǎo)致人類知識(shí)陷入止步不前的危機(jī)之中。在計(jì)算機(jī)科學(xué)里就更加現(xiàn)實(shí)了，知識(shí)膨脹直接表現(xiàn)為從畢業(yè)到“35 歲退休”（梗）之前，很多程序員恐怕都很難具備設(shè)計(jì)分布式架構(gòu)所需的全面知識(shí)。
云與分布式時(shí)代，軟件知識(shí)看來又到了該“打個(gè)結(jié)”的時(shí)刻，要設(shè)法把那些重要但普適的知識(shí)標(biāo)準(zhǔn)化并下沉。好比今天除去少數(shù)專門的領(lǐng)域，大多數(shù)程序員已經(jīng)不再需要關(guān)注寄存器、信號(hào)、中斷等與機(jī)器底層的細(xì)節(jié)，也不會(huì)太關(guān)注操作系統(tǒng)內(nèi)存頁 / 段、執(zhí)行調(diào)度器、輸入輸出原理等操作系統(tǒng)底層的細(xì)節(jié)。等云數(shù)據(jù)中心徹底成熟，成為主流的程序部署運(yùn)行環(huán)境后，云與分布式的復(fù)雜細(xì)節(jié)也同樣會(huì)被隱藏起來。
未來軟件如何使用云服務(wù)，現(xiàn)階段還很難有定論，但有跡象表明，軟件中的非功能屬性會(huì)率先被外置出去，而不會(huì)繼續(xù)像現(xiàn)在這樣，在開發(fā)階段鐫刻定型于程序代碼之中。
軟件是以單體還是以分布式運(yùn)行，需要提供怎樣的 SLA，具體與哪些技術(shù)組件進(jìn)行協(xié)作，通訊中是否要容錯(cuò)限流等等，都不必在開發(fā)期就鎖定起來，也不必由業(yè)務(wù)開發(fā)人員去關(guān)注，他們只處理那些承載系統(tǒng)業(yè)務(wù)價(jià)值的功能屬性。
這種外掛式的軟件架構(gòu)風(fēng)格，如同你要上戰(zhàn)場便穿上軍裝，要游泳便穿上泳衣，去舞會(huì)便穿上禮服，不同的裝備讓人能適應(yīng)不同的場景。而那些“可穿戴”的裝備，都是由專業(yè)廠商設(shè)計(jì)，有質(zhì)量保證，不需要每位編寫代碼的程序員都知道它們應(yīng)該如何工作。
正在逐漸成熟的 Service Mesh 就展露出一些這方面的特征。Sidecar 以流量劫持的方式，能夠?yàn)槌绦蜷g的網(wǎng)絡(luò)通訊額外附加上連接穩(wěn)定性（如重試、熔斷）、安全性（如鑒權(quán)、雙向通訊加密）、可管理性和可觀測(cè)性，既不依賴人專門去編碼，也不依賴某款語言或者框架的預(yù)置能力。
不過，Service Mesh 僅僅能滿足與服務(wù)通訊能力相關(guān)的治理，而軟件設(shè)計(jì)所需的能力并不止通訊這一項(xiàng)，開發(fā)者要依賴多種提供不同能力的運(yùn)行時(shí)來搭建軟件，譬如高級(jí)語言虛擬機(jī)提供執(zhí)行能力、消息隊(duì)列提供 Pub/Sub 通知能力、容器編排系統(tǒng)提供生命周期管理能力等等。開發(fā)者使用這些能力時(shí)，也面臨與通訊一樣的治理需求。
ShardingSphere 的作者張亮曾經(jīng)在 InfoQ 撰文，提出過 Database Mesh 的設(shè)想，把數(shù)據(jù)庫發(fā)現(xiàn)、訪問路由、數(shù)據(jù)分片、讀寫分離、負(fù)載均衡等特性從程序代碼中拿出去，也交給 Sidecar 來實(shí)現(xiàn)。既然 Service 和 Database 可以 Mesh 化，那 Cache Mesh、MessageQueue Mesh、Storage Mesh 等自然都有了登場的理由。
更進(jìn)一步，分布式中那些復(fù)雜卻有共性的處理技巧，如并行、并發(fā)、狀態(tài)、共識(shí)等等，是不是也可以從程序代碼中獨(dú)立出去，由 Sidecar 引導(dǎo)至合適的、不特定的部件中妥善處理？最后，一旦云計(jì)算服務(wù)提供商的技術(shù)貨架中大多數(shù)部件和能力被 Mesh 抹掉了差異化特性，剩下都是一致的標(biāo)準(zhǔn)操作，那 Serverless 一直倡導(dǎo)的“后端即服務(wù)”（BaaS）便立刻有了無比廣泛的基礎(chǔ)。此時(shí)，云數(shù)據(jù)中心就仿佛是一部擁有無限算力的機(jī)器與一套有標(biāo)準(zhǔn)接口的操作系統(tǒng)，開發(fā)者無需關(guān)心程序在哪里執(zhí)行（FaaS），也不再關(guān)心程序有哪些依賴（BaaS）。
上面僅談概念恐怕有些抽象，筆者以“如何存儲(chǔ)一個(gè) K/V 值對(duì)”為例，來看一下當(dāng)前的編程與未來設(shè)想的編程方式會(huì)有什么差別。下面這段代碼是現(xiàn)在隨處可見的大路貨，它具有稍后列舉的幾點(diǎn)問題：
首先，這是一段操作 Redis 的代碼，意味著你需要了解 Redis 的知識(shí)，不說實(shí)現(xiàn)原理，起碼要知道它的 API 該如何使用，程序代碼也必須引入 Redis 的客戶端 SDK 作為依賴項(xiàng)。
其次，這是一段可運(yùn)行的 Java 代碼，意味著你需要知道 Redis 的服務(wù)位置（如 Host 地址、端口等）、部署方式（如單點(diǎn)、集群、分片情況等）、鏈接信息（如鑒權(quán)方式、密碼等），這些其實(shí)應(yīng)該是 SRE 而不是 SDE 的職責(zé)。
最后，這是一段在生產(chǎn)環(huán)境容易受到挑戰(zhàn)的代碼，生產(chǎn)可能還需要考慮額外的非功能屬性：要不要啟用連接池？并發(fā)策略是 first-write-wins 還是 last-write-wins ？是否需要支持事務(wù)？數(shù)據(jù)能保證什么級(jí)別的一致性？要批量操作該怎么辦？假若這些非功能屬性都反映到代碼上，結(jié)果肯定要比現(xiàn)在看到的復(fù)雜上不少，其中有一些需求甚至僅憑應(yīng)用代碼是無法解決的。譬如要支持事務(wù)，用 Redis 可以，用 Memcached/Cassandra 就不行；要支持強(qiáng)一致性，用 Etcd/ZooKeeper 可以，用 Redis 就不行。
以上問題，在今天看來其實(shí)都算不上真正的問題，去寫程序就該懂得寫程序的知識(shí)，但是作為一名業(yè)務(wù)開發(fā)人員，目的僅僅是想保存或者讀取一個(gè) K/V 值對(duì)而已，要用 Redis、Etcd、Memcached 或關(guān)系庫作為存儲(chǔ)、要用哪個(gè)云服務(wù)商提供的存儲(chǔ)服務(wù)、要滿足哪些非功能特性，這些本不該屬于操作意圖的一部分，都應(yīng)該被隱藏起來。譬如下面這樣來完成 K/V 值對(duì)的存儲(chǔ)和訪問：
至于為什么會(huì)存在“http://localhost:3500”這樣的服務(wù)地址，后面連接的具體是什么存儲(chǔ)服務(wù)，這些是 Sidecar 而不是業(yè)務(wù)開發(fā)人員需要關(guān)心的事情。不同產(chǎn)品與不同云計(jì)算服務(wù)商之間的差異，被隱藏在相同的操作原語（Primitives）和代表服務(wù)標(biāo)準(zhǔn)含義的接口（如 HTTP URL）之下。這樣云計(jì)算就自然而然地打破了目前各廠商之間和產(chǎn)品之間的隔閡，順利步入到云不可知（Cloud Agnostic）的階段。這便是對(duì)云計(jì)算與分布式架構(gòu)“打個(gè)結(jié)”的具體動(dòng)作。
雖然迄今為止，上述設(shè)想距離現(xiàn)實(shí)還很遙遠(yuǎn)，理論不夠成熟，能在生產(chǎn)環(huán)境中使用的多運(yùn)行時(shí)框架仍處于十分早期階段。譬如上面用于演示的代碼是基于微軟的 DAPR 框架，它在上周才剛剛進(jìn)入 CNCF 孵化。對(duì)這個(gè)演示 DAPR 目前也僅僅能處理 K/V 存儲(chǔ)，其它存儲(chǔ)類型（如更為常用的關(guān)系庫）目前都還完全沒有考慮。
但我愿意相信這是未來架構(gòu)演進(jìn)的一個(gè)主要方向，必須把復(fù)雜的問題盡量關(guān)進(jìn)籠子，由專業(yè)人員去看護(hù)，才能讓普通程序員更好參與軟件開發(fā)，甚至通過低 / 零代碼工具的支持，讓那些沒有太多編程知識(shí)、卻有豐富領(lǐng)域知識(shí)的業(yè)務(wù)專家，也能夠獨(dú)立制造出優(yōu)秀的軟件產(chǎn)品。
第一次軟件危機(jī)在 1950 年代末期初現(xiàn)端倪，結(jié)構(gòu)化編程思想在 1970 年才被正式提出；第二次軟件危機(jī)（連同“軟件危機(jī)”這個(gè)概念）是在 1970 年北約 NATO 會(huì)議上被定義的，要一直到 1990 年代面向?qū)ο蟮脑O(shè)計(jì)方法成為主流，以及 Scrum、XP 等軟件工程方法被提出后，這次危機(jī)才算是畫上句號(hào)。
從 2010 年左右開始興起的云計(jì)算是程序的運(yùn)行環(huán)境繼“大型計(jì)算機(jī)”轉(zhuǎn)變到“客戶端 - 服務(wù)器”之后的又一場巨變。與前兩次軟件危機(jī)帶來的變革契機(jī)一樣，現(xiàn)有的許多軟件架構(gòu)和開發(fā)方法，一定也會(huì)在以十年計(jì)數(shù)單位的時(shí)間段內(nèi)逐漸被顛覆，今天你我所談的云原生、微服務(wù)等話題，僅僅是這次變革浪潮的開端。
與技術(shù)變革相伴的，是它對(duì)行業(yè)以及對(duì)程序員這個(gè)群體的影響。
第一次軟件危機(jī)期間，世界上最聰明的科學(xué)家 / 工程學(xué)家在開發(fā)軟件；第二次軟件危機(jī)期間，社會(huì)中高智商高學(xué)歷的精英群體在開發(fā)軟件；云與分布式的時(shí)代，軟件開發(fā)者恐怕也不可避免會(huì)受到下一輪沖擊。未來的軟件架構(gòu)對(duì)普通程序員應(yīng)該會(huì)是更友善更簡單的，但是對(duì)普通程序員友善與簡單的背后，預(yù)示著未來的信息技術(shù)行業(yè)很可能會(huì)出現(xiàn)“階級(jí)分層”的現(xiàn)象。
由于更先進(jìn)的軟件架構(gòu)已經(jīng)允許更平庸的開發(fā)者也同樣能寫出可運(yùn)行、可用于生產(chǎn)的軟件產(chǎn)品，同時(shí)又對(duì)精英開發(fā)者提出更多、更復(fù)雜的技術(shù)要求。長此以往，在開發(fā)者群體中會(huì)出現(xiàn)比現(xiàn)在還要更顯著的馬太效應(yīng)，迫使開發(fā)者逐漸分層。從如今所有開發(fā)者都普遍被認(rèn)為是“高智商群體”的狀態(tài)，轉(zhuǎn)變?yōu)榇蟛糠止I(yè)化軟件生產(chǎn)工人加上小部分軟件設(shè)計(jì)專家的金字塔結(jié)構(gòu)，就如同現(xiàn)在的建筑工人與建筑設(shè)計(jì)師的關(guān)系一般。今天我們經(jīng)常自嘲的 CRUD Boy，隨著軟件產(chǎn)業(yè)日趨成熟，恐怕還會(huì)真的會(huì)成為現(xiàn)實(shí)。
在本次分享中，我避免使用“第三次軟件危機(jī)”這樣有嘩眾取寵嫌疑的表述，危機(jī)總是與契機(jī)同時(shí)出現(xiàn)，未來的軟件的一定是越來越貼近于普通平民百姓的軟件，但軟件的未來也一定有大量的挑戰(zhàn)與機(jī)會(huì)在等待著優(yōu)秀的程序員與架構(gòu)師去承擔(dān)。
本文來自微信公眾號(hào) “InfoQ”（ID：infoqchina），作者：周志明，編輯：羅燕珊，36氪經(jīng)授權(quán)發(fā)布。
