目錄

• 前言

• 業(yè)務(wù)網(wǎng)關(guān)介紹

• 業(yè)務(wù)網(wǎng)關(guān)面臨的主要挑戰(zhàn)

• 業(yè)務(wù)網(wǎng)關(guān)解決方案

• 總結(jié)與展望

前言

京東到家是達達集團旗下中國領(lǐng)先的本地即時零售平臺，依托達達快送和零售合作伙伴，為消費者提供超市便利、生鮮果蔬、醫(yī)藥健康、3C 家電、鮮花綠植、蛋糕美食、服飾運動、家居時尚、個護美妝等海量商品約1小時配送到家的即時消費服務(wù)體驗。作為京東到家流量入口的業(yè)務(wù)網(wǎng)關(guān)，相比于API網(wǎng)關(guān)承載整個平臺的流量入口，它是按頁面內(nèi)容承載具體某一塊業(yè)務(wù)的流量分發(fā)入口，如京東到家的首頁、頻道頁、活動頁、門店頁、單品頁等。業(yè)務(wù)網(wǎng)關(guān)又被稱為服務(wù)聚合層，這也和它的業(yè)務(wù)職責有關(guān)，本文將這一類系統(tǒng)，統(tǒng)稱為業(yè)務(wù)網(wǎng)關(guān)。

上圖是京東到家APP首頁和門店頁的截圖，這些頁面呈現(xiàn)的內(nèi)容均來自于業(yè)務(wù)網(wǎng)關(guān)的聚合處理，業(yè)務(wù)網(wǎng)關(guān)作為橋梁連接著京東到家基礎(chǔ)服務(wù)到用戶App端展示內(nèi)容，本文將詳細介紹下業(yè)務(wù)網(wǎng)關(guān)的職責以及面臨的挑戰(zhàn)。

業(yè)務(wù)網(wǎng)關(guān)介紹

京東到家業(yè)務(wù)架構(gòu)示意圖

圖中標紅底的位置就是業(yè)務(wù)網(wǎng)關(guān)在京東到家業(yè)務(wù)架構(gòu)中所處的位置，它處于API網(wǎng)關(guān)之后，基礎(chǔ)服務(wù)之前，它的作用是將不同領(lǐng)域的基礎(chǔ)服務(wù)數(shù)據(jù)使用不同的業(yè)務(wù)規(guī)則聚合后通過App呈現(xiàn)給用戶。

對業(yè)務(wù)網(wǎng)關(guān)有了初步認識后，這里以京東到家首頁feeds流為例詳細介紹下業(yè)務(wù)網(wǎng)關(guān)的具體職責。

如圖所示，京東到家首頁feeds流展示了商品基本信息、價格信息、促銷信息、門店信息、運費信息、紅包及優(yōu)惠券信息、輪播資源位、限時搶購、活動引導(dǎo)圖、榜單入口圖等多類元素，每一個元素都可能來自不同領(lǐng)域的基礎(chǔ)服務(wù)，如商品系統(tǒng)、價格系統(tǒng)、庫存系統(tǒng)、促銷系統(tǒng)、CMS、優(yōu)惠券系統(tǒng)、門店系統(tǒng)、推薦系統(tǒng)等。

feeds流網(wǎng)關(guān)要聚合完成這個頁面的所有展示元素首先要把這些資源的數(shù)據(jù)來源和上游基礎(chǔ)服務(wù)以及基礎(chǔ)服務(wù)依賴關(guān)系關(guān)聯(lián)起來，如給用戶呈現(xiàn)的商品skuId來自于推薦系統(tǒng)，商品展示的圖片、名稱、規(guī)格等信息來自于商品系統(tǒng)，商品的價格和促銷標分別來自價格系統(tǒng)和促銷系統(tǒng)，一些活動資源位如輪播圖、宮格等又來自CMS。由于京東到家是基于LBS的本地即時零售平臺，所以首先要通過定位系統(tǒng)獲取有效的服務(wù)門店列表，然后通過這些門店作為入?yún)慝@取要展示的內(nèi)容。簡易示意圖如下：

