云原生是怎么樣讓我們失去工作的

本人現(xiàn)在暫時(shí)是無(wú)業(yè)狀態(tài)，所以本文不代表任何雇主觀點(diǎn)。

到了 2021 這個(gè)時(shí)間點(diǎn)，大多數(shù)公司都決定擁抱云原生，但不少程序員對(duì)云原生的理解局限于“原生基于 k8s 的應(yīng)用”。公司只要上云(k8s)了，就是擁抱云原生了。稍微理解多一點(diǎn)的人覺(jué)得除了 k8s，我們只要上了 service mesh，就是擁抱云原生了。

cncf 給云原生的定義其實(shí)非常地龐雜：

云原生技術(shù)有利于各組織在公有云、私有云和混合云等新型動(dòng)態(tài)環(huán)境中，構(gòu)建和運(yùn)行可彈性擴(kuò)展的應(yīng)用。云原生的代表技術(shù)包括容器、服務(wù)網(wǎng)格、微服務(wù)、不可變基礎(chǔ)設(shè)施和聲明式 API。

這些技術(shù)能夠構(gòu)建容錯(cuò)性好、易于管理和便于觀察的松耦合系統(tǒng)。結(jié)合可靠的自動(dòng)化手段，云原生技術(shù)使工程師能夠輕松地對(duì)系統(tǒng)作出頻繁和可預(yù)測(cè)的重大變更。

云原生計(jì)算基金會(huì)（CNCF）致力于培育和維護(hù)一個(gè)廠商中立的開(kāi)源生態(tài)系統(tǒng)，來(lái)推廣云原生技術(shù)。我們通過(guò)將最前沿的模式民主化，讓這些創(chuàng)新為大眾所用。

上面的描述是從 cncf 的 toc 中摘出來(lái)的，應(yīng)該還是比較權(quán)威的。

第一條把后端開(kāi)發(fā)涉及的大部分基礎(chǔ)設(shè)施技術(shù)都囊括進(jìn)來(lái)了。涉及到 docker，service mesh，microservice，k8s 和 yaml 式的聲明 API。

第二條和我們已經(jīng)聽(tīng)到耳朵起繭的敏捷稍微有點(diǎn)關(guān)系，在互聯(lián)網(wǎng)公司工作，即使我們不知道怎么實(shí)現(xiàn)，高內(nèi)聚低耦合自動(dòng)化平臺(tái)化這樣的口號(hào)還是會(huì)喊兩句的，除了系統(tǒng)設(shè)計(jì)層面，這條原則還要求我們要有能夠支持自動(dòng)化交付的平臺(tái)和工具，現(xiàn)在開(kāi)源的 CI/CD 產(chǎn)品非常多，一家公司基于開(kāi)源產(chǎn)品(jenkins, argo 等)來(lái)定制自己的交付流水線并不難，沒(méi)什么可說(shuō)的。

第三條說(shuō)的是廠商中立，也就是在 cncf 內(nèi)部的這些基礎(chǔ)設(shè)施軟件不能像以前那樣搞得用戶各種 vendor-lock 了。有了這條原則，云廠商其實(shí)是很難再像以前一樣通過(guò)特殊的 API 來(lái)綁架用戶了。

三條綜合起來(lái)看，我們?nèi)粘ｉ_(kāi)發(fā)的技術(shù)和工作流程全都在里面，從開(kāi)發(fā)到交付全生命周期。對(duì)于不了解云原生的外行人來(lái)說(shuō)簡(jiǎn)直是究級(jí)迷惑，這幫人到底是想干啥？

在本文中，我們只關(guān)注一條線，就是后端業(yè)務(wù)模塊本身的架構(gòu)變化。

互聯(lián)網(wǎng)應(yīng)用從單體切到微服務(wù)，解決了之前大家擠在一個(gè)倉(cāng)庫(kù)里迭代和上線，導(dǎo)致交付瓶頸的問(wèn)題。服務(wù)拆分之后給基礎(chǔ)設(shè)施帶來(lái)了很多挑戰(zhàn)，所以之前幾乎每家公司都得自己去造服務(wù)框架，監(jiān)控系統(tǒng)，鏈路追蹤，日志收集，日志檢索這些和業(yè)務(wù)沒(méi)什么關(guān)系的系統(tǒng)。

