这是一个创建于 1855 天前的主题，其中的信息可能已经有所发展或是发生改变。
RT。
背景： 需要设计一个微服务的事件通知，通知会发送到 Kafka，其他感兴趣的微服务自动消费。当前各个微服务可以通过 RPC，或者 REST 调用，或者直接访问 DB 获取数据（有些可能有限制）。
想法是把这个事件设计的尽量简单，但是不知道需要考虑哪几个方面，请大神指教。
自身考虑的几个点是：
- 如果允许通过唯一标识拿到最新的数据，是不是只需要事件包含三个基本信息就行：唯一标识、操作类型和出发事件；
- 如果考虑服务之间尽量少调用（或者说减少数据库的 QPS ），在事件里包含了尽量多的信息，譬如更新，包含更新了哪个字段，什么值这类。为了做到尽量简单，那么在前期只能说综合已有业务考虑，把需要的字段都加进来。
现在组里的大佬是倾向于第一种，但是这种应该需要通过唯一标识拿一次详细数据（不管是 RPC、RESTful 还是数据库直接查），都会对服务方或者数据库产生压力，不确定这种方式是否最优。
不知对于这种事件的设计是从哪几个方面考虑的？我自己的考虑有什么问题？请大佬不吝赐教。
 |
1
mooncakejs 2019-03-22 00:20:46 +08:00
通过主键拿数据，数据库没什么压力的，如果是 nosql 压力就更小了
|
 |
2
yixinlove OP @mooncakejs 我在想，作为微服务架构，应该是避免这种直接数据库查询，可能更多的是通过 RPC/webservice 这类来获取数据。如果是这样，数据量大，那对于服务端压力会增加不少。
|
 |
4
blessyou 2019-03-22 10:52:27 +08:00 via Android
看过一本微服务的书 服务之间调用尽量通过 rpc 调用 而不是读其他服务的库
|
|
5
mooncakejs 2019-03-22 12:54:52 +08:00 via iPhone
@yixinlove 微服务里面就不读数据库了？
|
|
6
yixinlove OP @mooncakejs 按理说拆分成微服务，应该要尽量减少对其他服务数据库的访问吧，这样能减少依赖
|
 |
7
snappyone 2019-03-22 14:43:40 +08:00
在没有性能压力情况下可以先不考虑这个，正确地实现即可
|
|
8
mooncakejs 2019-03-22 17:22:46 +08:00
@yixinlove 读数据库不一定是直连啊，通过 api 也会读数据库
|
|
9
yixinlove OP @mooncakejs 是的，通过 API （ RPC / RESTful ）耦合度没那么高，因为数据都是有业务组装，如果是直连数据库那耦合度就非常高了，两个服务的升级有可能会互相影响。
大佬觉得这种事件的设计，应该如何去平衡呢？是尽量在消息实体里包含足够多的信息，避免再次调用 API 查询，还是说直接只发送唯一标识这类，如果需要数据再去查。 我现在比较迷糊的是不知道如何去抉择，或者应该根据什么去抉择。 |
Select Language