從一個(gè)玩笑說起

如果提起起開發(fā)工程師和測試工程師這兩個(gè)角色，你會(huì)想到什么？相比與開發(fā)和產(chǎn)品之間和諧相處的世紀(jì)難題，開發(fā)和測試之間可能會(huì)相對好一點(diǎn)，但也并不總是那么親密無間，在共同討伐產(chǎn)品需求的時(shí)候兩者可以槍口一致對外，但一旦到了提測和多輪測試的環(huán)節(jié)，一道無形的墻開始在兩者之間豎立。究其原因，是測試希望開發(fā)能夠eat their own dog shit，翻譯成白話就是，你要對你自己寫的代碼質(zhì)量負(fù)責(zé)，我只是輔助你把關(guān)質(zhì)量而已。

于是乎，筆者在百度工作期間，百度的測試為了讓百度的開發(fā)能夠主動(dòng)且高效地eat their own dog shit，測試同學(xué)重新定義了測試的工作，新時(shí)代的測試工作被定位為開發(fā)自動(dòng)化的質(zhì)量檢查和測試工具，并coach開發(fā)同學(xué)熟練使用這些工具來完成質(zhì)量保障工作。這里面蘊(yùn)含的一層意思是，隨著越來越多的自動(dòng)化工具被開發(fā)出來，越來越多的質(zhì)量保障工作會(huì)被自動(dòng)化的完成。聽起來很完美是不是？當(dāng)百度的測試經(jīng)理興奮地面對一堆開發(fā)經(jīng)理宣布這個(gè)宏偉計(jì)劃的時(shí)候，只聽開發(fā)經(jīng)理堆里悠悠地冒出了一個(gè)聲音：那你們還需要那么多測試hc嗎？我只記得，當(dāng)時(shí)那個(gè)測試經(jīng)理的臉色不太好看。

要知道，百度的測試也是從大量的手工黑盒測試開始起步的，即使到了后期大量的測試自動(dòng)化工具被啟用，但測試團(tuán)隊(duì)的人員能力結(jié)構(gòu)里，手工測試還是占據(jù)了大多數(shù)，而越來越多的測試自動(dòng)化帶來的，是對開發(fā)能力的升級(jí)要求，以及同時(shí)對人力資源的降級(jí)需求。

但不可否認(rèn)的是，百度測試做的這個(gè)角色轉(zhuǎn)型，是符合未來質(zhì)量保障的發(fā)展方向的，要知道，隨著業(yè)務(wù)越來越復(fù)雜，且隨著下文所講到的開發(fā)模式變革所帶來的生產(chǎn)力的提升，測試工作量和測試資源之間的矛盾會(huì)越來越尖銳，因此測試自動(dòng)化是必須要發(fā)展的方向，但越來越多的自動(dòng)化帶來的是對測試工程師能力模型和資源需求的強(qiáng)力沖擊。所以，測試自動(dòng)化是測試同學(xué)揮刀自宮的那把刀嗎？

云原生時(shí)代是程序員們更好的時(shí)代嗎

沒有馬云的時(shí)代，只有時(shí)代的馬云。

任何技術(shù)的發(fā)展也正是因?yàn)闀r(shí)代的需求。隨著國家在宏觀政策上對數(shù)字經(jīng)濟(jì)的大力支持，越來越多的企業(yè)開始將數(shù)字化轉(zhuǎn)型或升級(jí)作為提升競爭力的必須手段。而云計(jì)算則是幫助企業(yè)尤其是絕大多數(shù)的中小企業(yè)實(shí)現(xiàn)數(shù)字化轉(zhuǎn)型的有利武器。

因此，為了響應(yīng)時(shí)代的號(hào)召，云計(jì)算也提出了云時(shí)代的軟件架構(gòu)Cloud Native，其目的就是為了讓廣大中小企業(yè)可以實(shí)現(xiàn)最低門檻的上云和用云，為了達(dá)到這個(gè)目標(biāo)，云計(jì)算架構(gòu)開始將越來越多的基礎(chǔ)技術(shù)工作下沉到云基礎(chǔ)設(shè)施，從而讓廣大企業(yè)的開發(fā)人員可以將更多的關(guān)注點(diǎn)聚焦在自身業(yè)務(wù)上，非業(yè)務(wù)的通用技術(shù)能力則交給云基礎(chǔ)設(shè)施來完成，而這也正是云原生（Cloud Native）架構(gòu)的本意。

