本文讨论了在Spring Cloud微服务架构中API的设计问题，包括API是否为各业务下的Controller，以及微服务间如何交互。提出了三种解决方案：API网关直接转发、增加聚合服务层和调用方自行获取数据。建议在服务治理中，API网关应保持简洁，主要负责转发，而组装操作可在业务服务或独立的聚合服务层进行。
现在越来越多的公司开始拥抱Spring Cloud了，很多Java方向的同学也开始积极的学习Spring Cloud，其实这边还有一个问题就是说：虽然大家学了Eureka，Ribbon，Hystrix，Zuul，Feign等等，但是要运用到实际的项目中去还是有些难度的。
微服务难就难在服务的拆分上，框架只是工具，很多人都会用，服务拆分，服务之间的关系这些都是在拆分时候需要考虑的事情。
1、API是各个业务下的controller?还是统一的工程？
2、各个微服务之间相互调用服务，交叉调用行吗？
下面以我自己的经验来做一些解答，仅供参考：
关于第一个问题中的API是各个微服务下的Controller？
我们所说的API其实就是一个接口，大部分都是用Spring MVC方式去开发的，也就是Controller中的一个加了注解的方法，注解就是我们常用的那几个:
- @RequestMapping
- @GetMapping
- @PostMapping
- @PutMapping
- @DeleteMapping
关于第一个问题中的是否需要统一的一个工程，在里面封装其他微服务的controller?
这种其实也没有固定的模式，大部分是直接通过API网关转发到你的业务服务上
以猿天地这样的博客网站的业务类举例：
有一个业务功能，当我查看具体的博客文章的时候，需要返回的信息如下：
- 博文标题
- 发布时间
- 作者
- 标签
- 阅读数量
- 评论信息
- 作者信息（昵称，介绍）
这个时候我们这个查看文章的接口其实就涉及到了3部分的数据，文章本身的信息，评论信息，作者的信息
就是有3个服务，用户服务，
最低0.47元/天 解锁文章
扫一扫
1287
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
