這一部分主要講模塊化技術(shù)的演變
image.png
上圖展示了我們以前的一個數(shù)據(jù)交互邏輯坯汤，我們是按照頁面來分的接口虐唠，然而，接下去我們的產(chǎn)品做了一個龐大的產(chǎn)品矩陣惰聂，導(dǎo)致我們的頁面迅速膨脹
image.png
為了適配各個端的用戶畫像疆偿，我們在每個端的首頁都出現(xiàn)了差異化的UI咱筛，這就導(dǎo)致我們要為每一個端都寫一個首頁的接口，這會帶來幾個方面的問題
- 隨著產(chǎn)品矩陣的迅速膨脹翁脆，后端的接口會跟著一起增加眷蚓，維護成本是巨大的。
- 前端也是要每次要重新開發(fā)反番，并且沙热，還要開發(fā)埋點相關(guān)的功能。
- 測試的工作量同比增加罢缸。
上述就是模塊化產(chǎn)生的一個背景篙贸，那模塊化是如何來做的呢？
image.png
image.png
我放兩張圖枫疆，有利于快速理解一下模塊化的思路爵川，我進一步講解下
模塊化的整體思路是：面向組件編程
image.png
這套體系解決的問題：
- 不再重復(fù)在頁面的輪子，而是把每個頁面拆分成組件息楔，通過組件的組裝來達到low-code的效果寝贡。
- 前端做組件化，并且將埋點嵌入進組件化中值依，后續(xù)可以做拖拽化圃泡。
- 測試只需要面向組件測試即可，一旦組件通過測試愿险，可隨意組裝颇蜡，無需測試。
通過一個時序圖來解釋這個流程
image.png
上述時序圖辆亏，我解釋幾個地方：
- groupService风秤，這個是面向組件的一個服務(wù)，當(dāng)前階段扮叨，我們是這塊是和plate放在一起的缤弦，為了方便開發(fā)，減少遠程調(diào)用流程甫匹。但本身來講甸鸟，這塊的工作應(yīng)該是含在大前端團隊，由他們來對組件后端進行開發(fā)兵迅。所以，這張圖我還是將groupService拆分出來薪贫，方便理解整體架構(gòu)恍箭。
- plate → groupService，這塊是要并行的瞧省，為什么并行扯夭？因為如果串行鳍贾，一個頁面的組件非常多的時候，這個延時是幾乎不可接受的交洗；因此骑科，我們將所有組件做并行處理，這里我們用了completeService來做并發(fā)的處理（線程池我們設(shè)置為100個core線程构拳，部署了4臺機器咆爽，這個是我們多次壓測得出來了一個值），后面通過遍歷completeService來做結(jié)果集合并置森。PS：這里有一個超時的概念斗埂，防止某個組件卡住，導(dǎo)致整體請求的延時凫海，一般我們設(shè)置為1S呛凶。
- cloudService，則是我們的微服務(wù)行贪，在模塊化以前漾稀，都是gateway直接調(diào)用過來的，模塊化后建瘫，要從groupService調(diào)用了崭捍。
那整體的架構(gòu)圖就是這樣了
image.png
