微服务服务层接口粒度怎么把握
假设有四个类
class Product {
private Long productId;
}
class ProductImage {
private Long productId;
private Long productImageId;
}
class ProductAttachment {
private Long productId;
private Long productAttachmentId;
}
class ProductDto extends Product {
private List<ProductImage> images;
private List<ProductAttachment> productAttachments;
}
微服务架构里,服务接口设计如下:
1 细粒度:提供三个单独的接口,其他服务调用这三个接口获取数据,另外在Api网关聚合成ProductDto后直接返回给前端
interface ProductService {
Product getProduct(Long productId);
List<ProductImage> listProductImage(Long productId);
List<ProductAttachment> listProductAttachment(Long productId);
}
2 粗粒度:提供一个聚合接口,其他服务调用这个接口,另外Api网关只做转发返回给前端
interface ProductService {
ProductDto getProduct(Long productId);
}
请问大家更倾向于哪种方式,怎么把握服务层的接口粒度?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
这完全取决于你所要支持的业务。
首先,我假设你使用 restful 规范开发 api。那么,如果真实业务中完全没有 list product images 或者 list product attachment 的需求,那就完全没有开发的必要。
如果你想要比较动态灵活的方式,那我推荐 graphql。完全由客户端决定粒度。