作者 |  字白

一、防御性編碼的意義

類似于“防御性駕駛”對駕駛安全的重要性，防御性編碼目的概括起來就一條：將代碼質量問題消滅于萌芽。要做到“防御性編碼”，就要求我們充分認識到代碼質量的嚴肅性，也就是“一旦你覺得這個地方可能出問題，那基本它就會(在某個時刻)出問題”。當然，實際情況比這個更嚴峻。由于大家的編碼經驗和風格差異，導致大家的意識邊界是大小不一的，那些潛伏在意識邊界之外的“危險”更加隱蔽和不可琢磨。

在意識層面上，我們當然要摒棄“想當然”和“差不多”的思想，嚴肅評估這些問題發(fā)生的可能性，認真對待這些風險。但如若話題止步于此，那其實還是缺乏執(zhí)行層面的指導意義的，激不起半點“漣漪”的。

這個文章目的也更多是關注到“實操層面”的引導。

二、如何防御性編碼?

以下需關注的具體方面更多來自于我的習慣和觀察，并且統(tǒng)一用偽代碼作問題示例。

歡迎大家把自己的“防御性編碼心得”在評論區(qū)分享出來。

1.并發(fā)沖突問題

這個問題在實際項目中，被錯誤地忽視的比例相當高。它的外在表現形式五花八門，但關鍵點是：“當你的代碼被并發(fā)調用時，它會怎么表現?”

我們心里要有個運行時的世界觀，代碼運行的Context是這樣的：多線程 -> 多進程 -> 多機器 -> 多集群。我們編碼時，要充分考慮代碼在上述世界觀多點并發(fā)的可能性，及相應的潛在后果。

舉幾個具體的問題例子)：

• 存在共享變量 或者 數據。(不限于堆內存，也可能是緩存、DB、文件等)

例子1：

有線程 A 和線程 B 兩個線程，需要更新「同一條」數據，會發(fā)生這樣的場景：

1).線程 A 更新數據庫(X = 1)

2) 線程 B 更新數據庫(X = 2)

3）線程 B 更新緩存(X = 2)

4） 線程 A 更新緩存(X = 1)

最終 X 的值在緩存中是 1，在數據庫中是 2，發(fā)生不一致。

例子2：

// 某個 Spring singleton Bean 'aService' 存在一個調用來源標記，記錄調用來源是HSF還是HTTP。
// 先 記錄來源標記。
aService.setSource(source);
// 再結合source執(zhí)行其他邏輯。例如將上面記錄的source 和 其他參數 插入數據庫.
aService.doSomethings(params);

例子3 :

在一個系統(tǒng)中，有兩個價格類型 small 和 large，業(yè)務邏輯要求 small <= large，且 small 和 large 有2個入口可以分別修改。

目前方案是：對要改變的small或large，增加上面大小關系校驗，不通過則攔截，例如 改動small的入口上，校驗改后的small <= 系統(tǒng)里的large，不通過則不允許修改。

假如，最新需求要求：修改large的入口繼續(xù)攔截，但修改small的入口不再攔截，而是發(fā)現如果改后small > 系統(tǒng)的large，則將 系統(tǒng)large = 改后的small+0.1，讓 約束關系繼續(xù)成立。 這種改法有問題嗎?

答案：這種改法會有問題。即 small這個價格類型存有兩個鏈路同時修改，也是一種并發(fā)沖突問題。

舉個具體例子：

• 初始時，系統(tǒng)的small = 2; large = 2;
• 修改large 鏈路1：準備將 large 改為 3，檢查規(guī)則 3(改后large ) >= 2(系統(tǒng)small) 通過。準備寫入新的large (3)。
• 修改small 鏈路2：準備降 small 改為 4, 發(fā)現 4(改后small)> 2(系統(tǒng)large) 不符合規(guī)則，則 準備 自動修改 large = 4(改后small)+ 0.1 = 4.1。準備寫入 改后small = 4，自動改后 large = 4.1;
• 如果 鏈路2 最終先完成寫入，鏈路1再完成寫入。則 鏈路2寫入的 large=4.1 會被鏈路1 寫入的large=3 覆蓋。最終系統(tǒng) large =3，而 系統(tǒng)small = 4;破壞了最初的small <= large 的約束。
• 未考慮集群并發(fā)。

