这是一个创建于 1517 天前的主题，其中的信息可能已经有所发展或是发生改变。
关于微服务其实我一直有个疑问，像公司最近做的一个公寓管理项目，技术负责人把它分成了预约模块、房屋模块、签约模块、交接模块（交接水费、电费、家具等等）和出租管理模块。因为每个模块都有一个分页查询界面（界面上有一列得展示房屋信息），所以得在除房屋模块之外的所有模块冗余一下房屋的字段信息（房屋 id 、省份 code 、省份名称、城市 code 、城市名称、行政区 code 、行政区名称、小区 id 、小区名称、楼栋号、单元号、房间号），光这些冗余的字段信息就有十多个。
技术经理这样划分微服务是不是对的呢？
技术经理这样划分微服务是不是对的呢？
 |
1
huifer 2020-09-30 16:51:45 +08:00
不建议冗余过多字段, 将 id 和外键保留, 通过各自服务提供模糊查询查出 id 在进行 in 操作. 各个服务提供最基本服务,指代这个模块中的业务, 其他的组合结果最好是能够依靠 聚合服务进行处理.
举个例子 签名模块需要去查询有哪些楼房被签约, 假设条件小区名称, 1. 通过房屋模块查询小区名称的条件, 返回房屋的 ids. 2. 将第一步的 ids 放入签约模块查询出签约列表. 3. 如果需要拓展字段如将房屋的详情查询. 在去房屋模块进行查询 id 最后在组装返回. 通常我会将上述模块会被独立出来做一个聚合服务. |
 |
2
polyang OP @huifer 有点懂了，另外，这个聚合服务怎么样做呢？“通常我会将上述模块会被独立出来做一个聚合服务”中的上述模块指的是什么模块
|
|
3
huifer 2020-10-12 14:42:04 +08:00
假设目前使用的 rpc 框架是 Dubbo. 我会将上述的第 2 步做一个 dubbo-service, 便于在聚合服务中调用. 其他的也是类似.
此时我们会拥有 房屋模块 Dubbo 、 签约模块 Dubbo. 其中聚合服务就是将这两个 Dubbo 进行组装, 然后返回. 上述采用 Dubbo 实际场景可以根据贵公司的 RPC 框架进行选择. |
Select Language