據國家知識產權局公告，中國工商銀行股份有限公司近日取得一項名爲 “基於 SpringBoot 的 web 系統後端實現方法及裝置 “的專利，授權公告號 CN112905176B，申請日期爲 2021 年 2 月。
這項專利很多程序員表示看不懂，或者直接認爲是一個CRUD專利。我作爲一個架構師，嘗試從深到淺的解讀一下這個專利，以及專利背後，工行架構師面臨的架構困境。
從架構觀點來看，此專利本質上“配置驅動的業務開發專利”，用於解決系統架構中易修改性，可觀測的難題。
架構師困境
我們知道，架構主要目標是對軟件系統分解成較小更容易實現的元素，如模塊或者子系統，並能讓這些元素協同完成業務需求，對於通常的程序員視角來說，架構貌似就是畫幾個框，然後連上線即可。
如下是一個分佈式系統最簡單的架構。看着很簡單的倆框一線，但架構師卻需要考慮的非常多，這也是架構師和普通程序員區別
A服務的架構師需要考慮
- 如果服務B不可用，服務A如何保證高可用.比如宕機，故障，虛機漂移，網絡故障
- 如果服務B出現阻塞，性能下降，服務A如何保性能不受影響
- 服務A調用服務B，是否一定需要等待服務B的響應，能否解耦A和B調用，避免前面2個問題
- 服務A如果是通過其尋址服務到B，如果尋址服務不可用，如何調用服務B
B服務作爲服務提供者，架構師需要考慮的更多
- 如何保證服務B支持大併發的操作
- 如何保證服務B支持大流量操作，甚至是不正常突發高流量下仍然可用，比如斷網恢復後的高流量
- 如果服務B的下游不可用，如何給服務A提供可用接口
- 服務B的更新重啓，會對服務A產生什麼樣的影響
- 如何可觀測服務B的調用
- 如果服務B是公網服務，如何保證安全，數據被授權用戶獲取
B服務架構師還需要考慮意外情況，如服務A的BUG
- 服務A應該只調用服務B一次，但實際服務A調用了多次
- 服務A調用頻率應該是1分鐘一次，但實際1秒一次
- 服務A應該先後順序調用B倆次不同接口，但調用順序相反。這種可能是A的Bug，或者是事件驅動架構裏順序問題。
對這種“倆框一線”如此簡單的架構，可以看到架構師相比於初級程序員，需要考慮較多，需要考慮10+種情況。這種考慮其實也不是架構師撓禿頭髮想到的，而是基於技術架構的架構質量考慮的，有種說法，說是架構質量驅動了架構設計（ADD）。
我認爲現在的大部分系統都受到如下架構質量的驅動
- 架構的高可用：是系統能夠正常運行的時間比例。可用性999，即99.9% ,一年出故障時間爲8.76小時。
- 架構的高性能：系統的響應時間. 相比單體系統，微服務架構，實現一個功能需要調用若干微服務，每個微服務性能影響了系統響應速度。 一個衡量性能的指標TP95 。
- 架構的可觀測：通常架構的可觀測指的是能觀測到系統運行情況，粗到監控服務的主機指標，或者每個服務調用次數，細到監測和統計某個關鍵邏輯調用次數，時長等等。
- 架構的可修改，比如通過可配置實現系統的可修改，其他還包括使用EventBus，使用代理（如API網關），使用DSL語言（最著名的DSL應該是SQL了,屏蔽了不同數據庫差異)，使用腳本引擎，使用classloader，dcevm等熱加載技術。
其他架構質量還有可部署，可配置，可升級，跨平臺，易用性等。可參考 自動源代碼質量度量（ISO/IEC 5055）,每個質量屬性都對應了大量的軟件技術戰術和實現，但因爲篇幅有限，且不是此的重點內容，在這裏不再像詳細敘述。
針對工行的專利，之所以前面要這麼囉嗦的提到架構的質量，是因爲我認爲工行的專利背後，是其工行架構師是解決工行業務系統的架構的倆個質量屬性
- 可修改性：當業務需求變化，系統如何能快速調整上線。不需要開發，甚至不需要重啓系統，業務變動也能通過灰度上線，或者能回滾。
- 可觀測，這裏的可觀測，指的是業務變動的可觀測，系統經歷了多少次業務變動，每次變動，系統做了什麼調整
專利解讀
在文章開頭·，提到了專利的本質是“配置驅動的業務開發”，可以從專利摘要中解讀出來
本發明公開了一種基於 SpringBoot 的 web 系統後端實現方法及裝置，其中該方法包括：接收頁面顯示層上送的操作數據；從操作數據中提取操作數據對應的業務 ID 和維護對象 ID；從數據訪問層存儲的業務參數表中，獲取與業務 ID 對應的配置信息，所述配置信息包括不同數據字段各自對應的業務處理邏輯、每個數據字段所在的數據表，以及每個數據字段與數據表中表字段的映射關係；將維護對象 ID 和業務處理邏輯組合爲條件表達式；利用所述條件表達式處理所述操作數據。本發明可以減少後端業務層在開發過程中的變動，降低開發成本，同時提升系統的穩定性。
注意到專利提到了維護對象ID和業務ID，維護對象就是CRUD的目標對象，業務ID則告訴瞭如何CRUD，業務ID最終將生成多個SQL語句(專利中提到的條件表達式)。這種生成是自動的，基於業務ID相關配置，這也是我說的專利本質是配置驅動開發。以專利中的例子做說明，業務提交如下數據
{
sys_busi_id:"31000",
data_inf:{
stu_name:"張三",
stu_sex:"男",
address:"xxxxx"
}
}
工行的系統，通過sys_busi_id，可以將頁面提交的對象映射成倆個sql語句並執行，這樣，不需要後臺程序員開發任何代碼
insert into stu ("id","name","sex") values (?,?,?);
insert into stu_address ("address","stu_id") values (?,?)
講到這裏，你可能比較疑惑，如何生成SQL語句和相應的參數呢，這專利中並沒有提到。這可能是在其他專利中，或者是此部分實現已經基於某個開源實現。 或者我認爲這是系統更核心部分，過於強大，不方便對外公佈。我這裏列出供參考的開源實現，如
- APIJSON, 騰訊公司開源的工具，零代碼、全功能、強安全 ORM 庫 ，後端接口和文檔零代碼，前端(客戶端) 定製返回 JSON 的數據和結構
- 低代碼平臺，如JEECG等低代碼開源平臺，無需編碼即可實現全棧業務功能。
回到業務ID，上面說了專利並沒有講清楚業務ID是如何維護。但跟普通的對象ID一樣，也是需要增刪改查，保持歷史版本以支持可觀察，以及可回滾。業務ID的數據結構是一個配置，類似如下JSON ( 注意：以下JSON是我的想象，並非專利一部分“）
{
sys_busi_id:"31000",
mapping_table:{
stu:["stu_name","stu_sex"],
stu_address :["address"]
},
validate:{
"stu_sex":{"in":["男"，"女"]}
"address":"@adressExpression(?)"
}
}
上面的json格式中，mapping_table指示瞭如何字段映射到數據庫表中，validate則指示了入庫前，服務端如何校驗數據。這推測這裏的validate有可能複用了Spring Boot 的validation starter。
如果你還能耐心讀到這裏，你可能更加疑惑，維護業務ID豈不是非常麻煩。答案：是的。 想來工行的架構師設計出來的這套系統，程序員都需要了解這一套新的這種DSL而不是用Java做CRUD（上面的JSON，我在架構的可修改裏提到過DSL），學過SQL都知道SQL還是比較難學， 學習一套處理業務的專用DSL更難，其他難點還有
- 是否有可視化界面管理這些配置對象”業務ID“，比如可視化界面建立業務對象和數據庫表的映射
- 如何驗業務ID的正確性，比如上面寫的"@adressExpression(?)"，程序員少寫了個”d“
- 即使有可視化界面，最終也要導出成DSL，在驗收或者生產環境上執行生效，DSL語言可能非常難學，可能工行還會有JSON Schema用來驗證DSL
- 這種DSL需要有版本概念，這在專利中沒有看到提到，但想來應該爲了能查看歷史，回滾，支持版本概念，就像代碼的版本控制一樣。
- 業務ID的修改和上線，應該有一個完整的流程，涉及了產品，QA，項目經理等人審批，發佈上線。可能還需要跟工行已有的DevOp系統結合起來。
可以看到，此專利應該是工行系統的冰山一角，想必他們也付出了很多年的積累。
結論
儘管維護業務ID非常麻煩，程序員覺得得不償失，但架構的可修改性和可觀測得到了滿足。對於工行這樣一個大體量的公司和它的大體量系統，這個投入還是不虧的，這也是爲什麼此基於配置驅動開發的系統能在工行應用並申請爲專利的原因。此專利顯示的系統相比起其他低代碼平臺，功能弱一些，但基於工行特定應用，應該是能滿足的架構可修改性和可觀測
作者本人： 閒大賦（李家智），Java工作經驗24年，在多個行業頭部企業擔任架構師，寫個3本Java書，以及Beetl和BeetlSQL開源作者。