好了，在云原生時(shí)代，企業(yè)做好業(yè)務(wù)開發(fā)該做的事情，剩下的事情都交給Cloud Native來完成，準(zhǔn)確的說，是交給容器、Service Mesh和k8s等云原生的基礎(chǔ)設(shè)施來完成，我們來看看他們都幫助企業(yè)的開發(fā)者干了些什么？

1. 容器帶來的快速和低成本試錯(cuò)：

容器對于運(yùn)行環(huán)境的極強(qiáng)適應(yīng)性和快速啟動(dòng)的能力，配合云上動(dòng)態(tài)擴(kuò)展的龐大資源規(guī)模，讓云端的容器應(yīng)用可以在短時(shí)間內(nèi)拓展到成千上萬個(gè)實(shí)例。所以，云可以說是容器應(yīng)用的最佳載體，容器應(yīng)用也非常適合在云上運(yùn)行和擴(kuò)展。因此，隨著業(yè)務(wù)服務(wù)被拆分成一個(gè)個(gè)輕量級(jí)的微服務(wù)并以容器的方式快速啟動(dòng)運(yùn)行，極大地提升了業(yè)務(wù)試錯(cuò)的敏捷性。

同時(shí)因?yàn)樵票旧硎嵌嘧鈶舻?，需要運(yùn)行環(huán)境的隔離性，而容器正好能夠提供必要的隔離性，在保障隔離性的同時(shí)也意味著高效地利用了云資源。因此，使用容器可以幫助企業(yè)以更高的資源利用率來使用云上資源，從而降低企業(yè)業(yè)務(wù)試錯(cuò)的成本。

好了，企業(yè)的開發(fā)者們，你們只需要悶頭寫微服務(wù)的業(yè)務(wù)代碼就好了，云來幫你快速部署、啟動(dòng)、運(yùn)行，從而快速探索市場反饋。

2. 不可變基礎(chǔ)設(shè)施所帶來的環(huán)境部署的安全和效率：

傳統(tǒng)的服務(wù)器部署，服務(wù)器會(huì)不斷更新和修改。使用這類基礎(chǔ)設(shè)施的工程師和管理員可以SSH到他們的服務(wù)器，手動(dòng)升級(jí)或降級(jí)軟件包版本，逐個(gè)服務(wù)器調(diào)整配置文件，并直接將新代碼部署到現(xiàn)有服務(wù)器上。換句話說，這些服務(wù)器是可變的；它們可以在創(chuàng)建后進(jìn)行更改。由可變服務(wù)器組成的基礎(chǔ)設(shè)施本身可以稱為可變的、傳統(tǒng)的或手工的；

而k8s所代表的不可變基礎(chǔ)設(shè)施，其中服務(wù)器在部署后永遠(yuǎn)不會(huì)被修改。如果需要以任何方式更新、修復(fù)或修改某些內(nèi)容，就先對公共鏡像進(jìn)行修改，然后用鏡像構(gòu)建新服務(wù)器來替換舊服務(wù)器。經(jīng)過驗(yàn)證后，新服務(wù)器投入使用，舊的服務(wù)器就會(huì)下掉。

不可變基礎(chǔ)設(shè)施的好處是在基礎(chǔ)設(shè)施中有更多的一致性和可靠性，以及更簡單、更可預(yù)測的部署過程。它可以緩解或完全防止可變基礎(chǔ)設(shè)施中常見的問題，如 配置漂移（configuration drift）和 雪花服務(wù)器（snowflake servers）等。

好了，企業(yè)的開發(fā)者們，每次上線部署時(shí)服務(wù)器的各種環(huán)境和版本問題不用擔(dān)心了，上線上通宵的日子不再有，可以有更多的時(shí)間睡覺，以及睡醒后寫業(yè)務(wù)代碼了。

3.聲明式API所帶來的資源管理效率：

聲明式API就是當(dāng)用戶向 k8s 提交了一個(gè) API 對象（資源）的描述之后，k8s 會(huì)負(fù)責(zé)為你保證整個(gè)集群里各項(xiàng)資源的狀態(tài)，都與你的 API 對象描述的需求相一致。更重要的是，這個(gè)保證是一項(xiàng)“無條件的”、“沒有期限”的承諾：對于每個(gè)保存在 etcd 里的 API 對象，k8s 都通過啟動(dòng)一種叫做“控制器模式”（Controller Pattern）的無限循環(huán)，不斷檢查，然后調(diào)諧，最后確保整個(gè)集群的狀態(tài)與這個(gè) API 對象的描述一致。

利用聲明式API，我們可以實(shí)現(xiàn)服務(wù)故障時(shí)候的自動(dòng)恢復(fù)、服務(wù)升級(jí)時(shí)的自動(dòng)滾動(dòng)更新以及服務(wù)遇到瞬時(shí)高峰壓力時(shí)候的自動(dòng)水平擴(kuò)容。

