一、背景
随着閑魚業務的高速增長，業務的數量和複雜度，都急劇增加，研發側在業務支撐上出現了兩個明顯的變化：
一方面，如首頁、搜尋之類的傳統流量型頁面，試錯和調整變得更加頻繁，隻有卡片級的動态化能力已經不能滿足需求，更多的頁面級結構調整撲面而來，僅以首頁為例，去年大約有一半的時間，都在做頁面結構調整。
另一方面，更多的DAU帶來的是更多的垂直業務的增長，如同城、會玩、優品、租房、二樓等等，它們也都需要自己的流量型“首頁”，而在這個過程中，同類型結構和能力的頁面代碼大量重複，開發維護成本非常之高。
那麼有沒有一種方案，能夠快速cover各個業務場景裡的流量型頁面，不僅能夠适應這種快速多變的大量結構性調整，并且能夠快速試錯和嘗試，盡可能減少重複代碼的方案呢？答案是有的，基于流量型頁面重展示，輕互動的特點，我們的解法是建立一套端到端的頁面級描述協定，加上對接協定的雲端搭建平台來對流量型頁面結構進行動态調整和渲染。一方面，協定的調整可以直接映射為頁面結構的調整，以達到less code甚至no code對頁面結構進行調整的目的。另一方面不同業務場景，可以用通用協定來進行橫向擴充，減少開發和維護的成本。
二、流式場景協定的擴充
閑魚去年的時候，基于流量型頁面，提出過一套三級協定的容器化解決方案，當時的三級協定包括：Page、Section和Component，能夠較好的描述單頁面的情況：
- Page層協定主要包含整個頁面Sections資訊，以及下拉重新整理、上拉加載更多等配置資訊；
- Section層協定包含目前Section的布局資訊、初始化Event、LoadMore Event及Components等資訊；
- Component層協定與具體業務相關，對于容器來說是黑盒的，具體如何渲染會交給業務方處理；預設提供DX解析渲染Handler。
容器中，事件中心基于事件傳遞的方式，資料中心基于MVVM的資料驅動進行實作，在UI渲染方面，閑魚将清單容器與動态模闆渲染DXFlutter相結合，實作頁面渲染及資料更新後的頁面重新整理能力。
為了适應複雜的多頁面場景以及容器嵌套的情況，我們在之前提出的三級協定的基礎上，擴充了四層協定的設計：Container、Page、Section和Component。新設計的Container層協定主要包含多個頁面Page的資訊，以及頁面Page對應的tab等配置資訊：
|-- Container
|-- Page
|-- Section
|-- Component
由于在Container這一級，我們需要對多個Page頁面進行布局，這裡目前能支援三種形式：
- 單頁面，每個頁面單listview形式
- pager+tab+多頁面形式，每個頁面是單listview形式
- 頁面内包含子容器，也就是嵌套容器的形式
我們以最複雜的嵌套容器的情況為例，嵌套的子容器對他的父級的頁面而言，實際上是一個Component(卡片)，但是它的内部資料結構是一個完整的Container的容器結構，在協定上，我們給它設定的type="sub_container"，這個時候會用預設的SubContainerRenderhandler(子容器渲染器)對自容器進行解析和渲染，并在過程中處理對應的手勢問題，這裡我們會給父容器和子容器在協定上分别進類型指定，并提供類型對應手勢響應能力。子容器中的頁面間的切換消息通過通知對外發送，如果是tab+pager的形式，隻需要在tab内對廣播消息設定對應的監聽即可，同時子頁面也可以通過通知消息接收切換頁面的指令，這樣的組織形式就能讓tab和pager在解藕的情況下互相通信。
三、雲端平台的設計
整體設計
目前流量平台以二方包的形式對業務服務提供支援，營運和開發可以在流量平台搭建頁面和配置對應的資源位資料，在資料修改之後，平台會将修改的部分先寫入到TDDL，然後再主動同步到cache，而cache可以被部署在業務服務的平台client二方包讀取到，正常的情況下，cache存在，則業務服務在響應閑魚用戶端請求的時候，隻需要讀取緩存即可，隻有在緩存不存在的時候，才需要主動拉取對應的資源配置資料。
Client二方包設計
其中部署在業務服務中的client二方包具備配置擷取、分流計算、動态注冊、遠端調用等基礎能力，除此之外，還對容災兜底和異常監控都有對應的設計。依賴二方包的形式，業務方服務就能夠以解藕的方式來擷取流量平台的資源和配置資訊。
分流的設計
由于流量型頁面需求多變，試錯的場景普遍存在AB實驗的需求，我們在雲端平台設計了一套流量分流的體系，來最大限度的降低流式場景下AB實驗的成本。
一個閑魚端側使用者在請求容器頁面時，會将對應的使用者、版本、lbs等相關資訊通過統一的協定上傳到雲端平台，平台拿到這些資訊之後，會經過概念層、分流層、執行個體層和資源層，最後所有執行個體都會關聯資源和釋出計劃。這樣請求最終能映射到某一個确定的投放方案上，進而讓對應的使用者看到确定的頁面搭配，進而達到雲端實驗分流的目的，最終讓使用者看到他應該落到的實驗頁面。這樣建立或者調整頁面的AB實驗，我們隻需要在雲端配置對應的實驗頁面需要滿足的流量條件即可，很大程度上降低了業務試錯的研發成本。
安全容災
流量型頁面一般承載着對應業務的業務入口的角色，是門戶，它的穩定性不言而喻，是以整體端雲一體的設計中，也少不了對容災和兜底的考慮。
雲端容災
正常情況下，用戶端請求平台，通過業務方服務接口把userid、城市、裝置等資訊上傳到雲端，根據之前的流量設計以及二方包的緩存設計，如果命中的方案，二方包能擷取到緩存，則會直接傳回緩存資源資料，否則會去流量平台請求資源資料再傳回。
在異常情況下，或者沒有拿到對應的緩存，那麼這時候會用到我們在緩存制備好的的一份兜底資料，兜底資料會在平台操作變更時，通知業務方服務端去制備新的兜底資料以及去除舊的兜底資料。
用戶端容災
用戶端容災主要考慮到網絡異常或者接口服務不可用的情況，依然需要保證頁面的正常展示，這個時候我們在端側設計了三級緩存：記憶體緩存、磁盤緩存以及預置緩存。記憶體緩存和磁盤緩存都會在接口成功回調之後做儲存動作，在失敗的情況下會優先去擷取記憶體緩存和磁盤緩存，而當這兩部分都擷取不到時，就會嘗試擷取打在apk包中的預置緩存資料，這樣保證頁面不管任何情況下都能正常展示。
用戶端與雲端平台協定互動
由于端側容器化協定是基于事件進行互動的，那麼在雲端平台加入之後，整體事件互動的邊界就被進一步拓寬。舉個例子，以點選觸發關注清單中的某個卡片出現關注标記為例。傳統的做法，一般是用戶端在端側寫好關注和重新整理邏輯，然後在點選的時候去調用寫好的重新整理方法。但是如果用端到端的協定來實作，則會變成點選将清單接口在目前卡片上綁定的事件回傳給平台，這個事件是什麼，對端側來說是透明，在目前場景就是一個關注的事件，那麼這個事件會通過點選事件帶到雲端，雲端拿到對應的事件key之後，會下發對應的資料，然後端側隻對資料進行重新整理，重新整理之後，就會讓目前卡片出現關注标記。這樣的好處在于，減少業務依賴端側的版本釋出，最大程度的使用資料驅動的設計，減少依賴，提高複用性。這樣的設計加上容器化協定對頁面結構的描述和渲染，在重展示輕互動的流量型頁面，将會大大減少端側邏輯耦合，提高業務開發的效率。
總結和展望
目前，端雲一體的容器化搭建方案，已經在閑魚多業務場景落地。此前的兩個問題也得到了解決：
1. 頁面結構調整的動态化能力：以首頁為例，在容器化協定落地之後，再做頁面結構調整，我們隻需要簡單修改雲端平台的配置加上很少的代碼改動即可生效，大大減少了業務維護的成本。
2. 橫向業務場景的流量型頁面支撐：借助雲平台配置搭建和端側容器化渲染協定，現在大約隻需要平時一半的開發時間，就能完成一個全新業務場景的搭建，更多的頁面骨架型代碼，都沉澱在以容器化協定為基礎的SDK中。
流式場景下端雲一體搭建體系，降低了端側多業務中流量型頁面這種特定場景下的備援代碼邏輯。整體雲端一體的容器化搭建方案，使得less code甚至no code快速調整頁面結構以及快速搭建新業務場景中以展示為主、輕互動動态化營運流量型頁面成為了可能。