// 在短信發(fā)送服務中，控制對用戶的發(fā)送頻率
timestamp = rateLimitService.getMsgTimestamp(userId);
if( timestamp == null ){
  rateLimitService.putMsgTimestamp(userId, now);
  sendMsg(msg);
}else if( timestamp - now > 1 hour ){
  rateLimitService.putMsgTimestamp(userId, now);
  sendMsg(msg);
}

• 非原子操作問題。

// 先查詢是否存在目標記錄
resultList = dbRepo.list(query);
// 有結果就更新，沒有就插入
if( resultList.size() > 0 ){
  dbRepo.update(xxxx);
} else {
  dbRepo.insert(xxxx);
}

• 錯誤的發(fā)生并發(fā)

單個任務周期性的觸發(fā)，本來不會有并發(fā)問題。但因單次執(zhí)行時間變長，導致先后兩次執(zhí)行時間出現重疊。

2.事務問題

對于先A再B后C的這類組合操作，要仔細考慮保障一致性的必要性，做好是否做事務保障的評估。

事務即要求：對一組的operation combo，要保障好執(zhí)行順序，保障好context的一致性，保障好結果的一致性。

• 數據庫事務。 發(fā)生概率不高，大多會主動預防。

這個問題發(fā)生概率倒不高，也比較容易解決。但要注意，事務執(zhí)行耗時不要太久，以及避免死鎖問題發(fā)生。

• 上下文一致性問題。

以上傳并處理Excel文件為例，假如實現分為 2 步：

1） 前端調用后端API，上傳文件到Server的某個臨時目錄。

2）前端 在上傳完成時，調用后端另一個API，通知 后端處理此文件。

這個例子在集群環(huán)境中就會出現概率性成功或失敗的情況，集群節(jié)點數量越多，失敗概率越高。這是因為 前端的前后兩次請求調用到了不同節(jié)點上，執(zhí)行上下文出現了不一致。

• 順序一致性問題。

常見的，例如對于 ECS運行狀態(tài)的時序消息，如果下游消費者不是順序消費，而是并行消費，就可能導致最終記錄的狀態(tài) 與實際不符。

3.分布式鎖問題

分布式鎖日常也經常用到，在使用細節(jié)上存在一些容易忽略的盲點。

• 獲取鎖

1）是阻塞式等待鎖，還是等不到鎖重試，還是等不到鎖直接返回。這個層面主要考量點，這個調用鏈路對時間和成功率要求是什么。例如，上游是用戶操作，那肯定不能阻塞在等鎖那里太久;

2）鎖的key設計很關鍵。合理設計lock key，能夠降低鎖碰撞的概率。例如，你的lock 是加在一個BU層面上，還是加到某個人身上，那沖突概率顯然差別很大。

3）對于 持久鎖，在循環(huán)執(zhí)行業(yè)務邏輯時，要做好鎖的狀態(tài)檢查。

 RLock lock = redisson.getLock(lock);
    lock.lock(-1L, TimeUnit.MINUTES);
    // 獲取到鎖就持久占有，避免反復切換
    while( !isStopped ){
         if( lock.isHeldByCurrentThread() ){
              // do some work
         }else{
              // try to acquire lock again. 
         }
         SleepUtil.sleep(loopInterval, TimeUnit.MINUTES);
    }

4）能用本地鎖 不用全局鎖。

• 鎖超時

1）合理設置鎖的TTL，結合自己業(yè)務場景做取舍例如，加鎖之后執(zhí)行大量數據的batch計算的場景。如果鎖TTL太長，那計算被異常中斷(如機器重啟)時，這個長TTL內是無法被其他節(jié)點/線程獲取到執(zhí)行權限的;但如果TTL設置太短，那可能還沒等執(zhí)行完成，鎖就被意外搶走了。

