[[356823]]

答：Backend as a Database, Sort Of

直接把 Mysql 暴露在公網給前端使用會有什么問題：

• I/O 邊界 => 性能考慮
  • 批量獲取多條數據
  • 對數據進行 count / sum 等聚合
  • 把聚合結果做提前計算，冗余字段
• 組織邊界 => 安全考慮
  • 數據權限校驗，防止非法訪問
  • 校驗業務規則
    • 產生的訂單價格應該等于商品單價之和
    • 出庫單要創建，需要xxx領導簽字單

要做到 Backend as a "Database"，就是回答以上問題如何解決。

User 表

Mysql / Postgresql 的權限太粗了?？隙ㄊ且?Mysql / Postgresql 外邊套一層去校驗權限。這里有如下的挑戰要解決

• B 端權限需要非常細致，不僅僅要到行，甚至到格。權限可能是按職位授予，也可能是因為工單分配臨時授予。
• 權限校驗開銷不能太大，如果拿來做 C 端業務，單據數量和用戶數量都可能會非常大。要減少因為行級別權限引入的開銷。所以要能按需打開不同的授權模式。
• 沒有登錄的用戶需要登錄，或者能夠匿名瀏覽。如何方便給沒有用戶的訪問做適當的提權。
• 非真實人類用戶的訪問，比如夜間的批處理，需要能夠有機器人的賬號
• 賬號的初始化是如何描述的，誰來分配最初的那個管理員
• 如果有多個 Project，每個 Project 有自己的用戶體系，不同的 User 表。這兩個 Project 要互相訪問，用什么 User 身份?

解決了以上問題，我們就獲得了一個內建權限的“Database”，可以開放到公網給前端訪問。實際拉數據的時候，用的是人類用戶自己的身份。只要用戶自己對要訪問的數據表或者行有權限，就可以訪問到，否則就訪問不到。

業務數據表

寫一個 Typescript 的類，然后把 Mysql 的表建好。和 Java Hibernate 一樣

@Biz.profile('買家', 'read') 
@Biz.profile('店長', 'read', 'create', 'update', 'delete') 
@Biz.profile('管理員', 'read', 'create', 'update', 'delete') 
@Biz.authentic({ rowPolicy: 'public' }) 
@Biz.published 
export class RegionFreightTmpl extends Biz.ActiveRecord { 
    @Biz.lookup 
    public readonly freightTmpl: FreightTmpl; 
    // 計費模式：按件（目前只有按件） 
    public freightTmplType: string; 
    public firstPrice: number; 
    public firstAmount: number = 1; 
    public additionalPrice: number; 
    public additionalAmount: number = 1; 
    public regions?: string; 
} 

查詢的時候直接用這個 class 來指代這張數據庫表就可以了。

視圖表

能夠做好權限校驗的前提是只暴露單表的簡單查詢。那么 count / sum / join 這些怎么處理? 難道是要發明一種 SQL 變種，然后搞 SQL 解析么?

一個簡單的做法就是引入“視圖表”的概念。把這些聚合查詢都建模成一張虛擬的視圖表。這樣在查詢的時候仍然是單表查詢。

• 解決了 rpc 請求的時候如何表達復雜 query 的問題，避免了 sql over http
• 解決了權限校驗難以確定目標是什么的問題

物化視圖表

如果所有的聚合查詢都要按需計算則會非常慢。經常我們需要一些按日期，按維度提前聚合好的中間結果。這個可以用物化視圖表來表達

@(Biz.view`SELECT id, gender, age, city, SUM(OrderItem.cost) AS total 
FROM ${impactSet} 
JOIN ${User} on User.id = impactSet.userId 
LEFT JOIN ${Order} on User.id = Order.userId 
LEFT JOIN ${OrderItem} on Order.id = OrderItem.orderId`) 
@(impactSet`SELECT DISTINCT(Order.userId) AS userId FROM ${ Order }`) 
@(impactSet`SELECT DISTINCT(Order.userId) AS userId FROM ${ OrderItem } JOIN ${ Order } on Order.id = OrderItem.orderId`) 
@Biz.source(Starriness, { dataSource: 'clickhouse' }) 
export class UserWithTotal extends Biz.SqlView { 
    public readonly id: string; 
    public readonly userId: string; 
    public readonly created_at: Date; 
    public readonly total: number; 
} 

物化視圖的問題在于什么時候刷新。通過用 SQL 定義 impactSet，我們可以由 mysql binlog 觸發物化在 clickhouse 中的物化視圖表刷新。

用戶行為表

物化視圖的來源是業務數據。用戶行為因為數據量比較大，不太適合直接插入到 mysql 中。把用戶行為單獨提供一張寬表來記錄用戶做過什么操作。寫入可以是內存緩沖，或者經過 kafka 這樣的隊列緩沖。

寬表的列應該是按業務需求擴展的，如果業務上關心用戶操作的訂單id，或者商品id，則要加上這些字段。大概的 api 也類似 mixpanel 這些老牌分析廠商的上報接口。

物化視圖在計算報表的時候可以 join 用戶行為表和業務數據表來得出分析結果。

批量查詢

一次 rpc roundtrip 只能發一條查詢太慢了。那支持一個數組，一次可以提交多條查詢就好了。至于前端代碼中怎么把多個組件的查詢聚合到一個 rpc 中，這個就看前端的 data query 框架是怎么來弄了。無非就是全局搞個 buffer，在“合適的時候”刷一下這個 buffer，批量查一次。

存儲過程

細粒度的用戶權限只能解決數據完全被一個用戶擁有的問題。很多時候數據是協作數據，有多個 stakeholder，那么就必須經過協商好的規則去修改數據，而不是一個用戶說了算。例如你可以決定今天的日記本里隨便寫啥，但是不能決定把今天晚飯的訂單改成0。日記是你擁有的，但是訂單是多個相關方都關心的。

解決業務規則校驗后寫入的問題就是存儲過程了。前端同學肯定是希望用 javascript 來寫存儲過程。實際上就是所謂 FaaS 的云函數。本質上就是后端代碼仍然有，只是換了一撥人來寫。

如果業務規則比較簡單，例如只是一個狀態機的轉換圖，則可以用配置替代code。當然大部分時候，復雜的業務邏輯，上 javascript 是最直觀的。

Data Migration

數據庫表結構變更了肯定還是要寫 SQL 來升級數據庫的，標準做法沒啥說的。

Backend as a Database

• 用 RPC 接口提供了一個類似 Database 的東西
• 把后端業務切分成了 User表/業務數據表/視圖表/物化視圖表/用戶行為表/存儲過程/DataMigration 等預設的概念，變得更規整
• 除了“需要經過業務規則校驗之后寫入”這個例外，其他的后端接口都不需要上通用編程語言，可以用配置或者SQL定義解決
• 這個解法既不是 GraphQL，也不是經典的 BFF