本文主要是介绍alpakka-kafka(3)-kafka应用案例-需求分析，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
在大型复杂的应用中，业务模块之间总是相互关联，相互纠缠。无论对业务管理或软件开发方面都会造成困惑：从业务管理方面难以厘清确切的管理范围和职责：就是说不知一项业务具体谁来管。在软件开发方面则无法确定开发人员的具体分工和维护责任，即确定一项业务功能具体靠谁来修改、优化。拿一个普通的网上购物过程来说，除商品拣选过程外的优惠价选定、库存扣减、支付又会涉及商品定价管理、库存管理、财务管理等独立的业务模块。如果纯从软件开发角度来描述：负责开发购物流程的开发人员还需要兼顾优惠价计算、库存扣减、支付等业务操作。因为商品定价、库存管理、财务管理等都有可能是其它人负责开发的业务模块。一件商品拣选有可能造成该商品的定价调整、库存变动可能驱动采购、配货等业务的发生、支付也会是一些财务操作的启动原因。购物流程开发人员应该是不容许直接去实现这些业务操作的。为了解决这些矛盾，必须先实现业务模块的松散耦合。听起来有点像CQRS，不过是更广义的domainRS业务模块分离。在接触kafka之前，我们一般用soa模式由负责一块业务功能开发的程序员提供一套完整的对外业务操作api，就可以实现程序员各自独立工作，各管自己的一亩二分地。不过，完成的系统经常会出现内部处理业务速度跟不上外部api调用频率的情况，轻者拖滞api调用线程，重则造成业务处理异常。这个时候kafka应该能在解决方案里发挥特殊作用：如果我们把kafka引入到业务模块集成，业务模块之间通过消息/事件队列event-queue进行沟通就可以实现更高程度的、更高效率的、交易事务类型的业务集成了。
这次我们拿具普遍代表性的库存更新业务操作来作为示范案例。企业业务中几乎所有关于商品流动的业务流程都会涉及到库存状态的转变。显然，每个业务流程在操作中都直接对库存数进行修改是不妥当的：库存变更的决定权应该在库存管理业务，其它业务只能向库存管理业务申报库存变更提请。好了，可能大部分业务在提请库存变更后就继续进行下部分业务操作了，但也有些业务需要等待回复来确定请求执行状态的，这就是上面提到的具代表性案例了。库存更新业务具时效性，不同时间发生的库存更新请求会产生不同的状态结果，如：网购的秒杀，多个购物者同时对一种商品下单，同是库存扣减请求，其中有些可能无法实现。又比如一个售票系统，多个售票窗口可能同时对同一张坐票进行拣选，系统必须考虑到这种多并发背景下数据操作的安全、准确、高效。
好了，通过以上分析，一个系统轮廓已经显现出来了：这是一个独立的库存交易平台，把库存作为一项公共资源管理起来。外界业务模块或者第三方软件向平台提请库存状态操作，通过http-service api把库存查询或者库存更新请求提交平台、平台根据提交请求类型进行相关的库存管理操作，如：确定最新的库存状态、根据库存状态向物流业务进行相关的库存调配请求等等、然后可能需要尽快把结果返回请求方。以此类推，其它类型的交易平台如支付、商品信息、商品调拨、商品收发等等都可以成为独立的业务模块，通过kafka把它们集成为一个整体。
在下篇我们可以讨论一下用alpakka-kafka实现这个案例所需要考虑的一些技术方案。
这篇关于alpakka-kafka(3)-kafka应用案例-需求分析的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
