業務架構淺談
一、序章
一般的工程師接觸到的是應用架構 ,傳統的MVC分層架構、事件驅動架構等等。第一次接觸業務架構這個概念是在來到商品釋出團隊之後。商品釋出是一個業務屬性很重的系統,承載了淘寶、天貓、盒馬、魅力惠、汽車、虛擬、SCM自營、蘋果、村淘、公益
、教育等諸多業務(業務多的圍起來可以繞地球一圈)的商品釋出功能。頭半年對“業務架構”還是很懵逼的,隨著慢慢的熟悉業務,研究框架程式碼,才對我們的業務架構框架有了清晰的認識。
二、單體應用的痛點
在GPF框架(我們團隊的業務架構框架)誕生前,上述的所有業務都在一個單體應用裡承載。每新加一個業務,我們的應用工程就會變得更加的臃腫,軟體熵變大,程式碼難以維護,不少類都有幾千行以上。不同的業務程式碼都雜糅在一個類或者一個方法裡。
以商品上架時間元件為例,當我們承接教育行業時,我們的程式碼會做如下的改動(為了方便理解,我把原始碼改成了虛擬碼):
<code>/** * 初始化商品上架時間: * 1)教育業務釋出,開始放入倉庫中,且不可修改 * 2)其他業務立即上架 * @return */ private int initStartTime(){ if("業務身份" == "教育" && renderStatus.isPublish()){ velocityContext.put("startTimeReadonly", true); return “放入倉庫”; }else { return “立刻上架”; } } </code>
每承接一個新的業務,我們都要新增很多if else式的打補丁程式碼。嚴重違反了開閉原則 ,這種寫法是典型的程式碼壞味道。當承接的業務越來越多時,系統變的越來越龐大。不管是承接新的業務還是對老的業務進行改動,都越來越麻煩。馬老師說:
抱怨越多的地方,機會也越多。
這句話對軟體工程同樣適用。為了解決單體應用架構的痛點:新增業務就給老程式碼打補丁。實現業務程式碼給力功能的GPF框架面世。
新架構的核心訴求:業務隔離 。更加具體一點,程式碼隔離,配置檔案隔離,執行時流程隔離。圍繞業務隔離這個核心訴求,其實我們做了更多的事情,這個後面講。
三、如何做到業務隔離
我們給每個業務身份建立一個模型,並配一個業務id。業務模型包含這個業務要用到的元件,擴充套件點,流程配置。所有業務身份構成一個業務身份列表。每個業務模型都有一個業務識別邏輯——當前使用者請求是否命中該業務。使用者請求進來時,都會走一遍這個路由演算法,以確定唯一的業務身份。
唯一的業務身份id確定後,對應的元件集合,擴充套件點集合,流程配置也就確定了。
1. 元件
每個業務的釋出頁都由十幾個到幾十個元件構成。這其中有平臺通用的元件,比如說商品標題,商品條形碼,類目屬性,銷售屬性,sku等全行業都需要的業務元件。垂直業務有垂直業務的定製元件,比如說公益業務有捐贈金額的元件,除了公益業務,其他業務不可能用到這個元件;盒馬業務有商品所屬門店,管理機構等新零售行業特徵的元件。
業務需要的元件 = 業務定製元件 + 需要的平臺通用元件
2. 擴充套件點
這裡的擴充套件點可以理解為外掛(plugin)
-
擴充套件點
- 元件擴充套件點
- 流程擴充套件點
擴充套件點同組件一樣,也是有平臺通用擴充套件點和業務定製擴充套件點構成。
業務需要的擴充套件點 = 業務定製擴充套件點 + 需要的平臺通用擴充套件點
3. 隔離方案
通過上述可以發現,平臺通用的擴充套件點和元件是程式碼複用的!並沒有達到之前的程式碼隔離要求。解決方法也簡單:系統初始化時,每個業務身份id都會new一份通用元件和擴充套件點,並merge自己的定製元件和擴充套件點。於是,記憶體裡,每個業務身份id都會有一套執行時的獨立且完整的元件和擴充套件點集合。系統真正執行的時候,取到的是元件和擴充套件點的物件,並不是程式碼。這樣,程式碼複用,業務資料隔離。這才是最合理的方案。
四、如何做到靈活易接入的中臺化產品
僅僅達到業務程式碼解耦並不夠,商品釋出系統要做一個中臺化 的產品。能夠快速的支援新業務接入,讓新的業務一起共建甚至新業務的同學獨立的在GPF框架上接入他們的業務,是我們的目標之一。要做到高擴充套件,快速接入新業務,這裡不得不提到ofollow,noindex">“微核心 + 外掛化” 技術。
微核心技術:
微核心是核心的一種精簡形式。將通常與核心整合在一起的系統服務層被分離出來,變成可以根據需求加入外掛 這樣就可提供更好的可擴充套件性和更加有效的應用環境。使用微核心設計,對系統進行升級,只要用新模組替換舊模組,不需要改變整個作業系統。
GPF微核心會暴露一系列的SPI(Service Provider Interface)介面,不同的業務按需去實現這些外掛介面。系統啟動時,程式掃描出所有實現了SPI介面的外掛,並整合到系統中對外提供服務。當新業務需要接入時,定義好一個業務身份,同時實現需要的SPI介面,即可完成業務的接入,同時做到業務的隔離。
五、 結語
架構不是設計出來的,是演進而來的。演進式架構才有生命力。從Xsell 到 GPF1 GPF2 GPF3, 每個版本我們都解決了前一個版本的痛點同時往前看半步。一個產品要走平臺化道路,業務架構一定是標配。
——————— 本文來自 bruce128 的CSDN 部落格 ,全文地址請點選:https://blog.csdn.net/bruce128/article/details/82871316?utm_source=copy