作者：遠岩，進階開發工程師。2019年畢業加入阿裡巴巴，主要負責 CBU APP 端前台場景工程體系及服務端 Serverless 化建設。
前言
CBU作為集團内最早成立的幾個BU之一，有着多年豐富的業務沉澱，而CBU的技術也伴随着業務一起不斷地演進和成長着。從PC時代的WebX到如今的Serverless，CBU的研發體系經曆了多次變革，在不同的階段中有着不同的特點。筆者所在的團隊近年來一直在負責前台場景研發體系更新相關的工作，在這期間也對過往模式的演變進行了大量的回顧和分析，希望能夠通過本文對過去十年中CBU在研發方式和技術架構上的嘗試和探索做一個簡要的回顧和總結，重新審視我們所走過的路，同時也對未來的方向做一些探讨和展望。
青銅時代（2010～2013）
10年前的網際網路，移動終端還沒有興起，絕大多數的産品都是為PC使用者所服務的。在這種背景下，采用B/S結構是一種毋庸置疑的選擇，是以當我們回顧這個時代的技術時，最先能想到的自然是那些和WEB、浏覽器關系最密切的關鍵詞：比如WebX、jQuery、Velocity等等。
在這個階段，業務流量并不巨大，系統的性能瓶頸基本集中在資料庫的讀寫上，大部分的應用仍然采用單體式的架構，從前台頁面到背景邏輯都封裝在同一個應用中，而在應用内部，往往是采用MVC的分層思想對不同功能的子產品進行劃分。彼時CBU的前台應用架構也基本是這個思路，頁面通過Velocity模闆進行開發，背景業務邏輯則封裝成應用中單例的Service實作，中間通過一個類似Controller的粘合層進行連接配接，将後端的資料字段轉換成前端模版中所使用的變量：
這種模式的優點是，由于所有的子產品都在同一個應用中，非常便于集中管理，當一個開發同學非常熟悉整個應用結構時，他便可以非常快速地完成一整個需求的開發。但缺點也同樣明顯：随着業務的發展，前台邏輯變得越來越複雜，需求必須要拆解成前後端分離的方式，讓專人做專事，而前台代碼被耦合在應用中，使得前後端分離開發變得異常困難；除此之外，前台邏輯的變化往往是非常頻繁的，如果每次修改一個頁面元素都要釋出整個應用，不僅研發效率會十分低下，還會影響線上業務的穩定性。
為了解決上述問題，當時CBU的同學們充分利用了Java的動态類加載機制以及Groovy腳本語言，以一種特殊的方式實作了前後端分離開發和快速疊代，這裡我們以商品詳情場景為例解釋一下其機制和原理。
首先，一張頁面被拆分成若幹個元件，每個元件都會對應一個bundle，這個bundle中包含了前台的vm模闆，js代碼，以及一個Groovy腳本。在實際研發時，需要先通過一個映射表達式聲明該元件所需要消費的背景模型或字段，然後通過Groovy腳本（相當于Controller層）将其轉換為vm模闆中的變量，接着便可以開發前台的vm模闆和js邏輯。開發完畢後，通過一個定制的釋出系統，便可以把對應的bundle釋出到前台應用中，由應用内部的JVM動态加載Groovy腳本以及vm模闆，完成需求功能的上線。下圖便是一個使用這套研發體系開發需求的實際例子：
這套研發體系通過JVM動态加載的能力，将面向前台的View層和Controller層邏輯抽離出來，使其能夠進行獨立開發和動态釋出，進而實作了前背景邏輯之間的解耦，提升研發效率。隻要背景邏輯沒有大的變更，很多需求都可以通過bundle快速開發上線。不過在實際運作時，所有的邏輯仍然是在同一個應用中執行的，這在一定程度上會帶來一些安全隐患。除此之外，這套研發體系也是非常定制化的，bundle的釋出系統實作非常沉重，并且對應的前台應用有強綁定關系，這就意味着很難将它快速地複制到另一個業務場景中複用（CBU最終隻有商品和店鋪兩個業務落地了類似的模式）。
盡管存在着一定的問題，但即便以現在的眼光來審視，也不得不承認這套研發體系有着非常超前的設計思路。尤其是通過引入bundle這一概念，使業務疊代開發變得十分聚焦。在本文的後續章節中我們會看到這一思路最終将伴随着雲原生技術革命，再一次回到我們的視野當中。
蒸汽時代（2014～2018）
這一階段，網際網路行業的形态發生了非常巨大的變化。随着智能手機的流行和普及，移動網際網路迅速崛起，各種各樣的業務都開始向移動端發力。集團發動ALL IN無線的戰役，大量的業務和産品需要快速向移動端遷移。同時，随着智能手機市場的不斷下沉，加上其“随時随地”都能使用的特性，網際網路業務此時所需要應對的流量挑戰和PC時代将不再是同一個數量級。
在技術側我們也能看到與上述現象所比對的變革。一方面，由于流量的激增和系統複雜度的增加，傳統的單體式應用無法再支撐業務的發展，随着Docker這一關鍵技術的出現，服務端應用的分布式拆分和微服務化成為不可阻擋的趨勢。另一方面，由于移動端崛起，前台展示突破了PC鍵鼠互動以及浏覽器能力的限制，使用者對于産品體驗和互動的要求勢必會變得更高，這促使研發人員進一步細分化為負責底層業務邏輯的服務端研發和負責前台展現互動的前端、用戶端研發：React的出現敲響了傳統WEB技術的喪鐘，開發獨立APP成為拓展業務的不二選擇，前端技術和用戶端技術在這一階段開始飛速發展。
這樣的背景下，單體式應用和MVC架構逐漸死去，前後端分離的架構模式和Restful API登上曆史舞台，每個細分領域的技術棧都在飛速成長，大型軟體的開發流程從此将會面對更加複雜的協作和研發模式。
回到CBU本身，這一階段技術上最重要的任務就是将原本PC上的業務快速地遷移到無線終端上去，是以成立了專門的無線團隊，開始重點打造手機阿裡APP。整體思路非常簡單明了，原有的業務體系和邏輯保持不變，進行微服務化改造，以RPC形式對外提供核心業務能力；架構上增設無線服務層，面向APP進行業務邏輯的适配和封裝，通過集團統一對外網關提供Restful API給用戶端及前端開發人員使用。這樣就可以在基本不影響已有業務體系的條件下，讓APP上的業務快速跑起來。無線服務端在這裡所扮演的角色非常類似MVC架構模式中的Controller層：通過RPC與底層基礎業務互動，然後疊加面向無線側的特殊業務邏輯，最終對資料結構進行一定的處理和封裝，通過集團對外的無線網關透出給前台用戶端使用：
在此模式下，無線服務端和用戶端研發人員扮演着十分重要的角色，他們的研發和協作模式将最終決定APP的疊代速度以及品質。接踵而至的新挑戰催促着CBU的工程師們對已有的研發體系進行全面的更新，而最終他們給出了十分精彩的答案：輕服務和場景搭建兩大技術應運而生，接下來我們會看到，這兩者結合所産生的奇妙化學反應，将會給前台場景的研發模式帶來一次重大的突破。
輕服務平台
如上文所述，在ALL IN 無線的時代，無線服務端的研發同學們需要在已有的基礎業務接口上進行大量的改造和封裝，為無線APP端提供服務接口。而在微服務架構下，服務端要對外透出接口，一般需要在應用内編寫RPC服務，然後通過集團的無線網關将對應的RPC服務暴露成集團APP可以調用的HTTP接口：這種方式下一個服務從開發到上線往往需要數天時間。而為了保證用戶端功能的快速疊代，避免業務受到發版節奏的影響，很多簡單邏輯往往會被上行至服務端處理，這就對無線服務端的疊代速度和靈活性提出了一個非常高的要求。既有的技術生産力不能滿足業務訴求，那就勢必要進行創新，于是便誕生了能夠支撐快速靈活開發的輕服務平台，代号為MBOX。以今天的視角來看，這一平台踐行的便是當下非常火熱的Serverless理念，并為服務端同學提供了FaaS（Function as a Service，函數即服務）的能力。
MBOX平台依然采用了動态類加載機制來實作代碼的熱更新，并結合位元組碼技術提供了一個JVM内的“安全容器”，把Java語言的動态化特性運用到了極緻，其架構理念和實作原理如下圖所示：
通過配套的研發平台和釋出系統，開發者可以将自己編寫的一個類動态加載進線上應用的MBOX容器中，并建立一個單例對象；各種常見中間件如RPC和緩存能力，都可以通過注解進行聲明注入并使用；而服務一經釋出，便可以通過指定的Gateway通路到。這種無需配置、開箱即用、快速上線的輕服務疊代方式，非常适用于當時無線服務端所面對的開發場景：對現有的業務RPC服務進行組合編排，再加上一些面向APP端的簡單處理邏輯，使用MBOX便可以在幾小時内完成從開發到上線的整個流程，生産力得到了極大的提升。
場景搭建
早在PC時代CBU就已經建設了頁面搭建相關的技術産品，而在無線端，這一命題實作起來卻要複雜許多。首先，用戶端的頁面并非像前端一樣，由标準的浏覽器所承載，iOS和Andorid雙端從底層的系統機制到上層的元件實作都完全不同，要想實作統一的頁面搭建，勢必需要抹平這層差異。其次，場景搭建并不是簡單的堆砌元件，還需要考慮每個元件背後的資料源：來自各種應用的服務接口必須群組件解耦，而不能在元件内部通過Native邏輯實作，否則将會導緻元件完全喪失複用性，并且使業務疊代更加依賴發版。
為解決上述問題，各端的工程師付出了諸多努力。首先是制定多端差異的抹平和融合方案，該方案從各端元件化渲染方案進行抽象，統一了一套相對抽象、可擴充的協定，包含頁面協定、布局協定群組件協定三大部分。頁面協定指定了目前頁面的基本資訊、頁面主體結構、埋點資訊、渲染方式；布局協定指定了該布局下所有元件的布局方式，同時以布局容器可支援元件abtest、元件分流、元件個性化等投放方式；元件協定細化到元件的基礎屬性、渲染方式，除此之外，還會定義元件的資料綁定行為、資料請求方式、資料取數方式，進而将元件UI和資料解耦，提升元件複用性和可維護性。
Android、iOS雙端分别面向這套标準協定，對端上的多種渲染方案和Native能力進行封裝，提供了統一的搭建容器實作，抹平了多端渲染的差異。
在此基礎上，前台的開發/營運就可以通過搭建和配置化的方式，建構出前台頁面的渲染協定（頁面協定+布局協定+元件協定），該協定最終被上行至服務端的“渲染網關”節點，由其來收口所有搭建場景中協定的下發。除了協定下發之外，渲染網關還收口了所有元件的取數邏輯，通過一個通用的資料網關接口來統一前台元件的取數方式，讓整個搭建體系變得更加簡潔和标準。
建構完整的場景搭建體系是一項浩大的工程，其中包含着無數研發人員的智慧結晶，受限于篇幅本文不再過多展開，想要了解更多的朋友可以參考我們之前的系列文章：
靈活研發體系
在場景搭建體系中，渲染網關對外封裝了統一的取數接口，前台的元件将會通過這個接口直接消費背景的服務端資料源，也就是一套重後端的方案（主要邏輯在服務端實作），是以在實際落地當中，往往需要為每個元件獨立開發一個專屬的資料源，這些資料源基本是對已有的RPC服務進行簡單調用，然後封裝一些前台相關的邏輯，是以使用輕服務來解決再合适不過了。于是兩者互相結合形成了一套非常靈活的研發體系：前端開發者開發UI元件，背景開發者通過MBOX編寫一個輕服務，快速适配生成資料源，兩者通過搭建進行簡單的配置化綁定，一個頁面就完成了，十分高效。正是這樣靈活的研發體系，幫助CBU快速地開拓了無線戰場。
營銷會場類頁面是應用這一研發體系的典型場景，我們以某行業導購會場為例來體驗其研發流程：
在這種研發體系下，前端和用戶端研發人員可以專注于開發自己的元件，而服務端研發人員則可以使用輕服務的方式快速為對應元件适配封裝對應的資料源接口（或者是編寫傳統的RPC服務），得益于搭建平台對元件和資料源的标準抽象，雙方的研發流程可以互相解耦，讓整個研發體驗變得更加專注和高效。而采用這種前後端分離的模式之後，各端的技術能力和架構将得到更加聚焦的打磨，是以我們在之後将看到前台元件和背景資料源的研發模式都會出現新的突破。
總之，新的研發體系大大提升了前台場景的研發效能，這離不開背後的兩大關鍵技術突破 —— 場景搭建體系和輕服務平台。而在此之中，又蘊含着無數工程師智慧和汗水的結晶，是他們面對未知時的勇氣和堅持探索的熱情成就了這些偉大的技術産品，并為CBU研發體系的演進之路立起了一座新的裡程碑。
向開拓道路的先驅者們緻敬。
摩登時代（2019～2020）
故事還在繼續。最近兩年，移動網際網路已經進入下半場，随着時間的推移，既有業務模式演變的越來越複雜，同時也越來越成熟，而在此基礎上，又有着諸多新的賽道被開拓，越來越多的競争對手走上了跑道。我們看到了航母級APP在一次次的打磨和曆練中竣工并啟航遠征，各種新的業務場景像停靠在甲闆上的一架架艦載機，随時準備以極快的速度起飛。總的來說，已有業務完成了野蠻生長，逐漸步入需要更多精細化打磨的階段，而更多新興的業務場景則需要通過借助既有的沉澱，用比以前更快的速度跑起來。
而在技術側，職能細分化使得各端的技術棧在過去幾年裡都得到了相當大的突破：在前台展示方面，無論是前端還是用戶端，元件化研發都已經成為基本共識，并且技術方案也高度成熟，甚至出現一些能夠根據UI智能還原生成元件的技術。而在後端和運維方面，随着Kubernetes一統容器編排，雲原生理念被迅速引爆，大量的底層運維和中間件能力被再一次下沉，以FaaS為代表的Serverless技術手段帶來了生産力的極大提升，讓上層人員能夠更加關注業務邏輯。對于大部分的普通業務場景，前後端技術都已經實作了一定程度的開放化：前端可以通過Serverless能力來快速編寫服務端接口，後端也可以通過低代碼和可視化方案開發前端元件，這都象征着對應技術棧的高度成熟化。
在上一個階段中，我們通過搭建體系+輕服務的方式，打造出了一套能夠靈活疊代的高效研發體系，幫助CBU快速完成了無線業務的布局，但在“野蠻生長”過後，也開始逐漸暴露出一些問題，其中最為重要的是以下幾點：
- FaaS服務帶來了非常快的疊代速度，也造成了服務的快速膨脹，導緻整體業務邏輯非常的分散，同時也進一步加劇了系統的複雜度。
- 輕服務平台的底層架構仍然是基于JVM實作，無法實作精細化的資源隔離和彈性伸縮，随着使用範圍的不斷擴大，性能和穩定性問題日益凸顯。
- 現有的研發體系雖然靈活度很高，但是有一定的上手和學習成本，并且各個平台之間的割裂感非常明顯，僅僅是通過一些約定連接配接在一起。
針對于以上問題，我們進行了大量的讨論和分析（詳細可見前文
《CBU Serverless 研發體系 FY20 S2 建設總結》)，并貼合實際業務訴求和業界技術的發展情況，制定出了以下的政策：
- 按照領域驅動設計的思路，對服務進行分層，進而有效梳理整體系統結構，同時對各類資料源進行标準化的定義和描述，制定統一規範來治理複雜度。
- 輕服務平台底層架構進行更新，對接集團Serverless基建，全面擁抱雲原生，釋放技術紅利。
- 以搭建體系為核心，對現有的工程能力和研發平台進行系統化整合，打造一套面向前台場景的标準化解決方案，讓後續類似場景的研發變得易了解、易上手、易維護。
下面筆者将分别為大家介紹每一個政策的具體實作方案。
MBOX + FunctionCompute：打造真正的雲原生FaaS解決方案
前文提到過，CBU在很早的時候就開始大規模應用落地輕服務平台MBOX，經過幾年的沉澱，這種FaaS形式的服務已經幾乎滲透進我們的每一條業務線，帶來了顯著的研發提效，MBOX這一技術産品也在經過多次打磨後變得越來越成熟。
與此同時，我們也一直在關注着業界和集團内對于Serverless架構的最新落地方案，期望能夠将Runtime層的實作從JVM容器更新為真正的Serverless容器，實作更安全的資源隔離和彈性伸縮能力。這個财年，我們和阿裡雲函數計算（Function Compute，下文簡稱FC）團隊的同學并展開了合作，經過近一個季度的打磨和試錯，完成了MBOX平台與FC函數運作時的整合，為服務端的研發同學打造出了一套将大量曆史經驗和最新技術方案相結合的标準FaaS解決方案。
在這套方案中，最大的變革來自中間件能力的下沉，得益于各種中間件能力的sidecar化，上層的業務應用可以變得十分輕量，進而具備了快速部署和彈性伸縮的條件。在此基礎之上，FC團隊結合集團的基建，提供了成熟的函數運作時容器，支援函數級别的資源隔離和彈性伸縮，實作真正的Serverless能力。最終，我們将經過多年沉澱的MBOX編碼方式和新的中間件調用方式進行了高度整合和優化，面向研發人員提供一套非常高效的業務FaaS程式設計架構和配套的預覽調試插件，真正做到開箱即用的研發體驗。整體方案架構如下圖所示：
和傳統的應用相比，這套函數應用方案十分輕量，可以實作快速疊代，同時還可以享受Serverless的紅利，無需關心資源運維。而相比于原有的MBOX輕服務方案，又有着更高的擴充性和安全性。
建設規範化的資料源體系
在前後端分離的研發模式下，通常将為前台元件提供資料的服務接口統稱為“資料源”，在之前的研發體系中，任何形式的服務接口都可以注冊成為元件的資料源，并沒有任何的規範或者标準，最終随着時間的流逝，體系中的資料源數量飛速增長，難以維護。經過分析後，我們認為出現這種現象的主要原因有以下幾點：
- 大量一次性資料源的産生。我們可以看到，前台元件往往無法直接消費現有服務，那麼隻能通過服務端消費已有服務進行二次封裝的方式來提供資料源。這種資料源基本都是為元件所定制，根本沒有複用性可言，但又會大量存在和膨脹。
- 資料源沒有做好分層，通用的底層服務和面向元件的一次性資料源散落在一起，在這種模式下，研發人員通常不會有意識地對自己的業務服務進行收攏和沉澱，往往是即用即寫（甚至複制粘貼），最終整個體系下的資料源變得越來越混亂和難以管理。
- 超過90%的資料源都沒有文檔和說明，對于使用方來說，往往隻能通過口口相傳的方式來了解自己想要的服務究竟可以“找誰擷取”，這種完全依靠經驗的研發協作方式效率是非常低下的，溝通成本極高。
- 資料源的研發體驗十分糟糕。要消費已有資料源，通常是編寫一個FaaS腳本，要麼通過傳統應用再封裝生成一個新服務再通過網關暴露。這兩種方式的研發體驗都泛善可陳，前者因為是泛化調用是以沒法使用編碼提示，後者則需要面對引入二方庫帶來的沖突和緩慢的部署速度，再加上沒有文檔，研發同學在開發代碼時的體驗可想而知。
為了解決上述問題，我們在現有的混沌局面之上建立了一套新的分層标準和規範，并提供了一系列新的工具和能力切面，逐漸形成了一套全新的資料源體系，并命名為“奇點”，下面我們來看一下奇點是如何解決以上問題，又帶來了那些新的能力：
第一步，對資料源進行分層和标準化。
通過對曆史經驗的歸納總結，我們将各類資料源進行了分層，并對每一層的資料源進行了标準化的抽象：
值得一提的是，我們将原來很多專門為前台元件适配資料邏輯的輕服務腳本從資料源中剔除了出去，單獨抽象了“字段映射”的腳本層，避免這些一次性的服務污染整個資料源體系。
我們為開發者提供了一系列的插件，可以從服務端的代碼定義中抽取出這些資料源的定義并進行标準化封裝，然後注冊至奇點的背景資料庫。随着底層開發同學的逐漸接入，我們便可以慢慢建立起一個更加清晰和标準的資料源體系。
第二步，增加能力切面，讓所有資料源變得可了解、可編碼。
在第一步的基礎上，我們還要徹底解決資料源的使用問題，首先要讓資料源變得可了解，目前奇點通過javadoc掃描源代碼注釋的方式抽取所有服務的出入參定義及說明，并适配成标準的swagger開源協定，導入到RAP平台（由阿裡開源的API文檔平台）形成文檔，在此基礎上我們還會通過特定方式采集服務的一些真實樣例，這樣任何人都可以快速了解一個資料源的具體含義和使用方式，徹底改變之前口口相傳的低效協作方式。
接着還要進一步簡化和規範資料源的使用方式，這裡先說說面向服務端側，奇點提供了一套通用的調用樁SDK，通過引入該SDK，隻要知道資料源在奇點平台中的簽名（即唯一辨別符）就可以快速建立一個調用樁，并可以通過該調用樁進行泛化調用，完全不需要感覺底層服務的類型，也無需引入任何其他依賴。考慮到泛化調用方式在開發時無法實作代碼提示，體驗比較糟糕，我們還制作了一套IDE中的輔助插件，這個插件通過掃描源碼時所記錄的出入參字段結構，可以在指定的工程中生成對應的DTO類定義，再加上一些序列化轉換邏輯，實際開發人員便可以實作非泛化的調用，就像使用本地定義好的服務一樣順暢，而這種方式由于沒有引入任何二方包，是以不會産生任何項目依賴沖突問題，是以研發效率不會受到任何影響。
總之，通過為所有接入的資料源提供文檔、樣例、調用樁和字段結構這四個通用的能力切面，奇點做到了讓所有的資料源變得可了解、可編碼、可觀測。随着不斷推廣和業務場景的覆寫，這将有助于在研發人員内形成一個良性循環，進而長期維持新的體系秩序。
第三步，改變前台元件消費資料源的方式。
一直以來我們都通過封裝服務接口的方式為前台元件提供資料源，這樣會不知不覺中産生大量的一次性服務。這些服務通常都沒有什麼複雜邏輯，隻是消費一些現有的資料源然後做簡單的字段映射。經過思考我們最終将這類服務從奇點的資料源體系中剔除出來，單獨抽象為字段映射的腳本（使用FaaS實作）。前台元件最終将不再直接消費資料源，而是通過一份标準協定，聲明其所需要的資料源和用于處理這些資料源的映射腳本，通過映射腳本來消費資料源。
這份标準協定可以通過搭建平台自動生成，通過這種方式我們将大量的一次性邏輯單獨抽離了出來，避免它們對資料源體系産生幹擾，起到架構中防腐層的作用。
總之，在建設完奇點這一套新的架構體系後，我們終于“守得雲開見月明”，打造出了一套清晰可用的資料源體系，至此我們已經基本解決了之前研發體系中的絕大多數問題，是時候對它們進行一定的整合，來産出面向前台場景的标準研發解決方案了。
前台場景研發标準解決方案
可以看到，經過多年的積累和打磨，CBU的前台場景研發體系已經非常成熟了，整體看來，它是由幾個關聯性很高的子平台所構成：元件平台（前端、用戶端用于開發和注冊元件的平台）、搭建平台、FaaS平台、和資料源平台（奇點）。在過往的研發流程中，這些平台之間是通過一系列的約定進行關聯的，而這些約定往往是“經驗”性質的，對于沒有使用經驗的同學而言，了解和上手的門檻還是有一點高的，且各個平台之間存在着比較強的割裂感，在整個研發流程中開發人員需要在多個平台之間反複操作和跳轉，帶來了很多不變。
在攻克了原有體系中存在的諸多問題之後，我們決定将這套新的前台場景研發體系進行标準化，以搭建平台為中心，通過綁定關聯的方式、打通其他各個子平台的功能，将研發流程集中串聯在一起，把搭建平台打造成場景研發的核心“工作台”，沉澱出一套标準的前台場景研發解決方案。
在這套标準的解決方案中，一個前台場景由一張搭建頁面（包含多個元件）、一個FaaS函數應用（由标準的腳手架生成）和一系列的資料源組成，在初始化階段中，可以将三者進行綁定關聯形成一個完整的場景工程。
完成初始化後即可進入實際的研發階段，這個過程中前台研發專注于元件的實作，背景則負責在FaaS應用内部引用各種奇點資料源（或新增）實作業務邏輯，再通過字段映射腳本為指定元件進行UI層的封裝适配，雙方都可以做到Only Focus on Business的研發體驗。
研發階段完成後，即可在搭建平台上進行配置和聯調，由于各個子平台已經完成高度串聯，是以在搭建平台上可以直接完成元件、資料源和字段映射的綁定及實時預覽，甚至可以通過列印資料鍊路來排查可能存在的問題，節省配置和聯調所用的時間，也降低出錯的成本。最後再進行測試和釋出，一個前台場景便可上線。
以我們目前已經落地的無線商品詳情頁場景為例，在此标準解決方案下，研發流程如下圖所示：
非常有趣的是，仔細觀察這套方案的實際開發階段，其中一個元件子產品所包含的内容：元件UI + 映射腳本 + 業務資料源 ，這一組合正是10年前bundle思想的延續。但相比于當時，新的這套方案更加标準化、更加易于使用，能夠快速地被應用于各種前台場景。另外我們也可以看到，随着各端技術棧的成熟，單一業務子產品的研發流程又再次被高度集中化，這其中大部分的研發工作都已經十分簡化，例如元件的低代碼開發、無需關心運維的函數即服務，或許這些工作以後又将脫離具體的崗位劃分，整合成一個新的“全棧”工程師角色，如此一來，單個需求研發的溝通成本将會進一步降低，研發效能或許會再次邁上一個新的台階（當然，這隻是一個YY性質的推測，歡迎大家拍磚交流）。
結語
至此，我們已經一路走過整整十年的曆程，感慨過往峥嵘歲月的同時，我們也在努力創造新的輝煌。研發體系的演進之路不會有終點，未來我們仍将繼續探索。感謝一起前行的同路人們，也歡迎更多有識之士加入我們，一起鑄就下一個新的時代！
掃碼了解更多技術幹貨與客戶案例：