在這個(gè)過(guò)程中也催生了大量的基礎(chǔ)設(shè)施崗位，因?yàn)檫@些需求是每家公司的共性需求，早期大家都是剛剛切換到微服務(wù)架構(gòu)，并不是每個(gè)領(lǐng)域都有好用的開(kāi)源產(chǎn)品。所以只能自己動(dòng)手了。

微服務(wù)的布道師們聲稱(chēng)微服務(wù)拆分之后，大家都是基于 API 或 domain event 的松耦合，我們可以按照領(lǐng)域特性或團(tuán)隊(duì)長(zhǎng)處，隨意切換我們線上服務(wù)的語(yǔ)言(因?yàn)榘凑瘴⒎?wù)的邏輯，每個(gè)服務(wù)的代碼量都不大)。這導(dǎo)致了很多信以為真的公司內(nèi)部使用了多種語(yǔ)言來(lái)編寫(xiě)他們的線上服務(wù)。比如某公司的五種語(yǔ)言八種框架，又比如某公司的 197 種 RPC 框架(這個(gè)不是段子)，都是這個(gè)時(shí)期內(nèi)誕生的荒誕現(xiàn)實(shí)。

舉個(gè)例子，比如我要在業(yè)務(wù)框架里支持一下在 SRE 書(shū)里學(xué)到的重試套路，那么作為一個(gè)框架組的開(kāi)發(fā)人員，我需要用 Go 寫(xiě)一遍，用 Java 寫(xiě)一遍，用 javascript 寫(xiě)一遍，用 C++ 寫(xiě)一遍，用 PHP 寫(xiě)一遍，用 Rust 寫(xiě)一遍，寫(xiě)到猝死。

上面這張圖里的框架功能，要為每一門(mén)公司內(nèi)使用的語(yǔ)言實(shí)現(xiàn)一份。如果碰到了問(wèn)題(比如 tls 的 0day 漏洞)，要去每門(mén)語(yǔ)言里的 SDK 里修一遍。

框架的升級(jí)也是公司內(nèi)的老大難問(wèn)題，據(jù)某公司統(tǒng)計(jì)，因?yàn)槟硞€(gè)基礎(chǔ)庫(kù)頻繁出現(xiàn)漏洞，全年花在框架升級(jí)上的時(shí)間以千小時(shí)計(jì)。

service mesh 在一定程度上解決了這個(gè)問(wèn)題，框架的功能從業(yè)務(wù)進(jìn)程外移到 sidecar 進(jìn)程中，比如 istio 和 envoy/mosn。

service mesh 一般分為控制面(control plane)和數(shù)據(jù)面(data plane)，控制面(istio)負(fù)責(zé)管理與下發(fā)數(shù)據(jù)面需要的各種配置并保證配置信息的一致性；數(shù)據(jù)面(envoy、mosn)負(fù)責(zé)請(qǐng)求的轉(zhuǎn)發(fā)以及穩(wěn)定性有關(guān)的一切。

service mesh 追求對(duì)業(yè)務(wù)的零侵入/低侵入，現(xiàn)在已被不少公司所接受。在使用 service mesh 之后，公司內(nèi)的限流、降級(jí)、熔斷、重試、路由、加密都成為了語(yǔ)言無(wú)關(guān)的標(biāo)準(zhǔn)功能。

因?yàn)?service mesh 的數(shù)據(jù)面是以 sidecar 形式與業(yè)務(wù)在同一個(gè) pod 中的不同 container 工作，所以 mesh 和業(yè)務(wù)可以分開(kāi)升級(jí)。維護(hù) mesh 和維護(hù)一個(gè)自己的項(xiàng)目差不多，走公司內(nèi)的項(xiàng)目升級(jí)流程，幾天就可以完成。

