毫無疑問，云原生技術已經在事實上成為了大多數IT系統需要邁向的目標，區別只在于，到底是從一開始就遵循云原生架構原則對系統進行設計，還是演進式地從傳統架構遷移到云原生架構。

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

分析這些技術術語，剖析它們的架構思想與落地實踐，我希望從中窺得幾分端倪，做一次關于IT系統應用開發的發展趨勢分析。

1.趨勢一：業務與技術的正交性越來越明顯

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

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

理想狀態下，新的IT架構形態會形成：

• 設計態與研發態：關注點在于業務
• 運行態和運營態：關注點在于技術

如此就可能影響整個IT行業。由專業的云原生平臺或微服務平臺軟件供應商打造和實施基于云原生架構的技術平臺，提供基礎設施服務，由垂直領域的傳統企業IT部門與項目型軟件供應商負責業務功能的實現，共同合作完成企業IT系統的構建，這可能是未來長期存在的IT生態現象。

開發人員的角色隨之發生變化，業務型開發人員與技術型開發人員的分工變得越來越明顯，需要的技能存在非常大的差異，前者更看重領域知識、抽象建模能力與設計能力，后者更看重底層的關鍵開發技術，掌握如網絡通信、并行開發、數據一致等通用技術功能的實現。

2.趨勢二：業務單元的粒度變得無關緊要

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

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

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

3.趨勢三：傳統調試技術受到挑戰

在未來的應用系統，函數和事件會成為最主要的業務邏輯封裝單元，事件驅動架構風格會變得越來越普遍。同時，技術關注點主要以代理(Sidecar)形式透明地“粘合”業務代碼，使得代碼的執行順序不再是順序式的，而是跳躍式的;執行的指令也不一定運行在同一個進程(或線程)。

這就使得本地環境的開發調試變得越來越困難，越來越復雜，由于模擬技術無法達到真實生產環境的效果，而業務邏輯和技術邏輯之間的“粘合劑”又非顯式的膠水代碼，使得現有IDE支持的傳統調試和斷點功能無法滿足云原生時代的要求，至少增加了調試的成本，進而影響開發效率和開發質量。

為了迎合這一變化，除非能改進IDE的調試功能，在開發實踐上應更加重視自動化測試，充分利用單元測試驗證業務功能的正確性，由集成測試負責驗證業務與技術結合后形成的完整功能。換言之，開發團隊應盡可能通過自動化測試而非斷點調試來發現問題。

4.趨勢四：由業務人員開發核心業務代碼

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

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

由于只需編寫核心的業務代碼，DSL(領域特定語言)可能會成為各個垂直領域IT應用開發的首選，并以腳本方式在完成編寫后注入到服務模板中。DSL風格的腳本對于業務人員更友好，它會慢慢侵蝕開發人員的空間。前面所述的業務開發人員要么轉變為業務人員，要么參與測試和調試工作，成為質量保障團隊的一員。

以上趨勢有宏觀層面，也有微觀層次，不過是我偶然的想到，并非專業嚴謹的論斷。定有疏漏之處，寫來貽笑大方，只是隨意記錄我的想法罷了，但求讀者不要苛責太甚。