理清這些展示層數(shù)據(jù)來源和基礎(chǔ)服務(wù)的依賴關(guān)系之后，feeds流網(wǎng)關(guān)還需要根據(jù)頁面呈現(xiàn)的核心內(nèi)容來進一步去劃分主流程和輔助流程，圖上紅色箭頭所示為主流程，之所以把獲取商品資源看成是主流程是因為feeds流頁面的定位就是讓用戶來選品的。劃分好主流程輔助流程之后在開發(fā)過程中就要優(yōu)先考慮主流程的降級和兜底方案，另外一些資源如線程池等也要優(yōu)先向主流程傾斜。

最后feeds流網(wǎng)關(guān)根據(jù)版本適配按App端展示結(jié)構(gòu)把從基礎(chǔ)服務(wù)獲取的數(shù)據(jù)做一層轉(zhuǎn)換和封裝后呈現(xiàn)給用戶，因此業(yè)務(wù)網(wǎng)關(guān)只要根據(jù)需求新增或者變更聚合規(guī)則，就擁有呈現(xiàn)出千千萬萬不同頁面的能力。

業(yè)務(wù)網(wǎng)關(guān)面臨的主要挑戰(zhàn)

? 編碼風(fēng)格不統(tǒng)一

不同開發(fā)人員有著不同的編碼風(fēng)格，就連開發(fā)過程中用到的線程池都有很多種使用方式，這樣會導(dǎo)致系統(tǒng)交接時新接手人員要掌握不同編碼風(fēng)格，同時又融入了自己的編碼風(fēng)格，經(jīng)過多年迭代之后系統(tǒng)越來越難維護。

? 系統(tǒng)臃腫

業(yè)務(wù)網(wǎng)關(guān)是直接和用戶交互的，相較于底層基礎(chǔ)服務(wù)，它在業(yè)務(wù)上的“玩法”更加多變，需求改動也更加頻繁，一些功能邏輯要兼容多個App版本甚至要兼容不同的端（IOS、Android、H5、小程序等），在長時間的功能迭代后不可避免的導(dǎo)致一些兼容邏輯散落在各個地方，從而讓系統(tǒng)變得臃腫，維護和迭代起來會比較麻煩，甚至存在一些潛在的風(fēng)險。

? 重復(fù)造輪子

下圖頁面為京東到家附近門店列表資源，每個門店資源展示的元素都來自門店基礎(chǔ)服務(wù)、購物車系統(tǒng)、評價系統(tǒng)、月售系統(tǒng)、時效系統(tǒng)、距離服務(wù)系統(tǒng)、運費系統(tǒng)、紅包系統(tǒng)、優(yōu)惠券系統(tǒng)、促銷系統(tǒng)等多個基礎(chǔ)服務(wù)聚合，而展示門店列表的頁面又很多，如一些促銷頁面，活動頁等，假如有需求需要新增一個門店標就需要涉及展示門店列表的網(wǎng)關(guān)都要聚合進去。

? 聚合效率非最優(yōu)

由于業(yè)務(wù)網(wǎng)關(guān)需要調(diào)很多基礎(chǔ)服務(wù)或中臺服務(wù)的接口，本身又直接面向C端用戶，作為流量入口，接口的調(diào)用量非常高，開發(fā)人員一旦不注意對上游接口的調(diào)用效率，比如接口能調(diào)用一次的調(diào)用了多次，能批量調(diào)用的結(jié)果單次調(diào)用導(dǎo)致對上游接口的壓力過大，或者基礎(chǔ)服務(wù)接口調(diào)用的依賴順序沒做好，該并行調(diào)用的接口串行調(diào)用了，又或者線程池使用不當?shù)?，都會損失系統(tǒng)吞吐量，如果只靠橫向擴展機器，顯然是從業(yè)務(wù)網(wǎng)關(guān)到上游服務(wù)都是要投入更多服務(wù)器成本的。

業(yè)務(wù)網(wǎng)關(guān)解決方案

了解了業(yè)務(wù)網(wǎng)關(guān)的一些痛點后，才能針對性的給出解決方案。我們先將業(yè)務(wù)網(wǎng)關(guān)的聚合工作轉(zhuǎn)化成業(yè)務(wù)模型。

