[国内信息] 腾讯云2860元代金券领取及使用说明 [复制链接]
查看:327657 | 回复:709

gydtep · 发表于 2022-9-10 16:59:14

但是我个人还是觉得 model 更适合，因为从名称上面更好理解一点，更加直观一点，一看就知道是模型，什么模型，当然是业务的领域模型。

gydtep · 发表于 2022-9-11 15:53:31

instructure 层：基础设施层主要包含了各种通用能力以及工具类，它的作用就是为上层提供基础服务的，如数据库服务、MQ 服务以及缓存服务等还有其他的一些配置以及资源。

gydtep · 发表于 2022-9-12 08:02:08

的确这种开发方式更加的能体现 DDD 的优势。另外这里还是根据领域进行划分，和 biz 层是一样的。
（1）event 主要放事件处理的核心逻辑代码。

gydtep · 发表于 2022-9-13 10:52:37

如果可以有一个统一的消息系统（产品）来提供多场景计算（如 stream、event）、多场景（IoT、APP）接入，其实是非常有价值的，因为消息也是一种重要数据，

gydtep · 发表于 2022-9-13 13:27:26

P2P
服务端消息如果一台服务器处理失败可以由另外一台服务器处理成功即可，而终端消息必须明确发给具体终端，若该终端处理失败则必须一直重试发送该终端直到成功，这个和服务端很不一样。

gydtep · 发表于 2022-9-13 16:45:47

触达即通过匹配查找后找到所有的接受者目标，需要将消息以某种可靠方式发给接受者。常见的触发方式有两种：Push、Pull。Push，即服务端主动推送消息给终端设备，主动权在服务端侧

gydtep · 发表于 2022-9-14 08:32:47

可以看到读放大场景下消息只写一份，写到 Topic 维度的队列，但接受者读取时需要按照订阅的 Topic 列表多次读取，而写放大场景下消息要写多份，写到所有接受者的客户端队列里面，

gydtep · 发表于 2022-9-14 13:01:13

然后分发出多个需求场景的队列索引（ConsumerQueue），如服务端场景（MQ/AMQP）可以按照一级 Topic 队列进行传统的服务端消费，客户端 MQTT 场景可以按照 MQTT 多级 Topic 以及通配符订阅进行消费消息。

gydtep · 发表于 2022-9-14 16:23:09

Pull+Offset 机制可以保证消息的可靠性，这个是 RocketMQ 的传统模型，终端节点被动接受网关节点的 Push，解决了终端设备轻量问题，实时性方面因为新消息事件通知机制而得到保障。

gydtep · 发表于 2022-9-15 09:42:18

不太关心是哪台消费者机器，消息的可靠性 ACK 标识可以集中在消费组维度，而终端消息的可靠性 ACK 标识需要具体离散到终端设备维度。简单地说，一个是客户端设备维度的 Retry 队列，一个是消费组维度的 Retry 队列。