微服务,管理员接口.用户接口,浏览接口,的摆放问题

[dnjat]

以文章管理为例.

管理员接口	(管理,信息审核,显示上的权重..)
用户接口	(管理,编辑,修改..)
浏览接口	(无需登录就能访问的数据..)

这三者有共同的接口.也有各自专用的接口.

服务内有使用鉴权,大家对专用接口与通用接口是如何分结构的.

[thevita]

不分，把权限做好就行了

[lingxmo]

每个东西的管理都弄成一个服务（用户管理服务、文章管理服务、评论管理服务）
功能实现只有一份，外层接口可以开两套（管理 API 集合、公开只读的 API 集合），每套都有对应的网关给不同的人用

[dnjat]

@thevita
@lingxmo 谢谢经验分享

[dayeye2006199]

建议不搞微服务

[dnjat]

@dayeye2006199 怎么说? 其实我的疑惑和微服务也没什么关系,是代码结构问题..写在一起, 用户接口里混了管理员接口,不写在一起吧,管理员需要用用户接口,两套接口回来穿梭. 我觉得 2 楼的方法比较合理,和 1 楼的相结合.

[pannanxu]

如果仅仅是因为模块混在一起而做微服务，其实大可不必，不但增加了系统复杂性，性能反而不会有啥提升甚至下降（多层 http 调用、分布式事务等）。可以在工程化层面来解决模块耦合问题，例如 maven 、gradle 多模块。
@dnjat

[flmn]

建议在接口层分开，服务层可以共享。

随着迭代，各个功能会有很多自己独特的东西的，左右兼顾不如一开始就分开，工作量并没有增加太多，但是架构清晰了。

如果是单体，就在代码包结构上做好规划，如果是微服务，这种架构就是 BFF ，各端有自己的 BFF ，共享后端业务服务。

[dnjat]

@pannanxu 谢谢建议. 结构上的分包,共用也是不错的方法.

[dnjat]

@flmn 现在打算改成这样的结构了.核心共用,接口分开. 方便维护,结构清晰一点. 谢谢建议