通過簡化后的業(yè)務(wù)模型，我們看到底層基礎(chǔ)服務(wù)通過一組規(guī)則按流程進行執(zhí)行，像極了我們常見的一些工作流或者流程編排一樣的東西，那是否能從流程編排的思想里解決上述痛點呢？

關(guān)于編排的概念有很多，如工作流，服務(wù)編排、容器編排、任務(wù)編排等，其核心邏輯都是將一些需要執(zhí)行的邏輯通過一些規(guī)則定義出先后依賴執(zhí)行順序，只不過面向的業(yè)務(wù)場景不同。在流程編排方式上也有多種思想，這里簡單介紹兩種以及優(yōu)缺點對比。

? Pipeline模式

這種模式是將一個個需要執(zhí)行的任務(wù)抽象一個個步驟，一組步驟抽象成一個執(zhí)行階段，多個執(zhí)行階段根據(jù)先后依賴順序組成一個執(zhí)行管道Pipeline，這種方式在處理復(fù)雜業(yè)務(wù)流程組合的時候比較容易想到，在遇到一些復(fù)雜業(yè)務(wù)邏輯時也能清晰的表達出來，便于維護和擴展。

但是這種模式也有些缺點，解決不了組合時間最優(yōu)的問題模型，下圖是我把這類問題簡化成一個簡單的流程組合，實際業(yè)務(wù)場景可能要比這些復(fù)雜更多。 

第一張圖要執(zhí)行一個這樣的業(yè)務(wù)流程，我們?nèi)绻捎肞ipeline模式會發(fā)現(xiàn)Task3要么和Task1并行執(zhí)行，要么和Task2并行執(zhí)行，總之執(zhí)行時間為300ms，需要把Task1和Task2先串行封裝成一個任務(wù)再與Task3并行才能減少執(zhí)行時間。很明顯，這樣會產(chǎn)生一些問題，比如破壞了任務(wù)的獨立封裝，并且還需要開發(fā)者去具體關(guān)注這樣的場景，在一些負責業(yè)務(wù)開發(fā)場景中，可能還不知道具體要執(zhí)行的時間，所以讓使用者保證執(zhí)行時間最優(yōu)是不太好的。

? 任意組合模式

這種模式解決了Pipeline模式的缺點，同時也擁有Pipeline模式的諸多優(yōu)點，只關(guān)注任務(wù)本身執(zhí)行的先后依賴，不會等待無關(guān)的依賴順序，使用者只需要按依賴順序配置好續(xù)執(zhí)行任務(wù)即可，把更多的精力放到處理具體任務(wù)的業(yè)務(wù)中，所以京東到家的服務(wù)編排工具選擇了這種模式。

京東到家服務(wù)編排工具由三部分組成：執(zhí)行單元、流程控制器和數(shù)據(jù)池，其中執(zhí)行單元用來定義任務(wù)執(zhí)行所需要的執(zhí)行條件，如任務(wù)執(zhí)行的超時時間、線程池、執(zhí)行狀態(tài)、后續(xù)任務(wù)等，流程控制器用來按編排流程去執(zhí)行和控制任務(wù)的依賴、聚合、超時、異常等，數(shù)據(jù)池則是將任務(wù)執(zhí)行后的結(jié)果數(shù)據(jù)放入到全局可見的數(shù)據(jù)池中，調(diào)用鏈路生命周期可以共享。

整個調(diào)用流程如下圖所示，任務(wù)通過流程控制器編排后去執(zhí)行，執(zhí)行結(jié)果將被放入到由ThreadLocal和ConcurrentHashMap實現(xiàn)的數(shù)據(jù)池中，在上下文傳遞，后執(zhí)行的任務(wù)只需從數(shù)據(jù)池中就可以獲取到前置流程的結(jié)果。

通過實踐發(fā)現(xiàn)，業(yè)務(wù)網(wǎng)關(guān)的執(zhí)行邏輯引入流程編排框架后，雖然也額外增加使用門檻，但優(yōu)勢也更加明顯：

? 開發(fā)規(guī)約

