毫無疑問，云原生技術(shù)已經(jīng)在事實(shí)上成為了大多數(shù)IT系統(tǒng)需要邁向的目標(biāo)，區(qū)別只在于，到底是從一開始就遵循云原生架構(gòu)原則對系統(tǒng)進(jìn)行設(shè)計(jì)，還是演進(jìn)式地從傳統(tǒng)架構(gòu)遷移到云原生架構(gòu)。

了解云原生技術(shù)體系，一些耳熟能詳?shù)募夹g(shù)術(shù)語撲面而來，容器，微服務(wù)，服務(wù)網(wǎng)格(Service Mesh)，包含了FaaS(函數(shù)即服務(wù))和BaaS(后端即服務(wù))的無服務(wù)器(Serverless)模式，都是技術(shù)架構(gòu)常常采用的模式。

分析這些技術(shù)術(shù)語，剖析它們的架構(gòu)思想與落地實(shí)踐，我希望從中窺得幾分端倪，做一次關(guān)于IT系統(tǒng)應(yīng)用開發(fā)的發(fā)展趨勢分析。

1.趨勢一：業(yè)務(wù)與技術(shù)的正交性越來越明顯

云原生架構(gòu)本身就是從技術(shù)角度出發(fā)，遵循云原生架構(gòu)原則和模式，將云應(yīng)用中的非業(yè)務(wù)代碼進(jìn)行最大化剝離，然后將其下沉到云服務(wù)(設(shè)施)平臺，并以無侵略的方式和業(yè)務(wù)“粘合”在一起，共同支撐整個應(yīng)用的運(yùn)行。

設(shè)計(jì)上，為了避免業(yè)務(wù)復(fù)雜度和技術(shù)復(fù)雜度之間的互相干擾，設(shè)計(jì)上本來就需要力求業(yè)務(wù)與技術(shù)的正交性。隨著云原生技術(shù)的逐漸成熟，剝離技術(shù)功能，保留業(yè)務(wù)代碼的純粹性成為可能。在云原生平臺之上，業(yè)務(wù)系統(tǒng)的開發(fā)人員可以將精力放到業(yè)務(wù)領(lǐng)域的設(shè)計(jì)與開發(fā)，忽略運(yùn)行過程中需要賦予系統(tǒng)的技術(shù)能力。

理想狀態(tài)下，新的IT架構(gòu)形態(tài)會形成：

• 設(shè)計(jì)態(tài)與研發(fā)態(tài)：關(guān)注點(diǎn)在于業(yè)務(wù)
• 運(yùn)行態(tài)和運(yùn)營態(tài)：關(guān)注點(diǎn)在于技術(shù)

如此就可能影響整個IT行業(yè)。由專業(yè)的云原生平臺或微服務(wù)平臺軟件供應(yīng)商打造和實(shí)施基于云原生架構(gòu)的技術(shù)平臺，提供基礎(chǔ)設(shè)施服務(wù)，由垂直領(lǐng)域的傳統(tǒng)企業(yè)IT部門與項(xiàng)目型軟件供應(yīng)商負(fù)責(zé)業(yè)務(wù)功能的實(shí)現(xiàn)，共同合作完成企業(yè)IT系統(tǒng)的構(gòu)建，這可能是未來長期存在的IT生態(tài)現(xiàn)象。

開發(fā)人員的角色隨之發(fā)生變化，業(yè)務(wù)型開發(fā)人員與技術(shù)型開發(fā)人員的分工變得越來越明顯，需要的技能存在非常大的差異，前者更看重領(lǐng)域知識、抽象建模能力與設(shè)計(jì)能力，后者更看重底層的關(guān)鍵開發(fā)技術(shù)，掌握如網(wǎng)絡(luò)通信、并行開發(fā)、數(shù)據(jù)一致等通用技術(shù)功能的實(shí)現(xiàn)。

2.趨勢二：業(yè)務(wù)單元的粒度變得無關(guān)緊要

如果保證了業(yè)務(wù)與技術(shù)的正交性，意味著隨著IT技術(shù)的發(fā)展，最終會打通制約軟件開發(fā)的技術(shù)瓶頸。當(dāng)我們可以不用考慮性能和安全，不用擔(dān)心分布式通信的不可靠性，不用考慮分布式事務(wù)該如何保證一致性……業(yè)務(wù)單元的劃分就不再干擾或影響整個應(yīng)用的質(zhì)量屬性(非功能性需求)，反過來，系統(tǒng)的質(zhì)量屬性也不會影響對業(yè)務(wù)單元的劃分。我們完全可以從純業(yè)務(wù)角度出發(fā)定義業(yè)務(wù)單元的粒度。