2）注意watchDog機制像Redisson之類的會有鎖的watchdog，超過設置或默認的時間，鎖就被偷偷釋放了。

• 釋放鎖

1）非必要情況下，避免強行釋放鎖，要檢查鎖的持有人是否是自己。

2）對于沒有TTL的鎖，要考慮極端情況下(進程被強制殺死、機器重啟)的鎖狀態(tài)管理。否則意外一旦出現，鎖就永遠丟失了。

4.緩存問題

• 緩存穿透問題

緩存和數據庫都沒有的數據，但被大量請求，導致DB壓力過大。常見的解決方式：對空值也進行緩存，但TTL設置相對較短。

• 緩存擊穿問題

一般是緩存的熱點key發(fā)生過期失效，此時大量請求透過緩存 擊中DB，導致DB壓力過大。

常見解決方式：緩存查詢miss時，設置個互斥鎖，只允許一個request真實請求DB和重寫緩存，避免大量請求涌入。

• 緩存雪崩問題

緩存中的大量數據在較短的時間段內集中過期。一般發(fā)生在流量一波波來，緩存創(chuàng)建時間和TTL很接近。

常見解決方案：在TTL設置上不是一刀切，而是在一個合理范圍內隨機浮動，避免緩存集中失效。

• 緩存的一致性

一般情況下，一致性要求不會非常嚴格。但如果需要強一致性保障時，要考慮緩存和DB之間的數據強一致性。

一種可能的方案：只在寫DB時才寫緩存，讀DB操作不寫緩存。DB和緩存的寫操作要加鎖，避免并發(fā)問題。具體流程如下：

當寫DB請求發(fā)生時：

1）刪除 緩存。此時讀操作緩存會miss，讀取到DB中的老值。

2）寫入DB。此時讀操作緩存會miss，讀取到DB中的新值。

3）寫入緩存。此時讀操作緩存會 hit，讀取到緩存中的新值(與DB新值一致)。

需要注意的是：

1）緩存針對數據庫所有的數據記錄，可能導致緩存空間占用高，實際利用率卻不高。

2）如果某個緩存key 是熱點，或者 流量比較大，盡管緩存“刪除-重寫入”間隔短，依然可能會引發(fā) 緩存擊穿問題。

3）如果緩存寫入失敗，需要有相應的補償機制再寫入，且需關注 補償寫入與其他正常寫入的沖突和時序問題。

• 緩存命中率

這個本身不是問題，但命中率低說明緩存的設計或使用存在問題，需要重新設計。

• 熱點key問題

如果特定緩存節(jié)點CPU使用率遠高于其他節(jié)點，說明可能存在熱點key。這個時候需要合理對緩存key做拆分，將流量進一步打散。

5.失敗處理問題

這類問題雖屬于低級問題，但往往比較隱蔽。在異常發(fā)生時，選擇相應處理action時，我們要頭腦非常清醒。

• 失敗處理

可能的處理方式：

1）failover。失敗立即重試。

2）failback。記錄失敗，后置處理。

3）failfast。直接失敗，返回異常。

4）ailsafe。忽略失敗，繼續(xù)流程。

這里不在于選擇那種處理方式，而是要“頭腦清醒”的結合自己場景需求做出選擇。

• 注意默認值

一些情況下，我們會初始化時設定一些默認值、默認狀態(tài)等，對于這些情況要充分考慮異常發(fā)生時是否存在風險。

例如，在最開始時，代碼里配置了當時的開城信息，但這個狀態(tài)并沒有跟業(yè)務操作流程打通，也就是沒有辦法做到及時更新。

那隨著時間發(fā)展，開發(fā)了新的城市，那就可能產生問題。

6.switch配置問題

• 分批推送的時間間隔

switch發(fā)布時，不同批次會有時間間隔，大部分場景下都可以容忍這個時間間隔。但個別情況下，可能引發(fā)諸如數據不一致等問題。

