微服务的事件通知里，如何设计事件

[yixinlove]

RT。

背景： 需要设计一个微服务的事件通知，通知会发送到 Kafka，其他感兴趣的微服务自动消费。当前各个微服务可以通过 RPC，或者 REST 调用，或者直接访问 DB 获取数据（有些可能有限制）。

想法是把这个事件设计的尽量简单，但是不知道需要考虑哪几个方面，请大神指教。

自身考虑的几个点是：

1. 如果允许通过唯一标识拿到最新的数据，是不是只需要事件包含三个基本信息就行：唯一标识、操作类型和出发事件；
2. 如果考虑服务之间尽量少调用（或者说减少数据库的 QPS ），在事件里包含了尽量多的信息，譬如更新，包含更新了哪个字段，什么值这类。为了做到尽量简单，那么在前期只能说综合已有业务考虑，把需要的字段都加进来。

现在组里的大佬是倾向于第一种，但是这种应该需要通过唯一标识拿一次详细数据（不管是 RPC、RESTful 还是数据库直接查），都会对服务方或者数据库产生压力，不确定这种方式是否最优。

不知对于这种事件的设计是从哪几个方面考虑的？我自己的考虑有什么问题？请大佬不吝赐教。

[mooncakejs]

通过主键拿数据，数据库没什么压力的，如果是 nosql 压力就更小了

[yixinlove]

@mooncakejs 我在想，作为微服务架构，应该是避免这种直接数据库查询，可能更多的是通过 RPC/webservice 这类来获取数据。如果是这样，数据量大，那对于服务端压力会增加不少。

[joesonw]

@yixinlove 读的操作哪有压力, 扛不住了就前面加个 redis 缓一下, 纯 mysql 还有各种只读从库的实现呢

[blessyou]

看过一本微服务的书 服务之间调用尽量通过 rpc 调用 而不是读其他服务的库

[mooncakejs]

@yixinlove 微服务里面就不读数据库了？

[yixinlove]

@mooncakejs 按理说拆分成微服务，应该要尽量减少对其他服务数据库的访问吧，这样能减少依赖

[snappyone]

在没有性能压力情况下可以先不考虑这个，正确地实现即可

[mooncakejs]

@yixinlove 读数据库不一定是直连啊，通过 api 也会读数据库

[yixinlove]

@mooncakejs 是的，通过 API （ RPC / RESTful ）耦合度没那么高，因为数据都是有业务组装，如果是直连数据库那耦合度就非常高了，两个服务的升级有可能会互相影响。

大佬觉得这种事件的设计，应该如何去平衡呢？是尽量在消息实体里包含足够多的信息，避免再次调用 API 查询，还是说直接只发送唯一标识这类，如果需要数据再去查。

我现在比较迷糊的是不知道如何去抉择，或者应该根据什么去抉择。