所以，每次服務(wù)升級(jí)、線上故障和業(yè)務(wù)高峰，不用和運(yùn)維一起oncall挑燈夜戰(zhàn)解決問題了，可以有更多時(shí)間思考和寫業(yè)務(wù)代碼了。

4.Service Mesh、k8s和Serverless帶來的分布式服務(wù)開發(fā)革命：

我們來回顧一下開發(fā)業(yè)務(wù)服務(wù)的歷史：

• 早期：服務(wù)在實(shí)現(xiàn)業(yè)務(wù)需求的同時(shí)，為了實(shí)現(xiàn)服務(wù)間 RPC通信，還得實(shí)現(xiàn)一堆諸如序列化/反序列化、路由、負(fù)載均衡、流量控制（熔斷、限流）、容錯(cuò)（超時(shí)、重試、降級(jí)）等功能；
• 微服務(wù)sdk模式時(shí)期：在這個(gè)時(shí)期，開發(fā)者在應(yīng)用層添加一個(gè)胖客戶端，在這個(gè)客戶端中實(shí)現(xiàn)上述各種服務(wù)通信相關(guān)功能。但帶來的問題是：語言綁定、學(xué)習(xí)和維護(hù)時(shí)間成本（開發(fā)時(shí)不透明）和應(yīng)用侵入性（同進(jìn)程）；
• 微服務(wù)service mesh模式時(shí)期：在這個(gè)時(shí)期，SDK客戶端的功能被剝離出來放到Service Mesh的Sidecar中，Sidecar是獨(dú)立進(jìn)程，在Sidecar中實(shí)現(xiàn)sdk的各種功能。其實(shí)就是把更多業(yè)務(wù)無關(guān)的事情下沉到基礎(chǔ)設(shè)施中，業(yè)務(wù)開發(fā)者更多關(guān)注業(yè)務(wù)邏輯開發(fā)，從而解決了sdk模式帶來的問題；

Service Mesh主要是為了解決服務(wù)間網(wǎng)絡(luò)通信的問題，本質(zhì)上是管理服務(wù)通信（代理）。所以，使用Service Mesh的企業(yè)開發(fā)者們不再需要關(guān)注服務(wù)間通訊的問題了。

但分布式服務(wù)面臨的不僅僅是服務(wù)間通訊的問題，因此，甚至在整個(gè)分布式服務(wù)解決方案層面，k8s都希望在基礎(chǔ)設(shè)施層實(shí)現(xiàn)語言無關(guān)的分布式服務(wù)基礎(chǔ)設(shè)施。

我們來看看使用應(yīng)用層解決方案的問題（比如spring cloud）

1. 作為開發(fā)者，需要關(guān)注技術(shù)選型問題，比如決定是使用一個(gè)AP系統(tǒng)（consul, eureka等）還是CP系統(tǒng)（zookeeper, etcd等）；
2. 需要弄清楚如何監(jiān)控和管理這些系統(tǒng)，有學(xué)習(xí)和運(yùn)維成本；
3. 需要為不同語言提供不同版本的客戶端，以方便與服務(wù)注冊發(fā)布中心通信，因?yàn)槿萜髦锌赡苓\(yùn)行的是不同語言的應(yīng)用（Java/Node.js/Go）；

基于以上問題，k8s希望在基礎(chǔ)設(shè)施層面來提供語言無關(guān)的分布式服務(wù)基礎(chǔ)設(shè)施，可以看一下k8s和spring cloud的解決方案對比，如下圖：

好了，企業(yè)開發(fā)者甚至不用做分布式服務(wù)相關(guān)的技術(shù)選型了，更不用擔(dān)心不同的編程語言問題了。

而Serverless則更近一步，所謂“無服務(wù)器”就是想讓用戶感覺不到服務(wù)器的存在，開發(fā)者可以完全專注于業(yè)務(wù)邏輯的編寫，而不再關(guān)心任何基礎(chǔ)設(shè)施，完全屏蔽了計(jì)算資源，是在真正地引導(dǎo)你不再去關(guān)心底層環(huán)境，你只要遵循標(biāo)準(zhǔn)方式來直接編寫業(yè)務(wù)代碼就可以了。你甚至可以把每一個(gè)具有獨(dú)立功能的函數(shù)，來作為一個(gè)單獨(dú)的服務(wù)進(jìn)行部署和運(yùn)行。這也是為什么，在有些云計(jì)算的分類方法下，無服務(wù)器計(jì)算能夠單獨(dú)“開宗立派”，被稱為函數(shù)即服務(wù)（Function-as-a-Service，F(xiàn)aaS）的原因。“無服務(wù)器”計(jì)算，它會(huì)根據(jù)我們的負(fù)載情況，依托云端龐大的規(guī)模自動(dòng)地進(jìn)行支撐和擴(kuò)展，你不需要為云函數(shù)事先劃定資源池。

