江苏龙网

  1. 首页 > 资讯 > 科技 > >

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


4）数据版本机制
随着用户场景越来越丰富 ， 业务发展越来越复杂 ， 必然存在修改订单数据的场景 ， 这对分布式的异步系统是非常挑战的 ， 核心原因为过程和结果数据分发到相关系统已经触发其业务进程中 ， 而在这期间修改数据对于已经或正在执行的业务产生致命影响 。如修改收货地址 ， 直接影响到运费价格和履约时效的重新计算 ， 会引发很多相关系统做出应变 。
所以通常提供订单后修改数据的能力是非常慎重的 ， 且这部分数据通常会通过带有版本号的数据快照来记录 ， 以区分和追溯 。
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服务还能及时的得到异步处理成功的消息 。


推荐阅读


上一篇：『曼果教育』淘宝网店单品流量下降是什么原因？怎么解决

下一篇：「欧解」国产封测龙头通富微电如何修练内功？丨亿欧解案例