物流專案已經穩定執行超過一年的時間了，客戶也沒有再提出一些需要核查的問題。直到最近兩天，客戶那邊開始頻繁的讓我們核查一些標籤沒有產生過門事件的問題，這個引起了我們的重視，最終也完美解決，下面簡單說說整個問題的核查和解決思路。
因為筆者之前了解過，客戶曾經使用過非我司製造的標籤，並且該批標籤存在異常，可能無法正確讀取，所以我們這邊最開始的假設是該問題標籤為異常標籤，如果為異常標籤，那麼在網路層就不會讀取到任何明細資料，所以首先核查網路層。
使用linux指令查詢對應epc的網路層日誌，竟然找到了讀取記錄，說明標籤被正常讀取。這個時候就需要核查整個鏈路，看看問題到底出在**，我們繼續核查了最後的**層和storm計算層的相關日誌，一步一步縮小問題圈，最終確定標籤的明細是在storm層消失的。
這個時候筆者比較困惑，標籤沒有產生天線演算法的過門事件，也沒有留痕，那麼到底是在哪塊通過業務邏輯拋棄掉了呢？部長提出了乙個猜想，該標籤是否是繫結的標籤，消失是否和繫結業務相關？於是我核查了redis中儲存的標籤繫結資料，發現該標籤確實是繫結標籤，然後檢視下對應的storm層原始碼中對繫結標籤的業務邏輯處理，問題逐漸明晰。
目前實現的業務流程如下：
客戶在物流門出門時做了繫結業務，但是對應的繫結門出現了問題，無法通過這個門入門，只能通過其他非繫結門入門，導致了問題的產生。
筆者認為，這個問題的關鍵是在軟體的業務邏輯設計時，在一些異常的業務邏輯分支中，沒有和客戶核實清楚應該如何處理。比如這次的問題是，如果繫結門標籤通過非繫結門時應該如何處理，開發草率的認為應該直接拋棄掉這條資料，並且沒有在系統中留下任何痕跡，導致了後面出了問題，排查問題很困難。
和客戶協商後，客戶認為應該加入乙個開關控制是否啟用強繫結判斷，如果現場出現了繫結門無法使用的情況，可以通過這個開關使業務能夠正常流轉下去。但是仔細思考下，其實客戶還是沒有說明，如果強繫結開啟的情況下，標籤如果通過非繫結門，那麼業務邏輯該如何處理？有兩種方式可以處理：
不讓明細資料走天線演算法邏輯，但是在系統中進行留痕
這裡需要考慮客戶使用繫結的原因，客戶之所以使用複雜的繫結和解綁操作，就是為了減少只通過天線演算法而產生的錯誤事件，最終影響客戶的業務結算，業務結算需要保證百分之百正確。但是如果是因為客戶的異常操作導致的，我們也應該盡可能保證讓客戶能夠進行業務結算。
考慮到上面的優點和缺點，我們選擇第一種方式，讓明細資料繼續走天線的演算法邏輯，起碼有大概率可以正常生成事件，減少客戶的損失。
經過這次問題的排查和解決方案，筆者收穫了很多，最重要的是開發時要仔細思考異常業務分支，不能武斷的替客戶做判斷，要和客戶仔細討論，明確異常分支的業務處理，並且通過日誌還是其他方式要在出現異常時能夠可排查可追溯，開發時要更加關注異常分支。
電商物流倉儲WMS業務流程
po資訊核實 po purchase order 客戶發給你的採購訂單 收貨月台 月台也稱為進出貨站台 以下統稱月台 它是指與倉庫相連的線路或進入到倉庫內部的線路，以及線路與倉庫的連線點。月台是物流園區貨物 的入口，也是貨物的出口，是進出貨的必經之地 hub是快遞的概念，有集貨的的概念。hub是物流...
銀行的主要業務流程
1 主體和客體 客戶和會計 櫃員 2 業務發生條件，把業務比作物件 物件由結構和行為構成 結構 憑證和要素，要素涉及客戶的賬號，與之對應的就是會計科目 行為 客戶資金和銀行科目資金，這裡就涉及到了資產負債 共同等科目，以及衍生出的內部賬戶 不涉及利息 和外部賬戶 客戶涉及利息 的概念 有了科目 賬號...
業務流程層的API
netflix api的工程主管daniel jacobson最近在the next web上發表了一篇文章，他表示 我們需要理解誰是api的使用物件，以及他們的使用的方式，並在此基礎上進行api設計。這看起來是顯而易見 理所應當的事情，然而daniel接下來寫道 過去那種傳統的 萬應靈藥 般的面向...