Severless主要包括兩塊內(nèi)容：后端設(shè)施（Backend）和 函數(shù)（Function）

• 后端設(shè)施：是指數(shù)據(jù)庫、消息隊(duì)列、日志、存儲(chǔ)等這類用于支撐業(yè)務(wù)邏輯運(yùn)行，但本身無業(yè)務(wù)含義的技術(shù)組件，這些后端設(shè)施都運(yùn)行在云中，在無服務(wù)中將它們稱為“后端即服務(wù)”（Backend as a Service，Baas）;
• 函數(shù)：指業(yè)務(wù)邏輯代碼，這里函數(shù)的概念與粒度都已經(jīng)很接近程序編碼角度的函數(shù)了，其區(qū)別是無服務(wù)中的函數(shù)運(yùn)行在云端，不必考慮算力問題，也不必考慮容量規(guī)劃（從技術(shù)角度可以不考慮，從計(jì)費(fèi)角度還是需要掂量一下），在無服務(wù)中將其稱為“函數(shù)即服務(wù)”（Function as a Servcie）

無服務(wù)的愿景是讓開發(fā)者只需要純粹地關(guān)注業(yè)務(wù):

• 不需要考慮技術(shù)組件，后端的技術(shù)組件是現(xiàn)成的，可以直接取用，沒有采購、版權(quán)和選型的煩惱；
• 不需要考慮如何部署，部署過程完全托管到云端，由云端自動(dòng)完成；
• 不需要考慮算力，有整個(gè)數(shù)據(jù)中心支撐，算力可以認(rèn)為是無限的；
• 不需要操心運(yùn)維，維護(hù)系統(tǒng)持續(xù)平穩(wěn)運(yùn)行是云計(jì)算服務(wù)商的責(zé)任而不再是開發(fā)者的責(zé)任;

看到這里，那些一直在企業(yè)里做業(yè)務(wù)開發(fā)的同學(xué)，你們是感到無比興奮還是后脊梁發(fā)涼呢？

Low-Code和Zero-Code是程序員的低糖和無糖可樂

程序員說：讓技術(shù)革新的浪潮來得更猛烈些吧！我不要你以為，我要我以為，我以為非技術(shù)人員應(yīng)該也可以開發(fā)系統(tǒng)，于是，Low-Code和Zero-Code作為程序員最愛的低糖和無糖可樂，被送給了業(yè)務(wù)人員。

Low-Code和Zero-Code都屬于aPaaS,可以把a(bǔ)PaaS理解為PaaS的一種子形式。aPaaS的全稱是application Platform as a Service，即應(yīng)用程序平臺(tái)即服務(wù)。Gartner對其所下的定義是：“這是基于PaaS（平臺(tái)即服務(wù)）的一種解決方案，支持應(yīng)用程序在云端的開發(fā)、部署和運(yùn)行，提供軟件開發(fā)中的基礎(chǔ)工具給用戶，包括數(shù)據(jù)對象、權(quán)限管理、用戶界面等

aPaaS（應(yīng)用程序平臺(tái)即服務(wù)）有以下2個(gè)特征：

1. 提供快速開發(fā)的環(huán)境，用戶在幾個(gè)小時(shí)內(nèi)就能完成應(yīng)用的開發(fā)、測試、部署，并能夠隨時(shí)調(diào)整或更新；
2. 低代碼（low code）或 零代碼（no code），非技術(shù)人員就能完成應(yīng)用開發(fā)；

aPaaS和PaaS都可以完成軟件的開發(fā)和部署，都支持云端訪問，而兩者的差異主要體現(xiàn)在用戶人群和使用環(huán)境不一樣：

1. PaaS包含所有平臺(tái)級(jí)別的服務(wù)，需要技術(shù)人員在本地完成應(yīng)用程序的開發(fā)和數(shù)據(jù)提供，然后部署到PaaS平臺(tái)上，再分發(fā)給用戶使用；
2. aPaaS是PaaS的一種子形式，在aPaaS模式下，非技術(shù)人員可以直接在云端完成應(yīng)用程序的搭建、部署、使用、更新和管理；

