微服务划分后每个服务都需要冗余字段是正常的吗？

This topic created in 2076 days ago, the information mentioned may be changed or developed.

关于微服务其实我一直有个疑问，像公司最近做的一个公寓管理项目，技术负责人把它分成了预约模块、房屋模块、签约模块、交接模块（交接水费、电费、家具等等）和出租管理模块。因为每个模块都有一个分页查询界面（界面上有一列得展示房屋信息），所以得在除房屋模块之外的所有模块冗余一下房屋的字段信息（房屋 id 、省份 code 、省份名称、城市 code 、城市名称、行政区 code 、行政区名称、小区 id 、小区名称、楼栋号、单元号、房间号），光这些冗余的字段信息就有十多个。
技术经理这样划分微服务是不是对的呢？

模块

房屋

Code

字段

3 replies • 2020-10-12 14:42:04 +08:00

huifer

Sep 30, 2020

不建议冗余过多字段, 将 id 和外键保留, 通过各自服务提供模糊查询查出 id 在进行 in 操作. 各个服务提供最基本服务,指代这个模块中的业务, 其他的组合结果最好是能够依靠聚合服务进行处理.
举个例子签名模块需要去查询有哪些楼房被签约, 假设条件小区名称,
1. 通过房屋模块查询小区名称的条件, 返回房屋的 ids.
2. 将第一步的 ids 放入签约模块查询出签约列表.
3. 如果需要拓展字段如将房屋的详情查询. 在去房屋模块进行查询 id 最后在组装返回.
通常我会将上述模块会被独立出来做一个聚合服务.

polyang

Oct 12, 2020

@huifer 有点懂了，另外，这个聚合服务怎么样做呢？“通常我会将上述模块会被独立出来做一个聚合服务”中的上述模块指的是什么模块

huifer

Oct 12, 2020

假设目前使用的 rpc 框架是 Dubbo. 我会将上述的第 2 步做一个 dubbo-service, 便于在聚合服务中调用. 其他的也是类似.
此时我们会拥有房屋模块 Dubbo 、签约模块 Dubbo. 其中聚合服务就是将这两个 Dubbo 进行组装, 然后返回.

上述采用 Dubbo 实际场景可以根据贵公司的 RPC 框架进行选择.