csys

不像是已出轨，更像是等出轨

口头答应 拿到补偿后追缴

涉钱要征信很正常吧

涉命应该也要征信的，比如飞行员之类

严格说的话其实花不了这么多钱
先查炎症反应 再查当前季节的流行病 一般有的话一个一个查，或者 3 合 1 查，大多数情况下很快就命中了，医生肯定知道最近哪些流行病比较严重
这种 N 合 1 就是医院/医生图省事不把患者/医保的钱当钱

可怜

@blessingcr

你这交互是 请求-响应 模式的，内部实现可以用 http grpc 或者 mq 都行

> 有的在内网有的在外网，MQ 不能暴露在外网
mq 是个内部系统的基础设施，和外界交互肯定还是得用 [接口] 啊
比如其中一个选择就是 B 系统启动是注册自己的位置，提供一个监听接口，A 和 B 通讯的时候调用 B 注册的接口
或者 A 系统将待发送的消息放在 outbox ，B 系统通过 polling 来取消息
或者 更简单的，直接建立 websocket 连接，使用类似聊天室的框架（比如 signalr ），单播、广播也一块支持了
类似的方案到处都是

> 确保对于某一业务而言消费串行

这个和区块链有啥关系，用区块链性能不更低了
这就看一致性在哪保证，如果是数据库来保证就是用数据库事务，你反正也是中心存储的
如果是分布式系统，数据分散在不同数据库，就用分布式锁来保证强一致性，或者 saga 来实现最终一致性

槽点过多……
这不就是并发一致性问题么

无论是同步的 http ，还是异步的 mq ，你这业务场景都是命令消息，都是请求-响应模式的
一致性冲突的话直接把该失败的请求失败掉不就行了

http 就不说了，mq 的话

1.：发送请求上架消息，等待上架结果消息
2.：处理请求上架消息，发布上架结果消息
3.：收到上架结果消息，完成上架

如果这个流程时间很长的话，就给个“上架中”的中间状态来跟踪
锁用来保证局部的一致性

关区块链啥事啊，你这不是中心化的数据存储吗

你这个图也挺抽象的，第一次见到这种图，solidworks 画的吗