好了，業(yè)務(wù)人員都可以拖拖拽拽開發(fā)系統(tǒng)了，甚至將來隨著AIGC能力的越發(fā)成熟，機(jī)器人都可以寫代碼了，企業(yè)里還在一直寫業(yè)務(wù)代碼的開發(fā)者們，你們真的覺得低糖和無糖可樂喝起來快樂嗎？

要等揮刀自宮的刀落下嗎

回想起來是不是很可笑，隨著技術(shù)的不斷發(fā)展和進(jìn)步，聰明的程序員們似乎在舉起刀完成揮刀自宮的壯舉。但其實(shí)這還真賴不了程序員們，這只是技術(shù)發(fā)展的必然而已。我們所能做的，就是快速調(diào)整來適應(yīng)這個(gè)時(shí)代的需要。

在我看來，未來的程序員們，你們可以去向這些方向：

1. 愛寫業(yè)務(wù)代碼的同學(xué)，可以深耕toB的企業(yè)級(jí)軟件賽道，并在這個(gè)賽道深耕行業(yè)領(lǐng)域知識(shí)，成為行業(yè)里的技術(shù)專家，讓行業(yè)經(jīng)驗(yàn)成為你的壁壘；
2. 致力于成為技術(shù)領(lǐng)域?qū)＜业耐瑢W(xué)，去做基礎(chǔ)設(shè)施軟件的開發(fā)吧，去做更有技術(shù)含量和挑戰(zhàn)的事情，而且這也是國家政策大力鼓勵(lì)支持的方向；

同時(shí)，我們也能看到，現(xiàn)階段的Serverless和Low-Code還是有其弊端和局限性的，大家也不必過于恐慌。

比如，對Serverless來說，其“無限算力”的假設(shè)，決定了它必須按照使用量（函數(shù)運(yùn)算時(shí)間和占用的內(nèi)存）計(jì)費(fèi)以控制消耗的算力的規(guī)模，因而函數(shù)不會(huì)一直以活動(dòng)狀態(tài)常駐服務(wù)器，請求到了才會(huì)開始運(yùn)行，這就導(dǎo)致了函數(shù)不便依賴服務(wù)端狀態(tài)、也導(dǎo)致了函數(shù)會(huì)有冷啟動(dòng)時(shí)間，響應(yīng)性能可能不太好。目前無服務(wù)的冷啟動(dòng)過程大概是在數(shù)十到數(shù)百毫秒級(jí)別，對于java這類啟動(dòng)性能差的應(yīng)用，甚至是接近秒的級(jí)別。因此其更擅長短連接、服務(wù)無狀態(tài)、適合事件驅(qū)動(dòng)的場景，不適合具備復(fù)雜業(yè)務(wù)邏輯、依賴服務(wù)端狀態(tài)、響應(yīng)速度要求高、需要長鏈接等特征的場景。

而低代碼類的產(chǎn)品，它們的應(yīng)用場景主要是 B 端中后臺(tái)應(yīng)用的搭建，且能力不是萬能的。舉個(gè)例子，很多低代碼產(chǎn)品頁面控件大概就幾十種，如果你的需求是想超出這些控件，做一些新的更好看的樣式，那低代碼產(chǎn)品就無法滿足。低代碼解決的痛點(diǎn)問題是幫助客戶高效率低成本的實(shí)現(xiàn)業(yè)務(wù)需求，并且一般都是針對中后臺(tái)應(yīng)用。如果你對界面、UI、交互要求很高，那低代碼不一定合適，無可否認(rèn)低代碼是可以替代一些增刪改查的工作。但這不是挺好嗎？難道真的有工程師就喜歡每天在那里重復(fù)寫增刪改查，喜歡別人叫他碼農(nóng)嗎？不應(yīng)該這樣。工程師是藝術(shù)家，是有靈魂的人，大家的志向應(yīng)該是寫更有創(chuàng)造力的代碼，而不是每天浪費(fèi)生命在增刪改查之上。

寫在最后

隨著時(shí)代的發(fā)展，即使程序員們不自己舉刀揮下，時(shí)代的浪花推動(dòng)的技術(shù)發(fā)展，也會(huì)推動(dòng)著程序員技術(shù)能力模型的更新迭代。我們所能做的，就是緊跟時(shí)代發(fā)展的方向，不斷學(xué)習(xí)和提升自身的能力，甚至是革自己的命，才能讓我們不斷屹立于當(dāng)下。

歡迎大家關(guān)注我的微信公眾號(hào)：渝言家，我會(huì)不定期跟大家聊聊代碼、架構(gòu)、技術(shù)管理、行業(yè)和產(chǎn)品等話題。