建站
咨詢
售后
建站咨詢
新聞中心
本文轉載自微信公眾號「編了個程」，作者Yasin x 。轉載本文請聯(lián)編了個程公眾號。
成都做網(wǎng)站、成都網(wǎng)站制作介紹好的網(wǎng)站是理念、設計和技術的結合。成都創(chuàng)新互聯(lián)擁有的網(wǎng)站設計理念、多方位的設計風格、經(jīng)驗豐富的設計團隊。提供PC端+手機端網(wǎng)站建設，用營銷思維進行網(wǎng)站設計、采用先進技術開源代碼、注重用戶體驗與SEO基礎，將技術與創(chuàng)意整合到網(wǎng)站之中，以契合客戶的方式做到創(chuàng)意性的視覺化效果。
最近業(yè)務上用到比較多的多版本場景。這里總結一下多版本業(yè)務模型設計的思路。
多版本需求梳理
先梳理一下多版本的一般訴求：
- 同一個數(shù)據(jù)經(jīng)過多次編輯后，會產(chǎn)生多個版本，其中歷史版本不能刪除掉，因為可能有上下游在使用；
- 多版本通常用于配置中，最新一個版本的配置通?？梢远啻涡薷?、測試，確定后再發(fā)布；
- 已經(jīng)發(fā)布的歷史版本不能隨便修改，因為有數(shù)據(jù)在使用；
- 在消費側，一般默認是使用最新已發(fā)布的版本；
- 多版本可能會有發(fā)布審批、與上一個版本的diff等需求場景；
多版本狀態(tài)機設計
一個多版本的業(yè)務模型，通常會有以下的狀態(tài)機。其中“廢棄”不是必須的，回滾操作也不是必須的（回滾操作會給代碼和表設計帶來很大的復雜性），發(fā)布中間可能會有發(fā)布中、審批中等狀態(tài)。
草稿可以在原版本編輯，但已發(fā)布的數(shù)據(jù)再編輯，就會生成一個新版本的草稿。
有時候也會有下線操作，這個時候所有版本的狀態(tài)就會被改為“已下線”。
多版本表設計
對于多版本而言，你需要有一個唯一標識這個業(yè)務數(shù)據(jù)的字段，可以叫id?或者code。
同時，需要一個字段來標識版本，這個版本建議是一個遞增的數(shù)字，叫version?。有些業(yè)務期望版本是業(yè)務輸入的，或者有一個版本說明的概念，那可以新增一個字段叫version_desc。
我們可以把唯一標識和版本拼接起來，作為這個數(shù)據(jù)在這個版本的唯一鍵，可以叫code_version?。通常是拼接成一個字符串，中間用某種特定的分隔符來區(qū)分，比如#?。那code_version?可能就長這樣：A12334#3?。這里就要求code?里面不能有分隔符#，不然代碼邏輯處理起來就比較麻煩。
這里說一下這個拼接字段的必要性，因為上下游往往會存code + version。那上下游在列表查詢等場景來查詢數(shù)據(jù)的時候，如果沒有這個字段，只能循環(huán)一個個查，不能用where批量查詢。
另外一個必要的字段就是status來標識當前版本的狀態(tài)。
還有一個非必須的字段is_last_version?，用來標識當前這條數(shù)據(jù)是不是它的最新版本，無論是草稿態(tài)還是已發(fā)布還是已廢棄，它都會變成true。這里在待會兒下文的查詢要點中會解釋它的用處。如果不用這個字段也能查，但是需要group by order，整體查詢語句麻煩，效率低。在寫的時候多維護一下這個數(shù)據(jù)，會讓查詢的時候方便很多。
其它的都是審計字段了。最終的建表語句可能長這樣：
CREATE TABLE `t_xxx`
(
`id` bigint unsigned NOT NULL AUTO_INCREMENT COMMENT 'ID',
`code` varchar(255) NOT NULL DEFAULT '' COMMENT 'code',
`version` int NOT NULL DEFAULT 0 COMMENT '版本',
`version_desc` varchar(255) NOT NULL DEFAULT '' COMMENT '版本說明',
`code_version` varchar(255) NOT NULL DEFAULT '' COMMENT 'code和版本',
`is_last_version` tinyint NOT NULL DEFAULT '0',
`status` varchar(255) NOT NULL DEFAULT '' COMMENT '狀態(tài)',
# 以下是業(yè)務字段...
`name` varchar(255) NOT NULL DEFAULT '' COMMENT '名稱',
# 以下是審計字段...
`create_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '創(chuàng)建時間',
`create_by` varchar(10) NOT NULL DEFAULT '' COMMENT '創(chuàng)建人',
`modify_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '修改時間',
`modify_by` varchar(10) NOT NULL DEFAULT '' COMMENT '修改人',
`deleted_at` bigint DEFAULT '0' COMMENT '刪除時間秒時間戳',
PRIMARY KEY (`id`),
UNIQUE KEY `uk_code_version_deleted_at` (`code`, `version`, `deleted_at`)
) ENGINE = InnoDB
AUTO_INCREMENT = 5
DEFAULT CHARSET = utf8mb4
COLLATE = utf8mb4_0900_ai_ci COMMENT ='xxx表'
生產(chǎn)端和消費端的查詢要點
生產(chǎn)端就是配置數(shù)據(jù)的地方，消費端就是使用的地方。生產(chǎn)端和消費端有一些區(qū)別，生產(chǎn)端往往要看最新的版本，包括草稿等狀態(tài)，還要能修改。而消費端一般只用最新已發(fā)布的版本。
生產(chǎn)端
生產(chǎn)端的查詢，可以按照is_last_version為true來過濾，這樣就只查每一個code的最新版本的數(shù)據(jù)。
同時，每個code也應該返回一個version?列表，是這個數(shù)據(jù)code_version的集合，以便用戶查看和跳轉歷史版本。
生產(chǎn)端的寫入，需要維護好狀態(tài)、版本、is_last_version等字段。在編輯的時候，要判斷當前的狀態(tài)是草稿態(tài)還是已發(fā)布，如果是已發(fā)布，是要創(chuàng)建一條新的記錄（當然這個在前端判斷也是可以的，但后端要做好校驗，防止頁面沒刷新等場景造成臟數(shù)據(jù)）。
消費端
消費端的查詢，需要查詢最新已發(fā)布版本，一般是通過狀態(tài)來過濾，比如status = Online。
但這里根據(jù)狀態(tài)過濾有一個問題：歷史已發(fā)布的版本怎么辦？如果一個code發(fā)布了3個版本，那豈不是會查出來3條數(shù)據(jù)？要解決這個辦法有兩種思路：
- 狀態(tài)機添加一個Online_history的狀態(tài)，在寫入的時候維護這種狀態(tài)；
- 表增加一個is_last_online_version，在寫入的時候維護這個字段；
我個人比較喜歡用第一種方案，少維護一個字段，僅僅多維護一個枚舉就行了。
其它注意事項
上下游
我們在上下游的接口交互中，除了要根據(jù)code?查最新已發(fā)布版本這種消費端場景外，通常用code_version來交互。這樣在DB中可以直接命中一條數(shù)據(jù)，查詢起來也方便。
這個數(shù)據(jù)和其他數(shù)據(jù)的關系，也通常使用code_version來存，因為不同版本關聯(lián)的數(shù)據(jù)可能不同。
diff
diff往往是利用領域模型json化后來diff。這里的diff能力可以做成一個通用的服務，傳入old json和new json，返回哪些是新增的，哪些是刪除的，哪些是變更的。內(nèi)部的邏輯一般是利用json_path和遞歸的方法來做。
diff的難點是做成配置化，配置哪些屬性參與diff，哪些屬性ignore diff。diff出來之后，可能枚舉等需要key轉換成label，外部有一個轉換函數(shù)，或者前端去轉。
另一塊需要注意的就是數(shù)組的順序。有些字段雖然到json是數(shù)組，但業(yè)務上本身是順序無關的，這種數(shù)據(jù)的比對會更麻煩一些。
回滾
回滾其實很麻煩，包括已發(fā)布的回滾到上一個版本、發(fā)布中的回滾到草稿態(tài)。主要是前者很麻煩，尤其是有上下游使用了這個版本的數(shù)據(jù)，一般是不允許輕易回滾的。
如果有這類場景，多半是沒有上下游，比如服務發(fā)布、應用發(fā)布等。這種回滾，當前版本的數(shù)據(jù)一般也不會刪除，而是設置成一個特殊的狀態(tài)。下次編輯上一個版本的時候，生成的version也不是+1， 而是+2甚至是+n，還得查一遍庫，比較麻煩。
所以如果不是有特殊的需求，可以不做已發(fā)布的回滾，它會帶來很多復雜性。
分享題目：聊聊多版本業(yè)務模型設計
瀏覽地址：http://www.5511xx.com/article/cceshoc.html
