昀哥 2020年10月23日
一，開展詳細設計之前請先把大的設計原則寫下來
每一位設計師都需要知道這個常識：
當你開始構建或重構一個復雜系統的時候，請先把大的設計原則寫下來，然后在這些設計原則的框架內做推演。
而不是這種常見的工作方式：
根據需求分析，天馬行空，想到哪兒是哪兒，給出一個設計方案，自己做一番推演之后，自我感覺良好。
阿里巴巴資深技術專家畢玄這樣總結自己的系統設計方法：
回顧了下自己做過的幾個系統的設計，發現在自己在做系統設計的時候確實是會按照一個套路去做，這個套路就是：
系統設計的目的->系統設計的目標->圍繞目標的核心設計->圍繞核心設計形成的設計原則->各子系統、模塊的詳細設計。
二，訂單與交易的設計原則，我們可以寫在設計文檔的前面，作為總綱
設計原則一：歷史可追溯、可還原、有快照！
進一步說明如下：
互聯網核心服務很容易產生數據不一致，一旦出現數據不一致，一定要有旁證來修正，這個旁證盡量不要是文件日志，否則會累煞人。
數據庫中關鍵記錄的關鍵字段，原則上不允許直接修改歷史數據。這里的“直接修改”指的是，沒有把變更行為記錄到操作日志表里，而是直接在原始記錄上 update 甚至 delete，這種“毀屍滅跡”是明文禁止的，即使留下了文件日志也是不允許的。
對此注意兩點：
第一，修改關鍵記錄的關鍵字段時，必須在操作日志表里保留變更日志（old value和new value），並記錄發起人、操作人和發起系統，一定要確保歷史可回溯、可還原、有快照。
第二，嚴禁對關鍵記錄做物理刪除，只能是軟刪除。
商品中心、訂單中心、庫存中心等中心服務要記錄清楚商品核心屬性、訂單核心屬性、庫存的每一次變更，強調記錄“過程”，而不是僅僅在“結果”上Update（即覆蓋）。
比如說每一次庫存增減、盤點（盤盈盤虧）等變更，在哪一個系統發起的，哪一個操作員發起的，因為什么原因變更（有變更類型），從什么變成了什么。這樣記錄下來之后，如果從某一天上線之后引入了BUG，就能夠追溯所有變更，並能夠徹底地還原數據。
比如說對於記錄了訂單信息的 order_info 表，會員如果點擊使用賬戶余額支付了訂單的應付金額，那么該訂單操作日志表就會做如下記錄，原訂單記錄的重要字段（what）由誰（who）因為什么（why）在什么時候（when）從什么變為了什么（how），都會詳細記錄。
設計原則二：接口從一開始就要做冪等性和防並發（這倆本質上是一回事）！
特別說明：所有與支付交易相關的訂單，都必須有一個全局唯一的clientOrderID（或者叫客戶端流水號），作為客戶端提交時的冪等性依據。
為什么特別寫這個說明，因為我們有兄弟公司的重復扣款事故，短短幾個月內已經連續三次了，就是因為他們沒有設計客戶端流水號，無法利用客戶端流水號在服務端、或者在定時任務里阻止重復提交或重復扣款：
a) 某日，掃臉后，收銀員“手抖”致“雙擊”確認按鈕（在彈出對話框之前），導致重復扣款；
b) 離線支付又出現重復交易；
c) 某日系統定時自動補扣時，補扣慢，現場運營人員擔心用戶欠費影響就餐，所以在商家中心后台點擊了手動補扣，導致重復扣費；
三次重復扣款分別在三個業務邏輯上，其實背后是一個毛病。
設計原則三：要求必須建立校驗訂單交易數據一致性的定時任務，做數據補償！
進一步說明：以數據庫操作日志為依據，校驗單個訂單、交易的各項數據是否一致，如果發現不一致，第一要告警，第二盡量自動修復，比如說原路退返。
設計原則四：凡是收銀系統最終肯定是要接入異地雙活體系的，這是躲不過去的，因為單機房是不可靠的！
進一步說明：由於我司有異地雙活機制，所以與訂單操作、資金賬戶划轉、券操作等敏感操作的設計都需要提前考慮雙活，免得回頭還要推倒重做。
比如說訂單號、券號、卡號等序列號的生成規則里，都應該有機房ID，能看出來這個訂單是在哪一個機房生成的。
舉例：我們某團隊利用Twitter SnowFlake算法生成如下規則的訂單號：
25位 = 時間戳（13位）+機房ID（2位）+容器ID/IP（5位）+線程號（2位）+序列號（3位）
某團隊的雲小盒訂單號規則為：
起始位固定2（1位）+日期（6位）+根據商戶ID獲取hashRoute（2位）+步長（7位）+機房ID（1位）
比如說事先划定“多活表”（如訂單表和退款表）、“非多活表”（如隊列表）和全局表（如支付配置表）。
設計原則五：數據庫設計和變更必須提前與DBA溝通！
進一步說明：
大表（如訂單表）上預留足夠多（如10個）擴展字段，后期復用時改字段名即可，不影響業務，無需停服。
大表真的被迫加字段的話，請提前一天加好，不要與上線動作綁在一起。
大表加字段，選擇凌晨執行，因為以5G的數據量為例可能耗時10分鍾左右，對業務有致命影響。
異地雙活里，對於雙活數據庫而言，有主機房概念，如果先在主機房的雙活數據庫上做表結構變更，會導致otter同步中斷，所以請先變更從機房的雙活數據庫的表結構，然后再變更主機房的。
三，回顧訂單與交易上容易發生的錯誤
經典錯誤一：高並發高性能的競爭環境，設計方案完全不同，大家一定要畫時序圖，而不是流程圖。
進一步說明：分布式系統最常見的就是未能做到防重復提交和防並發提交。這是傳統軟件開發者轉入互聯網開發時最容易犯的錯誤。
做系統設計時，最好畫業務時序圖。
通過時序圖的輔助，以及同事的設計評審，能幫助你想清楚你的業務依托哪些點上的原子級操作來阻止重復提交和並發提交。
經典錯誤二：主從延遲問題，是傳統軟件開發者轉入互聯網開發時最容易犯的第二個錯誤。
進一步說明：當讀寫分離成為常態時，低估了數據庫主從延遲對代碼的影響。
開發者特別容易進入如下陷阱：
代碼A向主庫寫入一條記錄，立即通知代碼B；
代碼B去從庫查詢，由於主從延遲（比如大於半秒），沒查到記錄；
於是代碼B報錯。
經典錯誤三：不了解線程安全
進一步說明：
《RCA：轉換日期格式線程不安全導致支付時間錯誤》：SimpleDateFormat 類的 java doc 中明確指明該類非線程安全，多線程情況下需要同步處理或者每個線程創建一個實例。
《RCA：TaskMall線程不安全致死循環》：HashMap 是線程不安全的，如果多個線程對 HashMap 做 put 和遍歷操作，就有可能出現 HashMap 中的 Entry 實例的 next=它自身，導致死循環，cpu 空轉。
經典錯誤四：先刪除舊值，再插入新值
進一步說明：剛刪了舊值，服務就宕機了，導致新值也沒插入。
大家可能會覺得這是廢話，但總是有先刪后插的程序員。
舉例：當年商品手動排序頁面交互中，
——當點擊“提交排序”時，先把舊排序序位刪掉，再把提交的新排序序位存入；
——當程序有BUG時，舊排序序位刪掉了，但接下來程序爆出異常而中斷，導致新排序未存入。
……
之前我寫過《鄭昀：技術人間自有法則在》，不妨對照着看看，再想想你的設計有沒有遵循什么原則、什么法則，有沒有腳踩西瓜皮滑到哪里算哪里？
-EOF-