流程編排“約束”了編碼方式，讓開發(fā)者將注意力集中在業(yè)務(wù)線的設(shè)計和實現(xiàn)點的編碼，按照“一切業(yè)務(wù)皆可編排”原則，所有的業(yè)務(wù)先按照相對固定的思維去設(shè)計“線”，再扣“點”，當開發(fā)者結(jié)合產(chǎn)品需求對“線”的設(shè)計完備以后，完全可以沉浸于“點”的實現(xiàn)，并且可以按照“點”的特性安排不同的開發(fā)人員進行完成，不僅“強制”統(tǒng)一了開發(fā)規(guī)范，而且還提升了開發(fā)效率，也更適合團隊合作開發(fā)。

? 業(yè)務(wù)功能內(nèi)聚

業(yè)務(wù)邏輯長時間迭代導(dǎo)致代碼層面臃腫的問題，我們通過使用流程編排框架，將不同的能力被分組聚合成一個個服務(wù)，各個服務(wù)的能力職責單一，只需要按一定的規(guī)則進行業(yè)務(wù)流程編排即可，這些服務(wù)不做任何展示層邏輯或者數(shù)據(jù)結(jié)構(gòu)封裝，只做數(shù)據(jù)的RPC查詢，整體就像搭積木一樣。但是實際存在的各個版本、甚至各個端的兼容邏輯依然存在，這里引入了防腐適配層概念，將這些代碼邏輯盡可能不影響展示層數(shù)據(jù)封裝結(jié)構(gòu)和流程編排數(shù)據(jù)獲取，最大限度保證業(yè)務(wù)的靈活性。 

? 業(yè)務(wù)組件復(fù)用

通過分析業(yè)務(wù)網(wǎng)關(guān)聚合的展示資源，其實業(yè)務(wù)網(wǎng)關(guān)所要聚合組裝的內(nèi)容無非是銷售資源（商品）、促銷資源（優(yōu)惠券）、門店資源以及一些引導(dǎo)資源（活動圖、banner資源位）等，我們將這些組件或者功能流程沉淀下來，封裝成統(tǒng)一的資源組件或者通過服務(wù)編排組合成一些公共效率中臺服務(wù)，這樣就會被編排進更多的業(yè)務(wù)規(guī)則中，在各個領(lǐng)域的業(yè)務(wù)網(wǎng)關(guān)中復(fù)用。

? “俯視”整個業(yè)務(wù)流程圖

隨著業(yè)務(wù)的不斷迭代和功能的不斷增多，再加上開發(fā)人員相互交接，要貫通所有的需求場景對任何人來說都不是一件容易的事情，對業(yè)務(wù)的理解和維護成本越來越高，通過使用編排規(guī)則，我們可以不用大費周章的梳理業(yè)務(wù)流程即可俯視整個業(yè)務(wù)的功能重點，及各個展示層頁面維度的數(shù)據(jù)來源，大大降低系統(tǒng)交接帶來的風(fēng)險和理解成本。流程編排的職責不僅僅是“定義規(guī)則”和“管控規(guī)則”，更在于對業(yè)務(wù)規(guī)則的描述。

? 縮短開發(fā)周期

流程編排提倡能力復(fù)用，通過編排大部分已經(jīng)實現(xiàn)的能力和少量新編碼的能力來完成業(yè)務(wù)流程，并不斷沉淀新能力以面對更多需求迭代。這是一個不斷進化和自我成長的過程，通過這種能力的不斷沉淀和增加，使得我們在新增一個頁面的時候，只需要將原有的已經(jīng)大部分實現(xiàn)的流程進行規(guī)則編排，只需要特殊處理些展示層邏輯即可，可大大縮短項目開發(fā)周期，因為從零到一的過程是站在已有能力的基礎(chǔ)上進行快速迭代的。

總結(jié)與展望

在業(yè)務(wù)快速迭代的背景下，如果系統(tǒng)的基礎(chǔ)架構(gòu)設(shè)計不好，在未來隨著業(yè)務(wù)的不斷增加，系統(tǒng)也將變得越來越難維護，甚至存在潛在風(fēng)險。要想使系統(tǒng)保持靈活和易用，就需要不斷的尋找使系統(tǒng)變好的驅(qū)動力，而這種驅(qū)動力正是不斷的挖掘系統(tǒng)潛在的風(fēng)險和痛點才能獲得。另外也要不斷向行業(yè)內(nèi)領(lǐng)先的解決方案看齊，了解自己系統(tǒng)存在的差異，才能不斷進步和完善。