2019年開始丑掺，業(yè)務(wù)開始了突飛猛進(jìn)的發(fā)展，我們的日活基本在30~100萬之間品山，需求越來越多胆建、越來越復(fù)雜，尤其是面向UI交互的變化是非常頻繁的肘交，光詳情頁就有9個版本之多笆载。
面對這類問題，技術(shù)童鞋應(yīng)接不暇涯呻，各種特判滿天分凉驻，微服務(wù)直接面向上游的UI交互的時候，明顯對業(yè)務(wù)的理解是很吃力的复罐；
例如：我們在評估的詳情頁改造的時候涝登，在詳情頁加一些用戶的信息、加一些商戶的信息效诅，前端雖然知道要哪些信息胀滚，但不知道去找誰要接口咳短，于是，每次評審只能拉上一大堆后端蛛淋，通過PRD一起討論，誰提供哪些信息篡腌。而實(shí)際推進(jìn)工程中褐荷，后端的思路就是，我只是信息提供方嘹悼；所以叛甫，大伙的配合度很低，并且后端也沒有動力去了解需求背景杨伙，導(dǎo)致需求經(jīng)常因?yàn)楹軝C(jī)械的協(xié)調(diào)其监，出現(xiàn)“生硬”的交互。
于是限匣，我們提出了一個概念：“大前端”抖苦。
大前端的普遍理解是，大前端是前端和客戶端的集合體米死，而我認(rèn)為的大前端則是：“面向交互編程”的團(tuán)隊(duì)锌历，而大前端團(tuán)隊(duì)一樣會有后端，這些后端則是要面向交互編程的峦筒。
我們成立了一個大前端的虛線組究西，將后端的一部分業(yè)務(wù)sense比較好的人放進(jìn)來，讓他們來參與面向交互的開發(fā)物喷；這樣的話卤材，后端的資源協(xié)調(diào)一律可以以大前端的后端團(tuán)隊(duì)來做，解放了前端很多的精力峦失。
但我們還面臨著另一個問題扇丛，就是面向各類業(yè)務(wù)的特判，還是會放在微服務(wù)中宠进，這導(dǎo)致微服務(wù)既要處理面向交互的特判晕拆，也要處理業(yè)務(wù)流程。這個問題是剛才的分工無法解決的材蹬；面對越來越多的特判邏輯实幕，代碼的難度、易讀性堤器、測試的工作量成指數(shù)上漲昆庇；于是，我們就開始了建設(shè)中臺闸溃，把各個服務(wù)之間的通用邏輯下沉整吆，個性化的邏輯上浮的各個業(yè)務(wù)端拱撵。
我們進(jìn)一步將后端進(jìn)行垂直拆分，把做中臺的和做業(yè)務(wù)的分開表蝙，中臺負(fù)責(zé)向業(yè)務(wù)賦能拴测，提供通用核心能力；各個業(yè)務(wù)線基于中臺的能力府蛇，開發(fā)自己的特判邏輯集索，并向上提供組件。
后端的架構(gòu)來一張整體的全景圖（缺少UI面向交互編程的后端邏輯汇跨，這塊我伴隨著模塊化的思路去講解）：
