集成平台管理系统 ● 项目采用微服务架构.前后端分离的开发模式 ● 技术栈采用 springBoot+springCloud 和各个相关微服务配合 ● 系统总体分为 7大模块 ● 基础设置模块:主要是仓库信息,相关方档案,货品信息,承运商信息,专属客户等 ● 订单管理模块:主要针对销售订单管理 ● 入库管理模块:主要针对采购订单管理,ASN 收货管理,扫描收货,上架操作管理 ● 库存管理模块:主要是移位管理,库存管理 ● 出库管理模块:主要是发货单管理,波次管理.交接单出库 ● 退货管理模块:主要是退货订单,退货质检 ● 策略配置模块:主要是库位规划库区规划

龙湖地产供应链招采系统是供应链中的核心环节.龙湖地产由此平台进行招投标操作. ● 发标人:系统核心由招标规划和招标过程两部分组成.并由过程延伸出特殊事项审批,资源管理,基础配置,报表统计4个辅助模块.由招标 规划延伸出需求管理模块. ● 投标人:供应商门户系统和供应商评价管理以及供应商投标系统3部分组成 ● 系统难点:系统业务专业性强 ● 系统重点:立项阶段,预警计算 技术概述: ● 后台通过11个微服务来实现招采系统的功能. ● 通用三模块(通用业务操作模块,定时任务模块,三方调用模块) ● 业务8个模块(算法模块,评价模块,计划,过程,投标,考察,供应商门户,供应商管理) ● 技术栈方面: ●日志服务(ELK) ●服务发现(consul) ●服务配置(appolo) ●网关服务(Gravitee) ●消息服务(RabbitMq) ●kafka 服务(Kafka) ●缓存服务(Redis) ●调度服务(XXL-JOB) ●API协作门户(Yapi) ●Nacos 服务发现(Nacos)

