作者 |  字白

一、防御性編碼的意義

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

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

這個文章目的也更多是關(guān)注到“實(shí)操層面”的引導(dǎo)。

二、如何防御性編碼?

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

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

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

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

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

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

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

例子1：

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

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

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

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

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

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

例子2：

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

例子3 :

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

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

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

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

舉個具體例子：

• 初始時，系統(tǒng)的small = 2; large = 2;
• 修改large 鏈路1：準(zhǔn)備將 large 改為 3，檢查規(guī)則 3(改后large ) >= 2(系統(tǒng)small) 通過。準(zhǔn)備寫入新的large (3)。
• 修改small 鏈路2：準(zhǔn)備降 small 改為 4, 發(fā)現(xiàn) 4(改后small)> 2(系統(tǒng)large) 不符合規(guī)則，則 準(zhǔn)備 自動修改 large = 4(改后small)+ 0.1 = 4.1。準(zhǔn)備寫入 改后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ā)送服務(wù)中，控制對用戶的發(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);
}

• 非原子操作問題。

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

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

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

2.事務(wù)問題

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

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

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

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

• 上下文一致性問題。

以上傳并處理Excel文件為例，假如實(shí)現(xiàn)分為 2 步：

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

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

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

• 順序一致性問題。

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

3.分布式鎖問題

分布式鎖日常也經(jīng)常用到，在使用細(xì)節(jié)上存在一些容易忽略的盲點(diǎn)。

• 獲取鎖

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

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

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

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

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

• 鎖超時

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

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

• 釋放鎖

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

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

4.緩存問題

• 緩存穿透問題

緩存和數(shù)據(jù)庫都沒有的數(shù)據(jù)，但被大量請求，導(dǎo)致DB壓力過大。常見的解決方式：對空值也進(jìn)行緩存，但TTL設(shè)置相對較短。

• 緩存擊穿問題

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

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

• 緩存雪崩問題

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

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

• 緩存的一致性

一般情況下，一致性要求不會非常嚴(yán)格。但如果需要強(qiáng)一致性保障時，要考慮緩存和DB之間的數(shù)據(jù)強(qiáng)一致性。

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

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

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

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

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

需要注意的是：

1）緩存針對數(shù)據(jù)庫所有的數(shù)據(jù)記錄，可能導(dǎo)致緩存空間占用高，實(shí)際利用率卻不高。

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

3）如果緩存寫入失敗，需要有相應(yīng)的補(bǔ)償機(jī)制再寫入，且需關(guān)注 補(bǔ)償寫入與其他正常寫入的沖突和時序問題。

• 緩存命中率

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

• 熱點(diǎn)key問題

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

5.失敗處理問題

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

• 失敗處理

可能的處理方式：

1）failover。失敗立即重試。

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

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

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

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

• 注意默認(rèn)值

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

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

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

6.switch配置問題

• 分批推送的時間間隔

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

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

• 內(nèi)存值與持久值

switch的邏輯是這樣：

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

2）當(dāng)在代碼中修改默認(rèn)值時，switch平臺也會顯示代碼默認(rèn)值。此時也并不是 持久值。

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

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

如果你看到switch平臺上展示了開關(guān)值，以為已經(jīng)持久化，然后在代碼里就把默認(rèn)值刪掉，此時也可能導(dǎo)致故障。

• 代碼重構(gòu)注意事項(xiàng)

做代碼結(jié)構(gòu)重構(gòu)時，如果沒有指定switch的namespace，會導(dǎo)致你推送過的持久化開關(guān)失效，進(jìn)而引發(fā)嚴(yán)重的線上故障。

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

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

• 合理使用，避免濫用

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

7.重大風(fēng)險評估和處置

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

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

我們?nèi)绾卧u估 重大風(fēng)險呢?我建議分這么幾個環(huán)節(jié)做評估：

1）梳理 關(guān)鍵的業(yè)務(wù)流。

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

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

4）結(jié)合自己場景，假定 關(guān)鍵邏輯 和 關(guān)鍵上下游 出現(xiàn)極端問題。例如 網(wǎng)絡(luò)掛掉、機(jī)器重啟、高并發(fā)來臨、緩存掛掉等。

這里需要強(qiáng)調(diào)一點(diǎn)，并非所有模塊都需要假定非常極端的情況，要結(jié)合自己實(shí)際業(yè)務(wù)要求、歷史風(fēng)險等 來綜合判斷。

再舉個例子：

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

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

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

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

三、最后

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

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