目錄
一, 服務(wù)架構(gòu)的演變
1.1 單體架構(gòu)
1.2 分布式架構(gòu)
1.3 微服務(wù)
1.4 SpringCloud
二, 服務(wù)拆分和遠(yuǎn)程調(diào)用
2,1 服務(wù)拆分原則
2.2 服務(wù)拆分示例
2.3 創(chuàng)建相應(yīng)數(shù)據(jù)庫
?2.4 實(shí)現(xiàn)遠(yuǎn)程調(diào)用示例
1, 更改需求
2, 注冊RestTemplate實(shí)現(xiàn)遠(yuǎn)程調(diào)用
?2.5 服務(wù)消費(fèi)者和提供者
一, 服務(wù)架構(gòu)的演變
1.1 單體架構(gòu)
將業(yè)務(wù)的所有功能集中在一個項(xiàng)目中開發(fā),打成一個包進(jìn)行部署項(xiàng)目稱為單體架構(gòu).
假設(shè)有一個商城項(xiàng)目,該項(xiàng)目包含訂單模塊,用戶功能,商品功能以及支付功能,將該項(xiàng)目進(jìn)行部署時,只需要將該項(xiàng)目的所有功能打包成一個包部署在Tomcat上即可,該項(xiàng)目所有業(yè)務(wù)功能都只訪問一個數(shù)據(jù)庫,如圖所示:
單體架構(gòu)的優(yōu)點(diǎn):結(jié)構(gòu)簡單,部署成本低(只需要將整個項(xiàng)目打包放在一個Tomcat下即可);
單體架構(gòu)的缺點(diǎn):耦合度高(因?yàn)橐粋€項(xiàng)目中包含了所有業(yè)務(wù)功能,不同業(yè)務(wù)之間的數(shù)據(jù)都密切耦合).
1.2 分布式架構(gòu)
根據(jù)業(yè)務(wù)功能對系統(tǒng)進(jìn)行拆分,每個業(yè)務(wù)模塊作為獨(dú)立項(xiàng)目開發(fā),稱為一個服務(wù),多個這樣的服務(wù)的組合稱為分布式.
還是商城項(xiàng)目,項(xiàng)目包含4個業(yè)務(wù)功能,每個業(yè)務(wù)功能只需要開發(fā)和自己業(yè)務(wù)相關(guān)的代碼即可,用戶需要獲取數(shù)據(jù)時只需要調(diào)用相應(yīng)的模塊即可,但是這幾個模塊使用的還是同一個數(shù)據(jù)庫,如圖所示:
分布式架構(gòu)的優(yōu)點(diǎn):降低服務(wù)耦合(業(yè)務(wù)和業(yè)務(wù)之間相互獨(dú)立),有利于服務(wù)的升級和拓展(需要其他業(yè)務(wù)模塊時只需要單獨(dú)開發(fā)該模塊的代碼即可);
分布式架構(gòu)的缺點(diǎn):服務(wù)調(diào)用關(guān)系錯綜復(fù)雜(假設(shè)某一個業(yè)務(wù)模塊需要其他業(yè)務(wù)模塊時就需要調(diào)用其他模塊進(jìn)行數(shù)據(jù)的獲取).
1.3 微服務(wù)
分布式架構(gòu)相對于單體架構(gòu)一定程度上降低了業(yè)務(wù)模塊之間的耦合性,但是正因?yàn)闃I(yè)務(wù)模塊之間的耦合,不同業(yè)務(wù)模塊想要進(jìn)行交互時就會變的更加困難,還有我們定義的不同業(yè)務(wù)的粒度是多大,如何做到業(yè)務(wù)模塊拆分的比較合理等等都是需要進(jìn)一步解決的,所以引出了微服務(wù)的概念,微服務(wù)需要解決的問題如下:
- 服務(wù)粒度的拆分;
- 服務(wù)集群地址的維護(hù);
- 服務(wù)之間的遠(yuǎn)程調(diào)用;
- 服務(wù)健康狀態(tài)的感知.
微服務(wù)的架構(gòu)特征
- 單一職責(zé):微服務(wù)拆分粒度很小,每一個服務(wù)對應(yīng)唯一的業(yè)務(wù)能力,做到單一職責(zé);
- 自治:團(tuán)隊(duì)獨(dú)立,技術(shù)獨(dú)立,數(shù)據(jù)獨(dú)立,獨(dú)立部署和交付;
- 面向服務(wù):服務(wù)提供統(tǒng)一標(biāo)準(zhǔn)接口,與語言技術(shù)無關(guān);
- 隔離性強(qiáng):服務(wù)調(diào)用做好隔離,容錯,降級,避免出現(xiàn)級聯(lián)問題.
用戶進(jìn)行服務(wù)訪問時,會先經(jīng)過服務(wù)網(wǎng)關(guān),網(wǎng)關(guān)進(jìn)行請求的過濾和路由,路由到相應(yīng)的服務(wù)上,在相應(yīng)的服務(wù)上進(jìn)行數(shù)據(jù)庫的訪問等操作.
微服務(wù)的上述特性其實(shí)是在給分布式架構(gòu)制定一個標(biāo)準(zhǔn),進(jìn)一步降低服務(wù)之間的耦合度,提供服務(wù)的獨(dú)立性和靈活性,做到高內(nèi)聚低耦合.
1.4 SpringCloud
從上述微服務(wù)的特征來看,可以認(rèn)為微服務(wù)是一種經(jīng)過良好架構(gòu)設(shè)計的分布式架構(gòu)方案,但是方案該怎么落地?選用什么樣的技術(shù)棧?全球的互聯(lián)網(wǎng)公司都在積極嘗試自己的微服務(wù)落地方案,其中Java領(lǐng)域最引人注目的就是SpringCloud提供的方案了.
SpringCloud是目前國內(nèi)使用最廣泛的微服務(wù)框架;官網(wǎng)地址:Spring CloudSpring Cloud
SpringCloud集成了各種微服務(wù)功能組件,并基于SpringBoot實(shí)現(xiàn)了這些組件的自動裝配,從而提供了良好的開箱即用體驗(yàn),其中常見的組件包括:
二, 服務(wù)拆分和遠(yuǎn)程調(diào)用
任何分布式架構(gòu)都離不開服務(wù)的拆分,微服務(wù)也是一樣.
2,1 服務(wù)拆分原則
微服務(wù)拆分一般有以下幾個原則:
- 不同微服務(wù),不要重復(fù)開發(fā)相同業(yè)務(wù);
- 微服務(wù)數(shù)據(jù)獨(dú)立,不要訪問其他微服務(wù)的數(shù)據(jù)庫;
- 微服務(wù)可以將自己的業(yè)務(wù)暴露為接口,供其他微服務(wù)調(diào)用.
2.2 服務(wù)拆分示例
假設(shè)有一個微服務(wù)名為cloud-demo,其結(jié)構(gòu)如下:
?cloud-demo:父工程,管理依賴
- order-service:訂單微服務(wù),負(fù)責(zé)訂單相關(guān)業(yè)務(wù)
- user-service:用戶微服務(wù),負(fù)責(zé)用戶相關(guān)業(yè)務(wù)
要求:
- 訂單微服務(wù)和用戶微服務(wù)都必須有各自的數(shù)據(jù)庫,相互獨(dú)立
- 訂單微服務(wù)和用戶服務(wù)都對外暴露Restful的接口(供其他微服務(wù)進(jìn)行調(diào)用)
- 訂單服務(wù)如果需要查詢用戶信息,只能調(diào)用用戶服務(wù)的Restful接口,不能查詢用戶數(shù)據(jù)庫
2.3 創(chuàng)建相應(yīng)數(shù)據(jù)庫
因?yàn)椴煌⒎?wù)所使用的數(shù)據(jù)庫不一樣,所以這里為了演示效果分別給order-service和user-service項(xiàng)目在一個機(jī)器上創(chuàng)建兩個不同的數(shù)據(jù)庫作為區(qū)分
order-service項(xiàng)目的tb_order表:
?user-service項(xiàng)目的tb_user表:
?2.4 實(shí)現(xiàn)遠(yuǎn)程調(diào)用示例
在order-service服務(wù)中,有一個根據(jù)id查詢訂單的接口:
?根據(jù)查詢結(jié)果可以看到,返回的Order對象中的user屬性為null;
在user-service中有一個根據(jù)id查詢用戶的接口:
1, 更改需求
?order-service和user-service都可以根據(jù)id查詢到相應(yīng)的訂單和用戶信息,假設(shè)現(xiàn)在有一個需求是在查詢到訂單的同時返回相應(yīng)的用戶信息.
?因?yàn)椴煌瑯I(yè)務(wù)模塊之間是相互獨(dú)立的,在order-service中查詢相應(yīng)訂單的用戶信息就需要在order-service模塊下向user-service模塊下發(fā)送一次http請求調(diào)用http://localhost:8081/user/{userId}這個接口獲取到用戶信息后再進(jìn)行封裝返回.
大概得步驟是這樣的:
- 注冊一個RestTemplate的實(shí)例到Spring容器
- 修改order-service服務(wù)中的OrderService類中的queryOrderById方法,根據(jù)Order對象中的userId查詢User
- 將查詢的User填充到Order對象中一起返回
2, 注冊RestTemplate實(shí)現(xiàn)遠(yuǎn)程調(diào)用
1.我們在order-service服務(wù)中的OrderApplication啟動類中,注冊RestTemplate實(shí)例：
2.修改OrderService類中的queryOrderById方法實(shí)現(xiàn)遠(yuǎn)程調(diào)用
?3.重啟服務(wù)器查看結(jié)果
?2.5 服務(wù)消費(fèi)者和提供者
在服務(wù)調(diào)用關(guān)系中,會有兩個不同的角色:
- 服務(wù)提供者:一次業(yè)務(wù)中,被其他微服務(wù)調(diào)用的服務(wù)(提供接口給其他微服務(wù))
- 服務(wù)消費(fèi)者:一次業(yè)務(wù)中,調(diào)用其他微服務(wù)的服務(wù)(調(diào)用其他微服務(wù)提供的接口)
文章來源：http://www.zghlxwxcb.cn/news/detail-719959.html
?但是,服務(wù)提供者與服務(wù)消費(fèi)者的角色并不是絕對的,而是相對于業(yè)務(wù)而言,如果服務(wù)A調(diào)用了服務(wù)B,而服務(wù)B又調(diào)用了服務(wù)A,服務(wù)B既是服務(wù)提供者也是服務(wù)消費(fèi)者.文章來源地址http://www.zghlxwxcb.cn/news/detail-719959.html
到了這里，關(guān)于SpringCloud(一) 服務(wù)架構(gòu)的演變及注冊RestTemplate實(shí)現(xiàn)服務(wù)的遠(yuǎn)程調(diào)用的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