ASN管理,上架单管理,销售单管理,发货单管理,波次管理,拣货单管理,包装复核管理,交接单管理,库内管理,基础数据,库存管理 分布式事务解决方案 仓储中分布式事物的场景 微服务环境下会根据不同的业务拆分成不同的服务。每个服务都有自己独立的数据库。一个业务操作可能涉及到多个服务对应多个数据库，由于多个数据库是无法保证数据一致性的，这就出现了分布式事务问题。 在仓储项目中，用户单据操作很多情况下会影响到库存数据。一个业务流程涉及到两个服务、两个数据库。这些单据操作都会用到分布式事务。 常见的分布式事务的解决方案 解决分布式事务有很多理论指导，例如 2PC 协议、3PC 协议、TCC、本地消息表、事务消息、最大努力通知等。 其中，2PC、3PC都是强一致性解决方案。本地消息表、事务消息、最大努力通知都属于最终一致性解决方案。 强一致性就是任何时间数据都是一致的；弱一致性允许数据在可容忍的时间范围内暂时不一致。 到底选择强一致性解决方案还是弱一致性解决方案，需要看实际业务。如果业务可以容忍短暂的数据不一致的情况，那么就可以使用最终一致性的分布式事务解决方案。弱一致性的解决方案牺牲了强一致性，但是性能相比强一致性方案更高。 仓储中解决分布式事务的方案 仓储中使用 RocketMQ 的事务消息解决分布式事务问题，这是一种最终一致性的分布式事务解决方案。以发货单/交接单/拣货单扣减库存举例 交接单出库--》交接单服务--》此时只允许一个人操作这个交接单因此需要用redis锁确保此单号唯一被操作---》携带交扣减库存所需要的信息(核心是一个magid唯一性标志)远程调用扣减库存==》库存接受到调用后需要一个个处理首先通过唯一性标志进行redis加锁，一个一个处理单据，这时候如果再有调用就持续等待释放锁--》此时库存更新各种库存表并记录记录库存日志详细记录扣减库存---》记录扣减出库任务(msgid确定一条信息)--》返回成功信息==》库存返回成功信息交接单服务开始更新数据状态===>给库存发送mq(里面含有msgid)===>库存收到消息先判断是否超时(每个服务发送确认mq必须在一定时间内交接单的确认时间是一小时)====>满足时间就删除扣减出库任务==>生产每小时执行一次针对交接单扣减库存任务表建立一个定时任务==>首先从任务表查询记录==>循环判断是否超时==>超时任务插入主键重复表 ,防止多任务的重复执行===>进行回退操作===>回退变比删除扣减任务表 概述: 1.服务通过远程调用的方式来触发库存操作 2.库存操作完毕生产者继续进行其他操作,一般是更新状态 3.其他操作完毕确认无误给库存发确认mq 4.库存收到确认消息进行库操作 5.如果超时需要回滚 6.回滚通过定时任务执行 分布式锁解决方案 场景 分布式锁主要用于在分布式环境下对跨进程、跨主机、跨网络的共享资源实现互斥访问，以达到保证数据一致性的目的。 在仓储项目中,在单据进行操作的时候,为了防止重复性或者多人操作需要进行加锁来锁定当前的订单资源. 分布式锁的常见解决方案 在互联网项目中，常见的分布式锁的解决方案有两种： 1.基于Redis实现分布式锁：主要是利用Redis的SETNX命令实现分布式锁 2.基于ZooKeeper实现分布式锁：主要是利用ZooKeeper的临时顺序节点和Watcher事件监听器来实现分布式锁 Redis 实现分布式锁的原理 ​ 使用Redis实现分布式锁主要是利用了SETNX命令，这个命令的作用就是当key不存在时设置key的值。如果一个线程成功设置了值，那么这个线程就是拿到锁了。 ​ 但是如果项目宕机或者请求报错，那么key将永远不会被删除，这就造成了死锁。那么我们可以给key设置超时时间。我们可以使用exprie命令设置超时时间，但是setnx命令和exprie命令是两条命令，会出现原子性问题，如果执行完setnx后执行exprie时程序挂了，那么还是会造成死锁问题。 ​ 这个问题我们可以通过两种方式来解决。一种方式是使用Lua脚本来保证多条命令执行的原子性。第二种方式是在setnx命令中指定key的过期时间，语法是“set key value NX PX 过期时间”。我们一般是使用第二种方式。 ​ 死锁问题解决了，但是假设锁超时的时间是5秒，但是一个接口5秒中还没有执行完，那么这把锁就失效了，其他线程就能获取到锁了，这就又出现问题了。解决接口没执行完毕但是锁已经失效的这个问题可以使用Redission这个框架。 ​ Redission中有一个机制叫做watch dog看门狗，就是启动了一个后台线程，会定时比如没10秒检测一下当前线程是否还持有锁，是的话就将锁的失效时间延期。相当于一个定时任务。但是不建议开启，很损耗性能。 Zookeeper 实现分布式锁的原理 ​ zk是一个树形结构，由很多节点组成，每个节点叫一个Znode，每个节点都能存储数据。zk的节点分为三大类：持久性节点（Persistent）、临时节点（Ephemeral）、顺序节点（Sequential）。开发中可以通过组合生成4种类型的节点：持久节点、持久顺序节点、临时节点、临时顺序节点。 ​ 持久节点一旦被创建之后就一直存在zk服务器中，除非主动删除，这是最常见的节点。 ​ 持久顺序节点就是有顺序的持久节点，顺序性是通过在节点名后加一个数字后缀表示顺序。 ​ 临时节点会被自动清理掉，它的生命周期和客户端会话绑定在一起，客户端会话结束后节点就会被删掉。与持久节点不同的是临时节点不能创建子节点。 ​ 临时顺序节点就是有顺序的临时节点，保证顺序性的原理也是在节点名称后面加一个数字后缀。 ​ zk的分布式锁是基于“zk的临时顺序节点”和“zk的watcher事件监听器”实现的。 ​ watcher事件监听器也叫做zk观察器，是zk中非常重要的一个概念。 ​ Watcher事件监听器可以监听到节点的变动，如果节点发生变更就会通知zk客户端。Watcher事件监听器有一个比较重要的特征就是只能监控一次，再监控需要重新设置。 ​ Watcher机制主要有3个角色组成，客户端线程、客户端WatcherManager（事件管理器）、zk服务器。具体的流程是zk客户端向zk服务器注册Watcher事件监听的同时，会将Watcher（事件对象）对象存储在客户端的WatchManager（事件管理器）中。当zk服务器出发Watcher事件之后，zk服务器回向客户端发送通知，客户端线程从WatchManager中取出对应的Watcher对象执行回调逻辑（执行process方法）。 ​ zk实现分布式锁的原理就是利用zk的瞬时有序节点的特性，多线程并发创建瞬时有序节点，得到有序的序列，此时创建节点的时候就已经确定了线程的执行顺序。让序号最小的线程获取锁。其他线程监听自己节点序号的前一个序号。前一个线程执行完毕之后删除自己序号对应的节点。下一个序号对应的线程得到通知，继续执行。 仓储中分布式锁的解决方案 仓储中使用Redis实现分布式锁主要是利用了SETNX命令实现的加锁工具类. 通过:系统+单据号的方式来实现. 为什么不使用ZooKeeper实现分布式锁 Redis实现的分布式锁更加高效，Zookeeper实现分布式锁更加可靠。几乎所有的项目都会使用Redis，不见得所有的项目都会使用ZooKeeper。为了使用分布式锁而搭建一套ZooKeeper集群成本太大。 服务雪崩问题解决方案 场景 在微服务项目中，一旦业务达到一定体量，都需要引入一些熔断降级策略。 在仓储中，订单服务和订单流转服务，都会和库存服务进行交互。为了防止库存服务在高并发环境下宕机，进而导致整个微服务系统雪崩，我们需要采取一些措施预防、处理服务雪崩问题。 雪崩问题的解决方案 1.超时处理：设定超时时间，请求超时还未响应就返回错误信息，不会无休止地等待 2.仓壁模式（线程隔离）：限定每个业务能够使用的线程数，一个服务挂了不至于耗尽整个tomcat的线程资源 3.熔断降级：由断路器统计异常比例，如果超出阈值就熔断该业务，拦截访问该业务的一切请求 4.流量控制：限制业务访问的QPS，避免因流量突增而故障 仓储中服务雪崩的解决方案 仓储中使用 Sentinel 对微服务系统进行熔断降级、限流。 同类产品还有 Hystrix ，但是 Hystrix 已经不再维护，目前主流的熔断降级、限流的方案是使用阿里巴巴的 Sentinel 。 使用 Sentinel 可以实现仓壁模式、熔断降级、流量控制。 在线程隔离方面，Sentinel 即支持线程池隔离，又支持信号量隔离；Hystrix 只支持线程池隔离。 在熔断降级方面，Sentinel 可以统计慢调用比例或异常比例来进行服务熔断；Hystrix只能统计异常比例。 在限流方面，Sentinel 支持基于QPS限流，支持基于调用关系的限流，支持基于热点参数做限流；Hystrix不能做限流。 控制台方面，Sentinel 支持完善的web控制台，该控制台不仅支持查看微服务的运行状态，还能配置限流规则、降级规则，配置后立即生效；Hystrix的控制台只支持查看微服务的运行状态，不支持配置。 线程池隔离与信号量隔离 线程池隔离：很好理解，给每一个要调用的业务创建一个独立的线程池。也就是仓壁模式。缺点是线程数量会成倍增长，虽然这种方式隔离性会比较好，但是随着线程数量增长，CPU会增加额外的上下文切换的消耗，所以整个服务的性能会有一些损失. 信号量隔离：业务请求进入Tomcat之后，不会创建额外的线程池，而是会做一个统计。统计当前业务已经使用了几个线程，会限制某个业务使用的线程数量，例如限制a业务只能使用10个线程，如果已经使用了10个线程，再有新的a请求，就会阻塞等待。也就是说会限制某个业务能使用的线程数量，但是线程池只有一个，就是tomcat默认的线程池，不会去创建新的线程池。优点是不会增加CPU的负担，缺点是隔离性不如仓壁模式，毕竟是在一个线程池中。我们认为信号量隔离更好。 redis存储什么数据 我们使用Redis主要是为了加快数据查询速度，降低MySQL的数据读取压力。 第一我们使用分布式锁使用的是Redis，那么分布式锁也是存储在Redis中的。 第二货品经常按照货主供应商货品的维度进行查询.所以在查询此类信息要存到 缓存中. elasticsearch存储什么数据 我们使用 Elasticsearch 主要是为了使用ES的模糊搜索功能。我们需要对仓库中的货物,库区,库位名称称进行搜索，货主,供应商,承运商等也常采用名称搜索.因此ES中要存仓库的货品信息和相关方信息. 多久同步一次 对于Redis来说，只需要当首次查询不到的时候,从数据库查询并保存到缓存一份,只要数据库中的数据发生改变，就清空缓存中的相关数据. 对于Elasticsearch来说，要初始化一份数据库数据到索引库,后面库存信息变更是需要同步更新的.相关方信息包括货主信息,供应商信息,承运商信息都是通过定时任务每天定时同步到es.