云原生、Serverless和Low-Code是程序員揮刀自宮的那把刀嗎（云原生 serverless）
從一個玩笑說起
如果提起起開發(fā)工程師和測試工程師這兩個角色，你會想到什么？相比與開發(fā)和產(chǎn)品之間和諧相處的世紀難題，開發(fā)和測試之間可能會相對好一點，但也并不總是那么親密無間，在共同討伐產(chǎn)品需求的時候兩者可以槍口一致對外，但一旦到了提測和多輪測試的環(huán)節(jié)，一道無形的墻開始在兩者之間豎立。究其原因，是測試希望開發(fā)能夠eat their own dog shit，翻譯成白話就是，你要對你自己寫的代碼質量負責，我只是輔助你把關質量而已。
于是乎，筆者在百度工作期間，百度的測試為了讓百度的開發(fā)能夠主動且高效地eat their own dog shit，測試同學重新定義了測試的工作，新時代的測試工作被定位為開發(fā)自動化的質量檢查和測試工具，并coach開發(fā)同學熟練使用這些工具來完成質量保障工作。這里面蘊含的一層意思是，隨著越來越多的自動化工具被開發(fā)出來，越來越多的質量保障工作會被自動化的完成。聽起來很完美是不是？當百度的測試經(jīng)理興奮地面對一堆開發(fā)經(jīng)理宣布這個宏偉計劃的時候，只聽開發(fā)經(jīng)理堆里悠悠地冒出了一個聲音：那你們還需要那么多測試hc嗎？我只記得，當時那個測試經(jīng)理的臉色不太好看。
要知道，百度的測試也是從大量的手工黑盒測試開始起步的，即使到了后期大量的測試自動化工具被啟用，但測試團隊的人員能力結構里，手工測試還是占據(jù)了大多數(shù)，而越來越多的測試自動化帶來的，是對開發(fā)能力的升級要求，以及同時對人力資源的降級需求。
但不可否認的是，百度測試做的這個角色轉型，是符合未來質量保障的發(fā)展方向的，要知道，隨著業(yè)務越來越復雜，且隨著下文所講到的開發(fā)模式變革所帶來的生產(chǎn)力的提升，測試工作量和測試資源之間的矛盾會越來越尖銳，因此測試自動化是必須要發(fā)展的方向，但越來越多的自動化帶來的是對測試工程師能力模型和資源需求的強力沖擊。所以，測試自動化是測試同學揮刀自宮的那把刀嗎？
云原生時代是程序員們更好的時代嗎
沒有馬云的時代，只有時代的馬云。
任何技術的發(fā)展也正是因為時代的需求。隨著國家在宏觀政策上對數(shù)字經(jīng)濟的大力支持，越來越多的企業(yè)開始將數(shù)字化轉型或升級作為提升競爭力的必須手段。而云計算則是幫助企業(yè)尤其是絕大多數(shù)的中小企業(yè)實現(xiàn)數(shù)字化轉型的有利武器。
因此，為了響應時代的號召，云計算也提出了云時代的軟件架構Cloud Native，其目的就是為了讓廣大中小企業(yè)可以實現(xiàn)最低門檻的上云和用云，為了達到這個目標，云計算架構開始將越來越多的基礎技術工作下沉到云基礎設施，從而讓廣大企業(yè)的開發(fā)人員可以將更多的關注點聚焦在自身業(yè)務上，非業(yè)務的通用技術能力則交給云基礎設施來完成，而這也正是云原生（Cloud Native）架構的本意。
好了，在云原生時代，企業(yè)做好業(yè)務開發(fā)該做的事情，剩下的事情都交給Cloud Native來完成，準確的說，是交給容器、Service Mesh和k8s等云原生的基礎設施來完成，我們來看看他們都幫助企業(yè)的開發(fā)者干了些什么？
- 容器帶來的快速和低成本試錯：
容器對于運行環(huán)境的極強適應性和快速啟動的能力，配合云上動態(tài)擴展的龐大資源規(guī)模，讓云端的容器應用可以在短時間內拓展到成千上萬個實例。所以，云可以說是容器應用的最佳載體，容器應用也非常適合在云上運行和擴展。因此，隨著業(yè)務服務被拆分成一個個輕量級的微服務并以容器的方式快速啟動運行，極大地提升了業(yè)務試錯的敏捷性。
同時因為云本身是多租戶的，需要運行環(huán)境的隔離性，而容器正好能夠提供必要的隔離性，在保障隔離性的同時也意味著高效地利用了云資源。因此，使用容器可以幫助企業(yè)以更高的資源利用率來使用云上資源，從而降低企業(yè)業(yè)務試錯的成本。
好了，企業(yè)的開發(fā)者們，你們只需要悶頭寫微服務的業(yè)務代碼就好了，云來幫你快速部署、啟動、運行，從而快速探索市場反饋。
2. 不可變基礎設施所帶來的環(huán)境部署的安全和效率：
傳統(tǒng)的服務器部署，服務器會不斷更新和修改。使用這類基礎設施的工程師和管理員可以SSH到他們的服務器，手動升級或降級軟件包版本，逐個服務器調整配置文件，并直接將新代碼部署到現(xiàn)有服務器上。換句話說，這些服務器是可變的；它們可以在創(chuàng)建后進行更改。由可變服務器組成的基礎設施本身可以稱為可變的、傳統(tǒng)的或手工的；
而k8s所代表的不可變基礎設施，其中服務器在部署后永遠不會被修改。如果需要以任何方式更新、修復或修改某些內容，就先對公共鏡像進行修改，然后用鏡像構建新服務器來替換舊服務器。經(jīng)過驗證后，新服務器投入使用，舊的服務器就會下掉。
不可變基礎設施的好處是在基礎設施中有更多的一致性和可靠性，以及更簡單、更可預測的部署過程。它可以緩解或完全防止可變基礎設施中常見的問題，如 配置漂移（configuration drift）和 雪花服務器（snowflake servers）等。
好了，企業(yè)的開發(fā)者們，每次上線部署時服務器的各種環(huán)境和版本問題不用擔心了，上線上通宵的日子不再有，可以有更多的時間睡覺，以及睡醒后寫業(yè)務代碼了。
3.聲明式API所帶來的資源管理效率：
聲明式API就是當用戶向 k8s 提交了一個 API 對象（資源）的描述之后，k8s 會負責為你保證整個集群里各項資源的狀態(tài)，都與你的 API 對象描述的需求相一致。更重要的是，這個保證是一項“無條件的”、“沒有期限”的承諾：對于每個保存在 etcd 里的 API 對象，k8s 都通過啟動一種叫做“控制器模式”（Controller Pattern）的無限循環(huán)，不斷檢查，然后調諧，最后確保整個集群的狀態(tài)與這個 API 對象的描述一致。
利用聲明式API，我們可以實現(xiàn)服務故障時候的自動恢復、服務升級時的自動滾動更新以及服務遇到瞬時高峰壓力時候的自動水平擴容。
所以，每次服務升級、線上故障和業(yè)務高峰，不用和運維一起oncall挑燈夜戰(zhàn)解決問題了，可以有更多時間思考和寫業(yè)務代碼了。
4.Service Mesh、k8s和Serverless帶來的分布式服務開發(fā)革命：
我們來回顧一下開發(fā)業(yè)務服務的歷史：
- 早期：服務在實現(xiàn)業(yè)務需求的同時，為了實現(xiàn)服務間 RPC通信，還得實現(xiàn)一堆諸如序列化/反序列化、路由、負載均衡、流量控制（熔斷、限流）、容錯（超時、重試、降級）等功能；
- 微服務sdk模式時期：在這個時期，開發(fā)者在應用層添加一個胖客戶端，在這個客戶端中實現(xiàn)上述各種服務通信相關功能。但帶來的問題是：語言綁定、學習和維護時間成本（開發(fā)時不透明）和應用侵入性（同進程）；
- 微服務service mesh模式時期：在這個時期，SDK客戶端的功能被剝離出來放到Service Mesh的Sidecar中，Sidecar是獨立進程，在Sidecar中實現(xiàn)sdk的各種功能。其實就是把更多業(yè)務無關的事情下沉到基礎設施中，業(yè)務開發(fā)者更多關注業(yè)務邏輯開發(fā)，從而解決了sdk模式帶來的問題；
Service Mesh主要是為了解決服務間網(wǎng)絡通信的問題，本質上是管理服務通信（代理）。所以，使用Service Mesh的企業(yè)開發(fā)者們不再需要關注服務間通訊的問題了。
但分布式服務面臨的不僅僅是服務間通訊的問題，因此，甚至在整個分布式服務解決方案層面，k8s都希望在基礎設施層實現(xiàn)語言無關的分布式服務基礎設施。
我們來看看使用應用層解決方案的問題（比如spring cloud）
- 作為開發(fā)者，需要關注技術選型問題，比如決定是使用一個AP系統(tǒng)（consul, eureka等）還是CP系統(tǒng)（zookeeper, etcd等）；
- 需要弄清楚如何監(jiān)控和管理這些系統(tǒng)，有學習和運維成本；
- 需要為不同語言提供不同版本的客戶端，以方便與服務注冊發(fā)布中心通信，因為容器中可能運行的是不同語言的應用（Java/Node.js/Go）；
基于以上問題，k8s希望在基礎設施層面來提供語言無關的分布式服務基礎設施，可以看一下k8s和spring cloud的解決方案對比，如下圖：
好了，企業(yè)開發(fā)者甚至不用做分布式服務相關的技術選型了，更不用擔心不同的編程語言問題了。
而Serverless則更近一步，所謂“無服務器”就是想讓用戶感覺不到服務器的存在，開發(fā)者可以完全專注于業(yè)務邏輯的編寫，而不再關心任何基礎設施，完全屏蔽了計算資源，是在真正地引導你不再去關心底層環(huán)境，你只要遵循標準方式來直接編寫業(yè)務代碼就可以了。你甚至可以把每一個具有獨立功能的函數(shù)，來作為一個單獨的服務進行部署和運行。這也是為什么，在有些云計算的分類方法下，無服務器計算能夠單獨“開宗立派”，被稱為函數(shù)即服務（Function-as-a-Service，F(xiàn)aaS）的原因?！盁o服務器”計算，它會根據(jù)我們的負載情況，依托云端龐大的規(guī)模自動地進行支撐和擴展，你不需要為云函數(shù)事先劃定資源池。
Severless主要包括兩塊內容：后端設施（Backend）和 函數(shù)（Function）
- 后端設施：是指數(shù)據(jù)庫、消息隊列、日志、存儲等這類用于支撐業(yè)務邏輯運行，但本身無業(yè)務含義的技術組件，這些后端設施都運行在云中，在無服務中將它們稱為“后端即服務”（Backend as a Service，Baas）;
- 函數(shù)：指業(yè)務邏輯代碼，這里函數(shù)的概念與粒度都已經(jīng)很接近程序編碼角度的函數(shù)了，其區(qū)別是無服務中的函數(shù)運行在云端，不必考慮算力問題，也不必考慮容量規(guī)劃（從技術角度可以不考慮，從計費角度還是需要掂量一下），在無服務中將其稱為“函數(shù)即服務”（Function as a Servcie）
無服務的愿景是讓開發(fā)者只需要純粹地關注業(yè)務:
- 不需要考慮技術組件，后端的技術組件是現(xiàn)成的，可以直接取用，沒有采購、版權和選型的煩惱；
- 不需要考慮如何部署，部署過程完全托管到云端，由云端自動完成；
- 不需要考慮算力，有整個數(shù)據(jù)中心支撐，算力可以認為是無限的；
- 不需要操心運維，維護系統(tǒng)持續(xù)平穩(wěn)運行是云計算服務商的責任而不再是開發(fā)者的責任;
看到這里，那些一直在企業(yè)里做業(yè)務開發(fā)的同學，你們是感到無比興奮還是后脊梁發(fā)涼呢？
Low-Code和Zero-Code是程序員的低糖和無糖可樂
程序員說：讓技術革新的浪潮來得更猛烈些吧！我不要你以為，我要我以為，我以為非技術人員應該也可以開發(fā)系統(tǒng)，于是，Low-Code和Zero-Code作為程序員最愛的低糖和無糖可樂，被送給了業(yè)務人員。
Low-Code和Zero-Code都屬于aPaaS,可以把aPaaS理解為PaaS的一種子形式。aPaaS的全稱是application Platform as a Service，即應用程序平臺即服務。Gartner對其所下的定義是：“這是基于PaaS（平臺即服務）的一種解決方案，支持應用程序在云端的開發(fā)、部署和運行，提供軟件開發(fā)中的基礎工具給用戶，包括數(shù)據(jù)對象、權限管理、用戶界面等
aPaaS（應用程序平臺即服務）有以下2個特征：
- 提供快速開發(fā)的環(huán)境，用戶在幾個小時內就能完成應用的開發(fā)、測試、部署，并能夠隨時調整或更新；
- 低代碼（low code）或 零代碼（no code），非技術人員就能完成應用開發(fā)；
aPaaS和PaaS都可以完成軟件的開發(fā)和部署，都支持云端訪問，而兩者的差異主要體現(xiàn)在用戶人群和使用環(huán)境不一樣：
- PaaS包含所有平臺級別的服務，需要技術人員在本地完成應用程序的開發(fā)和數(shù)據(jù)提供，然后部署到PaaS平臺上，再分發(fā)給用戶使用；
- aPaaS是PaaS的一種子形式，在aPaaS模式下，非技術人員可以直接在云端完成應用程序的搭建、部署、使用、更新和管理；
好了，業(yè)務人員都可以拖拖拽拽開發(fā)系統(tǒng)了，甚至將來隨著AIGC能力的越發(fā)成熟，機器人都可以寫代碼了，企業(yè)里還在一直寫業(yè)務代碼的開發(fā)者們，你們真的覺得低糖和無糖可樂喝起來快樂嗎？
要等揮刀自宮的刀落下嗎
回想起來是不是很可笑，隨著技術的不斷發(fā)展和進步，聰明的程序員們似乎在舉起刀完成揮刀自宮的壯舉。但其實這還真賴不了程序員們，這只是技術發(fā)展的必然而已。我們所能做的，就是快速調整來適應這個時代的需要。
在我看來，未來的程序員們，你們可以去向這些方向：
- 愛寫業(yè)務代碼的同學，可以深耕toB的企業(yè)級軟件賽道，并在這個賽道深耕行業(yè)領域知識，成為行業(yè)里的技術專家，讓行業(yè)經(jīng)驗成為你的壁壘；
- 致力于成為技術領域專家的同學，去做基礎設施軟件的開發(fā)吧，去做更有技術含量和挑戰(zhàn)的事情，而且這也是國家政策大力鼓勵支持的方向；
同時，我們也能看到，現(xiàn)階段的Serverless和Low-Code還是有其弊端和局限性的，大家也不必過于恐慌。
比如，對Serverless來說，其“無限算力”的假設，決定了它必須按照使用量（函數(shù)運算時間和占用的內存）計費以控制消耗的算力的規(guī)模，因而函數(shù)不會一直以活動狀態(tài)常駐服務器，請求到了才會開始運行，這就導致了函數(shù)不便依賴服務端狀態(tài)、也導致了函數(shù)會有冷啟動時間，響應性能可能不太好。目前無服務的冷啟動過程大概是在數(shù)十到數(shù)百毫秒級別，對于java這類啟動性能差的應用，甚至是接近秒的級別。因此其更擅長短連接、服務無狀態(tài)、適合事件驅動的場景，不適合具備復雜業(yè)務邏輯、依賴服務端狀態(tài)、響應速度要求高、需要長鏈接等特征的場景。
而低代碼類的產(chǎn)品，它們的應用場景主要是 B 端中后臺應用的搭建，且能力不是萬能的。舉個例子，很多低代碼產(chǎn)品頁面控件大概就幾十種，如果你的需求是想超出這些控件，做一些新的更好看的樣式，那低代碼產(chǎn)品就無法滿足。低代碼解決的痛點問題是幫助客戶高效率低成本的實現(xiàn)業(yè)務需求，并且一般都是針對中后臺應用。如果你對界面、UI、交互要求很高，那低代碼不一定合適，無可否認低代碼是可以替代一些增刪改查的工作。但這不是挺好嗎？難道真的有工程師就喜歡每天在那里重復寫增刪改查，喜歡別人叫他碼農(nóng)嗎？不應該這樣。工程師是藝術家，是有靈魂的人，大家的志向應該是寫更有創(chuàng)造力的代碼，而不是每天浪費生命在增刪改查之上。
寫在最后
隨著時代的發(fā)展，即使程序員們不自己舉刀揮下，時代的浪花推動的技術發(fā)展，也會推動著程序員技術能力模型的更新迭代。我們所能做的，就是緊跟時代發(fā)展的方向，不斷學習和提升自身的能力，甚至是革自己的命，才能讓我們不斷屹立于當下。
歡迎大家關注我的微信公眾號：渝言家，我會不定期跟大家聊聊代碼、架構、技術管理、行業(yè)和產(chǎn)品等話題。
