原創 孫棋（空蒙） 淘系技術 2020-12-22
淘系業務高速發展，淘寶、天貓、淘寶直播、淘寶特價版、閑魚等平台上業務不斷創新，同時也對技術效率提出了新的更高的要求。而目前移動網際網路用戶端服務端分離的研發模式，存在跨技術棧+多端協同的挑戰，也面臨一些基礎的技術和業務能力無法有效的複用的問題。在此背景下，結合雲基礎設施的演進，結合端技術的發展，淘系技術探索實踐了業務雲端一體化的研發，圍繞應用架構的跨代更新，建構新的研發過程、研發體驗，在研發期、傳遞期、運作期重新定義了前台業務的研發模式。
業務研發模式演進的核心驅動力
“能力複用”、“跨端”、“技術棧歸一”是移動網際網路業務效率提升的三大底層核心驅動力，圍繞這三個點業務研發模式不斷的演進，以适應業務高速發展的訴求。
整個軟體工程發展的曆史，就是複用的曆史，一個行簡單的“hello world”，背後是一個工程奇迹，比如核心2700w行代碼，以及整個技術開源生态提供各種能力的組合，網際網路業務應用無不是站在巨人的肩膀上。能力的複用從使用模式上可劃分為代碼複用、服務化複用、元件化複用三種形态，背後是業務效率、隔離、成本上的平衡。
移動網際網路android、iOS兩大技術生态，給業務在跨端一緻性、業務效率上形成了巨大的挑戰
技術棧歸一，并不等同與跨端，也不是開發語言的統一，類似目前有業務全棧工程師的一種探索，這種模式是對開發人員提更高的要求，他要解決用戶端、服務端，用不同的技術棧來完成業務研發的閉環，這并不是技術棧歸一。技術棧歸一是面向業務的技術棧收斂，讓業務回歸自身，通過合理的分工邊界來減少協同。
目前淘系業務研發挑戰與應對
這樣的研發模式是否已經完善，我們來看目前的一些現象。
移動網際網路業務研發這些現象背後的核心問題是什麼呢？
可以看到目前的業務研發模式，是以技術棧劃分了用戶端和服務端的強邊界，中間基于API協同的模式，而API的定義随着業務快速發展是易變的、這層API并不是如TCP與IP層之間那樣，有清晰的邊界，不同的職責分工，易變這就造成了高昂的協同成本。同時也因為不同的技術棧，人力資源配比會對業務發展形成制約。伴随着業務平台化發展，業務平台化本質也是“能力的複用”來提升效率，大量業務都形成了面向前台業務頁面的backend for fronted這一層，這層典型的特征是編排組合能力，快速的完成業務傳遞；比如一個活動頁面，擷取使用者資訊、商品資訊、積分資訊等，這本來是個内聚的業務，卻因為技術棧的邊界而割裂。
這些問題背後的主要沖突，是一體化的業務，與技術棧為邊界、基于契約分工協調研發模式的不比對。舉個反例子，泥水匠砌牆分兩步，先是依據磚塊要處的位置決定在某幾個面塗上水泥漿，然後把這塊磚放到合适的位置上；如果這兩步分開為砌牆工程師+塗水泥漿工程師來協作，兩個人在砌牆的時候還要對眼神确定應該給磚塊某個面塗水泥漿，塗多少水泥漿，這樣砌牆的效率還能快嗎？
是以我們自然而然想到，讓前台業務實作雲+端一體化的研發傳遞，即“write integration run everywhere”，簡類比研發模式變化，從原來的三個和尚沒水喝，到兩個和尚擡水喝，到一個和尚擔水喝。那關鍵問題，如何讓簡單的編排邏輯的BFF層，由端同學實作閉環呢，從割裂的用戶端+服務端研發，轉變為前台業務研發，這裡會有哪些困難
業務BFF現狀是一個單體巨石應用，分析可見他由工程架構、通用技術、領域複用和業務邏輯共同組成，用戶端研發首先面臨開發語言門檻問題，技術棧上是不一緻的；其次是業務隔離性問題，業務這一層與其他三層是緊密耦合的關系，而且業務平台的富用戶端有高昂的開發語言限制的壁壘，也正因為這些客觀因素，導緻一個應用裡面的業務越來越多，最後變成了業務間的耦合，造成研發效率的底下；最後是BFF運維的複雜，對用戶端技術同學而言是巨大的壁壘。
那麼這些問題怎麼解決呢？核心2個政策，“多容器應用架構”+“元件化應用架構”，我們先看前者。
雲原生技術發展，容器設計模式提供了多容器支援，為業務和依賴解耦提供了新的路徑，原來業務之外的領域複用層、通用技術元件和工程架構，全部隔離到bottle runtime，業務邏輯獨立運作在biz runtime，兩個容器共同組合gaia application的容器規範；這裡帶來一個顯著的變化，業務變輕量了，是以biz runtime的多語言變為可能，支援跨端研發語言門檻被解決。
這裡還有另外一個問題，領域複用層内，包含了多種多樣的領域能力，雖然與業務剝離了，但他們之間還是缺乏有些的隔離，同時富用戶端高昂的使用成本怎麼解決，如何讓前台業務研發達到開箱即用的效果？
元件化應用架構就是實作平台能力快速複用的核心。首先bottle runtime支援開放擴充架構，支援元件的按需加載使用；從流量進出視角劃分，定義了兩種基本元件類型，其次不同的元件都有其自有資料協定，gaia定義了binding協定統一封裝，面向業務研發則抽象了OnInputEvent、InvokeBinding、InvokeService三個基本接口，把元件能力标準化，這樣OnInputEvent對應了InputBinding類型的業務元件，InvokeBinding、InvokeService對應了OutputBinding元件，兩個容器見基于本地通訊的grpc收口。
有了元件化的應用架構，圍繞這個架構的元件生産、傳遞、使用的配套體系也需要同步的建設。從元件生産者而言，他隻需要按照bootle component規劃來開發，傳遞時候gaia平台會自動生成各種語言原生的SDK，上傳到元件庫；對前台業務開發者，僅需要聲明引用元件，編寫自己的業務邏輯，後續的建構傳遞平台會自動的把元件傳遞。最終實作元件的開箱即用的效果。
總結來說，通過“多容器架構”+“元件化架構”的演進，業務函數化研發，解決了用戶端同學實作雲+端一體化閉環的技術棧門檻問題，領域能力開箱即用，讓“前台業務研發”跨端閉環從設想到落地。
業務雲+端一體化探索實踐
有了這些架構能力更新，我們來看淘系業務雲+端一體化的實踐，基于業務的特性劃分為3種典型的應用場景探索，分别是“一體化快速創新疊代”、“複雜互動邏輯”、“子產品化搭建複用”。
▐ 一體化快速創新疊代
面對簡單的業務編排場景，因gaia提供了跨語言的函數化研發能力，整個研發生産關系發生了變革，前台業務研發可以實作BFF到用戶端flutter研發的閉環，用統一的Dart開發語言，不再需要協同開發，原來碰到的各種協同問題天然不複存在，實作内聚業務的“技術棧歸一”；同時業務平台領域能力，成為gaia的元件，實作高效的“能力複用”。我們來看閑魚足迹，這個典型的應用場景。
原來用戶端+服務端基于API協作的研發模式，現在由“前台業務研發”一個角色來跨用戶端和服務端的閉環，他從足迹的儲存、查詢、删除實作完整業務的傳遞，商品平台的領域能力提供商品資訊查詢，這個領域能力通過元件化開箱即用。
這種方式下，API還是一個顯性存在的，強嵌入研發傳遞和運作過程當中的；大家估計也會碰到大量的API需要維護；同時API的粒度很難把控，一個頁面，到底是一個API編排所有的服務，還是細分多個API，都有利弊，尤其是複雜業務互動邏輯的場景，是否有更高效的方式？
▐ 複雜互動邏輯
基于redux的一體化研發架構，是解決複雜互動邏輯場景的鑰匙，其核心是基于store的state狀态變化，驅動頁面渲染，互動産生的事件，再由reducers函數化業務邏輯更新state；這套架構我們定義為Nexus一體化研發架構，對事件進行了抽象封裝，把常見事件的統一定義，同時支援業務自定義事件類型，并打通用戶端到服務端閉環。
比如閑魚的交易下單場景，頁面上涉及多塊的資料，包括閑魚币、詳情、收獲位址、運費、紅包服務等，如果1個API編排所有的服務，勢必造成業務的耦合，而多個API又對用戶端傳遞複雜性、使用者體驗等産生影響，同時這個頁面又存在修改位址、使用紅包等使用者業務互動的場景，最終情況往往是沉重的用戶端邏輯，相容與擴充性存在巨大挑戰。
一體化研發架構則優雅的解決這些問題，頁面級的orderPageState，他是由詳情、收獲位址、紅包等state組成，頁面初次渲染時候是init action，gaia業務函數響應并更新state，同步到用戶端驅動頁面的渲染；當後續有修改收獲位址等事件發生，也是同樣的處理流程閉環。
以此實作了頁面和業務邏輯的解耦，業務通過自定義擴充事件驅動，把業務邏輯下沉到了雲端，用戶端輕量化傳遞，也解決了用戶端版本化釋出重邏輯帶來的碎片化挑戰，同時業務邏輯基于state的擴充組合和事件驅動，實作業務細粒度的解耦，提升了業務效率。這種研發模式下，API已經弱化不再需要基于強協定的開發。
▐ 子產品化搭建複用
看淘系業務頁面組成，肉眼可見的存在複用的可能，“能力複用”本身就是業務效率提升的核心驅動力，同時業務高速發展也提出了通用的訴求，不可能所有的業務都是從0到1的開發，那怎麼樣去實作頁面的複用呢？
分析頁面的結構，其實質是由子產品組成的；子產品則由layout節點和普通節點共同組成，layout是資訊流、stick等多種形态按業務的選擇，普通節點是一個個端元件，端元件是UI控件模闆和資料源共同組成，實作最終的端元件渲染展示與互動使用，我們自然想到，通過頁面子產品化的搭建，實作快速的業務傳遞。
DinamicX是淘系端元件化的産品，與gaia的結合提供資料的編排能力，建設頁面搭建平台，讓業務傳遞從開發編碼，變成一次快速的配置傳遞過程，所見即所得。
看淘寶特價版活動頁的例子，通過搭建平台把多個子產品組合起頁面，子產品則由布局節點和普通節點端元件組成，端元件後面是對應的資料源服務，讓這些業務快速傳遞。
總結展望
淘系前台業務雲+端一體化的探索，核心是通過多容器應用架構的更新，打通了技術棧的邊界，實作了業務跨雲+端的閉環；通過元件化的應用架構實作領域能力複用的透明化；通過函數化的研發傳遞讓運維透明；通過雲端一體化架構以及頁面子產品化搭建，讓“前台研發”專注于業務。
雲端一體化研發模式閉環，沉澱典型應用場景模式。前台編排型場景傳遞效率提升30%（bug數量減少20%）；閑魚求購、懸賞端到端簡單需求變更一人半天上線，這在過往從0到1的開發模式下是不可想象的；研發期修改調試10秒内傳遞生效，真正做到秒傳遞的研發。
目前gaia平台已經實作百萬級QPS、百億級流量運作，包括閑魚、淘寶互動、淘寶特價版、淘寶拍賣等等衆多的業務場景已經廣泛的使用。
總結淘系前台業務雲端一體化研發模式的探索，本質仍是圍繞“能力複用”、“跨端”、“技術棧歸一”這三個核心的驅動力的探索；雲+端一體化“前台業務研發”，是業務研發分層職責與關系的再定義，從基于實體的技術棧邊界，轉為以業務内聚的邏輯邊界；底層則是應用架構的更新，基于單一職責，多容器+子產品化的方向演進，讓業務聚焦自身。
展望未來，首先是在研發工程體系上，要端到端打通一體，對應研發配套基礎能力，如調試、問題排查等，是後續研發模式成敗的關鍵，這個點上往往是大家做技術平台産品容易被忽視的點，很多産品大邏輯是通順的，最終往往死于細節。其次要實作運維自動化，元件的管控，面向業務透明更新，基于流量驅動的容量管理，運維透明化是個巨大的挑戰。最後，技術不是銀彈，目前這種架構和研發模式有其适用的場景，也有其負向的效應，比如機器資源overhead的成本，運維職責逐漸轉移到平台後如何用技術能力系統化解決，是未來可期待的突破。