業務架構淺談

摘要： 一、序章 一般的工程師接觸到的是應用架構 ，傳統的MVC分層架構、事件驅動架構等等。第一次接觸業務架構這個概念是在來到商品釋出團隊之後。商品釋出是一個業務屬性很重的系統，承載了淘寶、天貓、盒馬、魅力惠、汽車、虛擬、SCM自營、蘋果、村淘、公益 、教育等諸...

一、序章

一般的工程師接觸到的是應用架構 ，傳統的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確定後，對應的元件集合，擴充套件點集合，流程配置也就確定了。

1. 元件

業務需要的元件 = 業務定製元件 + 需要的平臺通用元件

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