再使用switch時需要對這個問題做提前考慮，若不能容忍這種情況，那需要更換其他方案。

• 內存值與持久值

switch的邏輯是這樣：

1）switch會默認記錄代碼中的默認值。此時并不是 持久值。

2）當在代碼中修改默認值時，switch平臺也會顯示代碼默認值。此時也并不是 持久值。

3）只有在switch平臺修改值并推送成功，swith平臺會保存持久值。

4）switch保存持久值之后，不管代碼修改默認值還是去掉 @AppSwitch 配置，持久值都是存在的。

如果你看到switch平臺上展示了開關值，以為已經持久化，然后在代碼里就把默認值刪掉，此時也可能導致故障。

• 代碼重構注意事項

做代碼結構重構時，如果沒有指定switch的namespace，會導致你推送過的持久化開關失效，進而引發(fā)嚴重的線上故障。

關于應用級服務發(fā)現與接口級服務發(fā)現的區(qū)別和 dubbo 生態(tài)的解決方案，本文中不多贅述，可以參考劉軍前輩寫的文章文章《Dubbo 邁出云原生重要一步 應用級服務發(fā)現解析》

簡單來說，應用級服務發(fā)現需要開發(fā)者關心接口之外還要關心應用名，注冊中心的冗余信息較少;接口級服務發(fā)現開發(fā)者只需要引入接口名，但注冊中心的冗余信息較多。

• 合理使用，避免濫用

switch 提供了簡單易用的配置化能力，但不要把應該正常編碼要考慮和處理的問題，丟到switch上做開關。否則，最后開關一大堆，維護越發(fā)困難，就隱藏了風險。

7.重大風險評估和處置

針對一個需求開發(fā)，我們需要評估風險及我們的承受能力。主要目的是 預防重大故障的發(fā)生，而不是要預防所有Bug。

關于風險處置，也沒有一個固定的標準。我建議是結合業(yè)務場景，評估風險概率和潛在問題的嚴重程度，最后來制定相應的解決方案。例如，如果發(fā)現有資損風險，那要采取一切手段把漏洞堵上;但如果只是小概率的漏掉釘釘通知，那增加相應的告警即可。

我們如何評估 重大風險呢?我建議分這么幾個環(huán)節(jié)做評估：

1）梳理 關鍵的業(yè)務流。

2）梳理 每個業(yè)務流的關鍵環(huán)節(jié)。

3）梳理 每個關鍵環(huán)節(jié)的關鍵邏輯 和 關鍵上下游。

4）結合自己場景，假定 關鍵邏輯 和 關鍵上下游 出現極端問題。例如 網絡掛掉、機器重啟、高并發(fā)來臨、緩存掛掉等。

這里需要強調一點，并非所有模塊都需要假定非常極端的情況，要結合自己實際業(yè)務要求、歷史風險等 來綜合判斷。

再舉個例子：

假設，有一個用戶資金轉賬系統(tǒng)，用戶可以通過App進行跨行轉賬操作。

那這個系統(tǒng)就要考慮到 轉賬超時、轉賬失敗等場景。同時還要考慮 轉賬超時 或 失敗時，是fail-fast 好，還是 fail-over好?

此外，還需要考慮到 App端的用戶交互設計，假如遭遇網絡中斷或超時，且用戶看不到任何問題提示，那用戶很可能再次發(fā)起轉賬嘗試，最后轉了兩筆的錢。

這個評估過程看上去有點冗長，但其實對于了解自己系統(tǒng)和需求細節(jié)的人來講，應該是很容易做到的。如果做不到那就只能加強細節(jié)的理解和學習了。

三、最后

以研發(fā)同學為中心，向內看：需持續(xù)提升防御性編碼的意識和實操能力;向外看：外部環(huán)境需要盡可能提供與之匹配的環(huán)境。

例如，在面臨有緊急DeadLine的需求時，防御性編碼的執(zhí)行完整度就會受到一定影響。