如果業(yè)務(wù)場景復(fù)雜，又具有獨(dú)立性和特殊性，將其設(shè)計(jì)為一個粗粒度的宏服務(wù)(macro service)也未嘗不可;如果一個業(yè)務(wù)場景只需要系統(tǒng)提供單一的功能，自然可以設(shè)計(jì)為微服務(wù)(micro service)或者迷你服務(wù)(mini service);如果只是對單一數(shù)據(jù)進(jìn)行運(yùn)算或操作，不妨定義為一個云函數(shù)。

顯然，當(dāng)分布式通信等基礎(chǔ)設(shè)施不再成為干擾因素時，各種粒度單元的組合會變得更加自由，一切只為具體的業(yè)務(wù)場景。

3.趨勢三：傳統(tǒng)調(diào)試技術(shù)受到挑戰(zhàn)

在未來的應(yīng)用系統(tǒng)，函數(shù)和事件會成為最主要的業(yè)務(wù)邏輯封裝單元，事件驅(qū)動架構(gòu)風(fēng)格會變得越來越普遍。同時，技術(shù)關(guān)注點(diǎn)主要以代理(Sidecar)形式透明地“粘合”業(yè)務(wù)代碼，使得代碼的執(zhí)行順序不再是順序式的，而是跳躍式的;執(zhí)行的指令也不一定運(yùn)行在同一個進(jìn)程(或線程)。

這就使得本地環(huán)境的開發(fā)調(diào)試變得越來越困難，越來越復(fù)雜，由于模擬技術(shù)無法達(dá)到真實(shí)生產(chǎn)環(huán)境的效果，而業(yè)務(wù)邏輯和技術(shù)邏輯之間的“粘合劑”又非顯式的膠水代碼，使得現(xiàn)有IDE支持的傳統(tǒng)調(diào)試和斷點(diǎn)功能無法滿足云原生時代的要求，至少增加了調(diào)試的成本，進(jìn)而影響開發(fā)效率和開發(fā)質(zhì)量。

為了迎合這一變化，除非能改進(jìn)IDE的調(diào)試功能，在開發(fā)實(shí)踐上應(yīng)更加重視自動化測試，充分利用單元測試驗(yàn)證業(yè)務(wù)功能的正確性，由集成測試負(fù)責(zé)驗(yàn)證業(yè)務(wù)與技術(shù)結(jié)合后形成的完整功能。換言之，開發(fā)團(tuán)隊(duì)?wèi)?yīng)盡可能通過自動化測試而非斷點(diǎn)調(diào)試來發(fā)現(xiàn)問題。

4.趨勢四：由業(yè)務(wù)人員開發(fā)核心業(yè)務(wù)代碼

在分離了業(yè)務(wù)和技術(shù)之后，為了提升業(yè)務(wù)開發(fā)人員的效率，IT公司或部門需要對業(yè)務(wù)代碼開展共性和可變性分析，識別并抽象出約80%業(yè)務(wù)邏輯的共性，將其沉淀為業(yè)務(wù)組件、微服務(wù)或云函數(shù)、甚至低代碼平臺，如此，開發(fā)人員就能將主要精力放在20%的差異化實(shí)現(xiàn)上。

因此，未來的業(yè)務(wù)系統(tǒng)開發(fā)會形成不同復(fù)用粒度和不同復(fù)用目標(biāo)的多層次松耦合架構(gòu)：技術(shù)關(guān)注點(diǎn)作為基礎(chǔ)設(shè)施層，交由云原生平臺形成技術(shù)支撐;組件、服務(wù)或函數(shù)組成的業(yè)務(wù)平臺實(shí)現(xiàn)通用子領(lǐng)域與支撐子領(lǐng)域的所有功能，以及實(shí)現(xiàn)核心子領(lǐng)域的部分功能，并由低代碼平臺搭建(創(chuàng)建)腳手架、服務(wù)模板，完成不同粒度業(yè)務(wù)單元的組裝;最后，在平臺上編寫定制的業(yè)務(wù)代碼以滿足業(yè)務(wù)邏輯的差異性。

由于只需編寫核心的業(yè)務(wù)代碼，DSL(領(lǐng)域特定語言)可能會成為各個垂直領(lǐng)域IT應(yīng)用開發(fā)的首選，并以腳本方式在完成編寫后注入到服務(wù)模板中。DSL風(fēng)格的腳本對于業(yè)務(wù)人員更友好，它會慢慢侵蝕開發(fā)人員的空間。前面所述的業(yè)務(wù)開發(fā)人員要么轉(zhuǎn)變?yōu)闃I(yè)務(wù)人員，要么參與測試和調(diào)試工作，成為質(zhì)量保障團(tuán)隊(duì)的一員。

以上趨勢有宏觀層面，也有微觀層次，不過是我偶然的想到，并非專業(yè)嚴(yán)謹(jǐn)?shù)恼摂?。定有疏漏之處，寫來貽笑大方，只是隨意記錄我的想法罷了，但求讀者不要苛責(zé)太甚。