非業(yè)務(wù)功能的下沉，大幅度降低了框架層面的工作量，具體到框架組，公司內(nèi)的框架組就沒(méi)那么多事情可以干了。

當(dāng) sidecar 的形式被廣泛接受后，我們也要留意到不追求對(duì)業(yè)務(wù)模塊低侵入的新思潮，在 2020 年的 multi runtime microservice architecture 中，作者將微服務(wù)的需求提練為 State，Binding，Networking，Lifecycle 四個(gè)方面：

這其中的 Lifecycle 已經(jīng)被 k8s 和 CI/CD 系統(tǒng)全權(quán)接管，Networking 在 service mesh 中已經(jīng)得到了很好的實(shí)踐。后來(lái)的 Dapr 的抽象更進(jìn)一步，把 Binding 和 State 也包括在內(nèi)了。

如果我們?nèi)ラ喿x Dapr 的文檔，會(huì)發(fā)現(xiàn)如果使用 Dapr 的話，無(wú)論是我們存取 MySQL/Redis，還是訂閱發(fā)布消息，抑或是與外部服務(wù)通信。都是以 HTTP 或者 gRPC 的方式來(lái)與其通信：

這種形式的抽象如果被接受，框架開(kāi)發(fā)崗位大概率就直接消失掉了。大公司里需要各種黑科技才能實(shí)現(xiàn)的流量回放功能，在 Dapr 中也只是加幾個(gè) if else 的事情。

如果你看到了這里，我相信你已經(jīng)差不多看明白了。云原生的本質(zhì)其實(shí)是基礎(chǔ)設(shè)施與業(yè)務(wù)的解耦，以及基礎(chǔ)設(shè)施自身的標(biāo)準(zhǔn)化。

如果我們想要學(xué)習(xí)穩(wěn)定性的知識(shí)，現(xiàn)在既不需要去加入一家大公司，也不需要去讀那本著名 Google 的 SRE 書(shū)，很多知識(shí)已經(jīng)在 service mesh 這樣的標(biāo)準(zhǔn)化模塊中實(shí)現(xiàn)了，只要簡(jiǎn)單讀讀代碼就可以搞明白。

作為大公司的工程師，我們可能在一段時(shí)間內(nèi)以自己積累了完善的穩(wěn)定性解決方案為傲，但在云原生被普遍接受后，以往的大部分高可用、高并發(fā)、高擴(kuò)展的知識(shí)可能會(huì)很快地貶值。仔細(xì)地想一想，有人會(huì)因?yàn)樽约耗鼙吵鰳?lè)高的說(shuō)明書(shū)目錄而感到自豪么？

早先的 k8s 的誕生一定程度上抹平了二線公司與一線公司的基礎(chǔ)設(shè)施差距，以低成本的方式讓每家公司都擁有了曾經(jīng)想都不敢想的故障自愈和自動(dòng)擴(kuò)縮容功能。對(duì)于互聯(lián)網(wǎng)公司來(lái)說(shuō)，這已經(jīng)是生產(chǎn)力的一次巨大的進(jìn)步了。但這次進(jìn)步其實(shí)消滅了很多傳統(tǒng)的運(yùn)維崗位，一部分愿意學(xué)習(xí)和寫(xiě)代碼的人后來(lái)轉(zhuǎn)為 SRE，在公司內(nèi)進(jìn)行 k8s 和其它基礎(chǔ)設(shè)施的二次開(kāi)發(fā)工作。但整體崗位數(shù)量一定是減少的。

現(xiàn)如今服務(wù)架構(gòu)的標(biāo)準(zhǔn)化會(huì)進(jìn)一步削減各個(gè)公司的框架開(kāi)發(fā)人員規(guī)模，當(dāng) cncf 內(nèi)每個(gè)領(lǐng)域的頭部軟件都解決了大規(guī)模部署的性能問(wèn)題之后，新進(jìn)場(chǎng)的公司、軟件和相關(guān)開(kāi)發(fā)人員大概就很難有很好的機(jī)會(huì)了。

如果你有其它的想法，歡迎在留言區(qū)討論。