物流微服务要做的事情非常简单，毕竟我们只是想把『消息驱动』的思想引入到我们的工程中。同时，我们的物流微服务并没有直接与 Kafka、RocketMQ 等等这样的消息中间件交互，而是引入了 SpringCloud Stream，实现了工具与代码的隔离。不过，总的来说，物流微服务可以继续扩展的地方还有很多，当你有任何想法的时候，随时在问答区和我交流吧。

1 在考虑消息驱动的时候，你会考虑重复消费、丢失消息的问题吗？

• 消息的丢失主要在 producer 端，要保证消息能够成功发送给消息中间件，需要有一定的 ACK 机制…
• 重复消费是在 consumer 端，consumer 一定要记录消费的 Message 元信息，需要比对是否曾经消费过…

2 如果让你选择，你会考虑使用 Stream 组件还是直接与消息中间件交互呢？理由是什么？

• 如果变动不大，且我对消息中间件的 API 非常熟悉，那么，不需要引入 Stream…
• 如果可能会变动，且需要考虑代码的复用性，那么，引入 Stream 会更好…

3 你会怎么考虑去扩展、优化物流微服务呢？说说你这样思考的理由？

• 增加消息推送，物流记录创建以后，给用户发送推送消息…
• 物流微服务考虑消费分组、消息分区（不过，要给出理由）…