新系统重构中，收获了一个重要的设计教训。特此记录。
事情是这样滴，如下图所示：
有一个 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 操作的性能要更好，获取大数据量时稳定性更优 ， —— 因此，错过了优化系统稳定性的一个关键环节。是不是很蛋疼 ？
教训：
- 要敏锐地主动发现旧设计的一些过时之处。即使当时不能解决，也应记录下来，当机会来临时进行重构优化。
- 在新系统重构中，及时用新设计来取代和兼容老设计。在这个例子中，如果在系统重构中，将 rowkey 设计为 新订单 -> "{order_no}{newItemID}"，老订单 -> "{order_no}{oldItemID}"，就可以用 batchGet 取代 scan ，大幅提升系统在获取大数据量时的稳定性。