前言

目前創(chuàng)新互聯(lián)建站已為超過千家的企業(yè)提供了網(wǎng)站建設(shè)、域名、虛擬主機(jī)、網(wǎng)站托管、企業(yè)網(wǎng)站設(shè)計(jì)、網(wǎng)站維護(hù)等服務(wù)，公司將堅(jiān)持客戶導(dǎo)向、應(yīng)用為本的策略，正道將秉承"和諧、參與、激情"的文化，與客戶和合作伙伴齊心協(xié)力一起成長，共同發(fā)展。我們擁有完善的網(wǎng)絡(luò)基礎(chǔ)設(shè)施服務(wù)，能夠?yàn)槠髽I(yè)或個(gè)人提供域名注冊(cè)、虛擬主機(jī)、企業(yè)郵局、網(wǎng)站加速、數(shù)據(jù)庫、云主機(jī)等網(wǎng)絡(luò)基礎(chǔ)服務(wù)。

現(xiàn)在越來越多的公司開始擁抱Spring Cloud了，Spring Boot做為下一代 web 框架，Spring Cloud 作為最新最火的微服務(wù)的翹楚，你還有什么理由拒絕。很多Java方向的同學(xué)也開始積極的學(xué)習(xí)Spring Cloud，其實(shí)這邊還有一個(gè)問題就是說：雖然大家學(xué)了Eureka，Ribbon，Hystrix，Zuul，F(xiàn)eign等等，但是要運(yùn)用到實(shí)際的項(xiàng)目中去還是有些難度的。

微服務(wù)難就難在服務(wù)的拆分上，框架只是工具，很多人都會(huì)用，服務(wù)拆分，服務(wù)之間的關(guān)系這些都是在拆分時(shí)候需要考慮的事情。

今天就有一位同學(xué)給我發(fā)郵件，咨詢我下面2個(gè)問題：

下面以我自己的經(jīng)驗(yàn)來做一些解答，僅供參考：

關(guān)于第一個(gè)問題中的API是各個(gè)微服務(wù)下的Controller？

我們所說的API其實(shí)就是一個(gè)接口，大部分都是用Spring MVC方式去開發(fā)的，也就是Controller中的一個(gè)加了注解的方法，注解就是我們常用的那幾個(gè):

• @RequestMapping
• @GetMapping
• @PostMapping
• @PutMapping
• @DeleteMapping

關(guān)于第一個(gè)問題中的是否需要統(tǒng)一的一個(gè)工程，在里面封裝其他微服務(wù)的controller?

這種其實(shí)也沒有固定的模式，大部分是直接通過API網(wǎng)關(guān)轉(zhuǎn)發(fā)到你的業(yè)務(wù)服務(wù)上

以猿天地這樣的博客網(wǎng)站的業(yè)務(wù)類舉例：

有一個(gè)業(yè)務(wù)功能，當(dāng)我查看具體的博客文章的時(shí)候，需要返回的信息如下：

• 博文標(biāo)題
• 發(fā)布時(shí)間
• 作者
• 標(biāo)簽
• 閱讀數(shù)量
• 評(píng)論信息
• 作者信息（昵稱，介紹）

這個(gè)時(shí)候我們這個(gè)查看文章的接口其實(shí)就涉及到了3部分的數(shù)據(jù)，文章本身的信息，評(píng)論信息，作者的信息

就是有3個(gè)服務(wù)，用戶服務(wù)，博客服務(wù)，評(píng)論服務(wù)

那么問題來了，涉及到多個(gè)服務(wù)之前的交互，其實(shí)跟上面那位同學(xué)問我的是一樣的問題，是否需要統(tǒng)一工程，組裝其他服務(wù)？是否可以相互調(diào)用？

這種的話我推薦2種實(shí)現(xiàn)方式：

一. API網(wǎng)關(guān)直接轉(zhuǎn)發(fā)到博客服務(wù)中

我們這個(gè)API就是一個(gè)獲取博文信息的接口，主體肯定是博客服務(wù)，在博客服務(wù)中有一個(gè)博文信息的接口，在接口中去調(diào)用用戶服務(wù)提供的用戶信息接口，還要去調(diào)用評(píng)論服務(wù)中博文的評(píng)論信息，下面看偽代碼：

@GetMapping("/blog/detail/{id}")
public BlogInfo blogInfo(@PathVariable("id") Long id) {
 // 獲取博客信息
 Blog blog = blogService.getById(id);
 // 獲取用戶信息
 UserInfo userInfo = userFeignClient.getUserInfo(blog.getUserId());
 // 獲取評(píng)論信息
 CommentInfo commentInfo = commentFeignClient.getCommentInfo(id); 
 return 組裝所有信息返回。 
}

二.增加聚合服務(wù)層

集合服務(wù)層也就是上面那位同學(xué)說的是不是需要有一個(gè)統(tǒng)一的工程來做組裝服務(wù)的事情，這個(gè)就是說我們博客服務(wù)還是提供基礎(chǔ)的博客信息，單獨(dú)加一個(gè)業(yè)務(wù)的聚合服務(wù)用來組裝這些信息統(tǒng)一返回給調(diào)用方，偽代碼如下：

@GetMapping("/blog/detail/{id}")
public BlogInfo blogInfo(@PathVariable("id") Long id) {
 // 獲取博客信息
 Blog blog = blogFeignClient.getById(id);
 // 獲取用戶信息
 UserInfo userInfo = userFeignClient.getUserInfo(blog.getUserId());
 // 獲取評(píng)論信息
 CommentInfo commentInfo = commentFeignClient.getCommentInfo(id); 
 return 組裝所有信息返回。 
}

數(shù)據(jù)都是遠(yuǎn)程調(diào)用的，當(dāng)然這邊你可以并行去調(diào)用，還有一種方式就是聚合操作在API網(wǎng)關(guān)中進(jìn)行，這種方案也是可行的，我建議還是不要在網(wǎng)關(guān)中做，API網(wǎng)關(guān)盡量簡單，只轉(zhuǎn)發(fā)，增加聚合服務(wù)層是不錯(cuò)的選擇。

如果你的服務(wù)治理是用dubbo構(gòu)建的，聚合服務(wù)層也是比較好的方法，將dubbo服務(wù)聚合統(tǒng)一提供http接口給外部調(diào)用。

三.調(diào)用方自行去獲取各個(gè)數(shù)據(jù)

還有一種方式的話就是調(diào)用方自己去分別調(diào)用博客接口，評(píng)論接口，用戶接口，這樣的話接口只需要關(guān)注自己本身的數(shù)據(jù)，把組裝的問題交給的使用方，這種一般用的比較少，最好是一次性將要用的數(shù)據(jù)返回給調(diào)用方，反復(fù)調(diào)用特別是在移動(dòng)端，請(qǐng)求太多了，浪費(fèi)流量。

總結(jié)

至于要怎么去組裝數(shù)據(jù)，還是得你自己來定，可以將組裝放在對(duì)應(yīng)的業(yè)務(wù)服務(wù)中，也可以單獨(dú)增加一個(gè)聚合服務(wù)來組裝，也可以讓客戶端自己去組裝。

服務(wù)之間肯定是可以相互調(diào)用的，要是不能相互調(diào)用，那么你拆開還有什么意義，用Feign來調(diào)用服務(wù)接口，你就把它當(dāng)做Service之間的調(diào)用即可。

好了，以上就是這篇文章的全部內(nèi)容了，希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，如果有疑問大家可以留言交流，謝謝大家對(duì)創(chuàng)新互聯(lián)的支持。