江苏龙网

  1. 首页 > 人文 > >

『设计』解密「零售」系列（二）：产品架构( 三 )


所以通常提供订单后修改数据的能力是非常慎重的 ， 且这部分数据通常会通过带有版本号的数据快照来记录 ， 以区分和追溯 。
5）数据分发机制
由于主干道对数据时效要求极高 ， 此时大部分是通过接口进行数据通信交互 ， 而对其他系统并不在主干道或对时效要求不高 ， 可通过消息机制的方式来实现数据交互 。 消息队列是基础数据结构中的“先进先出”的一种数据机构 。 生活中排队买东西 ， 就是典型的“先进先出” 。 通过消息广播数据的机制 ， 可以解决：应用解耦、流量消峰、消息分发、异步通知等 。
应用解耦：应用中有订单系统、财务系统、仓配系统等各种业务系统 。 用户创建订单后 ， 如果耦合调用所有相关系统 ， 任何一个子系统出了故障 ， 都会造成下单操作异常 。 当转变成基于消息队列的方式后 ， 系统间调用的问题会减少很多 ， 比如物流系统因为发生故障 ， 需要几分钟来修复 。
在这几分钟的时间里 ， 物流系统要处理的内存被缓存在消息队列中 ， 用户的下单操作可以正常完成 。 当物流系统恢复后 ， 继续处理订单信息即可 ， 中单用户感受不到物流系统的故障 。 提升系统的可用性 。
流量消峰：举个例子 ， 如果订单系统最多能处理一万次订单 ， 这个处理能力应付正常时段的下单绰绰有余 ， 正常时段下单一秒后就能返回结果 。 但是在高峰期 ， 如果有两万次下单操作系统是处理不了的 ， 只能限制订单超过一万后不允许用户下单 。 使用消息队列做缓冲 ， 我们可以取消这个限制 ， 把一秒内下的订单分散成一段时间来处理 ， 这使有些用户可能在下单十几秒后才能收到下单成功的操作 ， 但是比不能下单的体验要好 。
消息分发：多个服务对数据感兴趣 ， 只需要监听同一类消息即可处理 。
『设计』解密「零售」系列（二）：产品架构
本文插图
例如A产生数据 ， B对数据感兴趣 。 如果没有消息的队列A每次处理完需要调用一下B服务 ， 过了一段时间C对数据也感性 ， A就需要改代码 ， 调用B服务 ， 调用C服务 。 只要有服务需要 ， A服务都要改动代码 ， 很不方便 。
『设计』解密「零售」系列（二）：产品架构
本文插图
有了消息队列后 ， A只管发送一次消息 ， B对消息感兴趣 ， 只需要监听消息 。 C感兴趣 ， C也去监听消息 。 A服务作为基础服务完全不需要有改动 。
异步消息：有些服务间调用是异步的 ， 例如A调用B ， B需要花费很长时间执行 ， 但是A需要知道B什么时候可以执行完 ， 以前一般有两种方式 ， A过一段时间去调用B的查询api查询 。 或者A提供一个callback api ， B执行完之后调用api通知A服务 。 这两种方式都不是很优雅 。
『设计』解密「零售」系列（二）：产品架构
本文插图
使用消息总线 ， 可以很方便解决这个问题 ， A调用B服务后 ， 只需要监听B处理完成的消息 ， 当B处理完成后 ， 会发送一条消息给MQ ， MQ会将此消息转发给A服务 。 这样A服务既不用循环调用B的查询api ， 也不用提供callback api 。 同样B服务也不用做这些操作 。 A服务还能及时的得到异步处理成功的消息 。
（2）订单状态流转
订单状态由订单系统来维护 ， 也是其最重要的数据 。 其几乎控制着整个电商系统的运行流转 。
『设计』解密「零售」系列（二）：产品架构
本文插图
每一个状态的变化会影响和指引订单的信息流、实物流、资金流的流向 。 通常在大型电商平台会有上百个系统来监听订单状态的变化来触发业务 ， 作为业务开始的起点 。 每个状态都是在不同的作业流程中各系统来触发改变 ， 并将数据回传到订单主数据 ， 由订单主数据来统一维护和调度订单状态 ， 以确保数据一致性 。


推荐阅读


上一篇：「深扒财经圈」易观方舟：数据技术赋能城市出行服务升级

下一篇：「蓝血研究」华为伙食补贴：管理就是要让大家捞到好处