新系統重構中，收獲了一個重要的設計教訓。特此記錄。

事情是這樣滴，如下圖所示：

有一個 Hbase 表 oe_item 存放訂單商品相關的交易信息，rowkey 設計為 “訂單號_oldItemID” ，是通過 storm 同步任務處理 old_item 表的binlog訂閱寫入該表的。oe_item 的量級很大。

在老的實現方式中，由於應用在訪問這個表之前無法取到訂單的oldItemID, 因此，需要拿到訂單號去 scan 這個表。顯然這個開銷是很大的。當需要訪問大量訂單的 oe_item 數據時，並發訪問這個表會導致超時，線程被hang住，進而影響系統整體穩定性。若有可能，應該幹掉 scan oe_item 這個威脅系統穩定性的耗時操作。

系統重構後，通過詳情API接口，能夠獲取到新訂單及newItemID, 能夠獲取到老訂單及oldItemId。顯然，對於老訂單來說，可以用{order_no}_{oldItemID}拼成 rowkey 來 batchGet oe_item 表； 然而，對於新訂單，由於無法獲取到oldItemID, 這使得要獲取新訂單 oe_item 表的信息，依然要 scan 這個表，而不能替換為 batchGet, —— 眾所周知, batchGet 操作通常比 scan 操作的性能要更好，獲取大數據量時穩定性更優 ， —— 因此，錯過了優化系統穩定性的一個關鍵環節。是不是很蛋疼 ？

教訓：

1. 要敏銳地主動發現舊設計的一些過時之處。即使當時不能解決，也應記錄下來，當機會來臨時進行重構優化。
2. 在新系統重構中，及時用新設計來取代和兼容老設計。在這個例子中，如果在系統重構中，將 rowkey 設計為 新訂單 -> "{order_no}{newItemID}"，老訂單 -> "{order_no}{oldItemID}"，就可以用 batchGet 取代 scan ，大幅提升系統在獲取大數據量時的穩定性。

一個重要的設計教訓：設計的前瞻性思考