? ? ?分布式和微服務(wù)是什么關(guān)系？簡(jiǎn)單來說，分布式和微服務(wù)的概念比較相似，分布式屬于微服務(wù)。但是分布式和微服務(wù)在架構(gòu)、作用和粒度上有所區(qū)別。因此，兩者的關(guān)系是既相互聯(lián)系又相互區(qū)別。本文主要帶大家認(rèn)識(shí)分布式和微服務(wù)，并探討一下兩者的關(guān)系，感興趣的小伙伴可以接著看下去。

微服務(wù)

? ? ? 微服務(wù)的意思也就是將模塊拆分成一個(gè)獨(dú)立的服務(wù)單元通過接口來實(shí)現(xiàn)數(shù)據(jù)的交互。簡(jiǎn)單來說微服務(wù)就是很小的服務(wù)，小到一個(gè)服務(wù)只對(duì)應(yīng)一個(gè)單一的功能，只做一件事。這個(gè)服務(wù)可以單獨(dú)部署運(yùn)行，服務(wù)之間可以通過RPC來相互交互，每個(gè)微服務(wù)都是由獨(dú)立的小團(tuán)隊(duì)開發(fā)，測(cè)試，部署，上線，負(fù)責(zé)它的整個(gè)生命周期。

分布式

? ? ? 分布式服務(wù)顧名思義服務(wù)是分散部署在不同的機(jī)器上的，一個(gè)服務(wù)可能負(fù)責(zé)幾個(gè)功能，是一種面向SOA架構(gòu)的，服務(wù)之間也是通過rpc來交互或者是webservice來交互的。邏輯架構(gòu)設(shè)計(jì)完后就該做物理架構(gòu)設(shè)計(jì)，系統(tǒng)應(yīng)用部署在超過一臺(tái)服務(wù)器或虛擬機(jī)上，且各分開部署的部分彼此通過各種通訊協(xié)議交互信息，就可算作分布式部署，生產(chǎn)環(huán)境下的微服務(wù)肯定是分布式部署的，分布式部署的應(yīng)用不一定是微服務(wù)架構(gòu)的，比如集群部署，它是把相同應(yīng)用復(fù)制到不同服務(wù)器上，但是邏輯功能上還是單體應(yīng)用。

關(guān)? 系

? ? ? 聯(lián)系：分布式只是一種手段，把不同的機(jī)器分散在不同的地方，然后這些機(jī)器間相互協(xié)助完成業(yè)務(wù)。微服務(wù)是一種特殊的分布式，換句話說，微服務(wù)架構(gòu)是分布式服務(wù)架構(gòu)的子集。微服務(wù)架構(gòu)通過更細(xì)粒度的服務(wù)切分，使得整個(gè)系統(tǒng)的迭代速度并行程度更高，但是運(yùn)維的復(fù)雜度和性能會(huì)隨著服務(wù)的粒度更細(xì)而增加。微服務(wù)重在解耦合，使每個(gè)模塊都獨(dú)立。分布式重在資源共享與加快計(jì)算機(jī)計(jì)算速度。

區(qū)? 別

(1)架構(gòu)不同：微服務(wù)的設(shè)計(jì)是為了不因?yàn)槟硞€(gè)模塊的升級(jí)和BUG影響現(xiàn)有的系統(tǒng)業(yè)務(wù)。微服務(wù)與分布式的細(xì)微差別是，微服務(wù)的應(yīng)用不一定是分散在多個(gè)服務(wù)器上，他也可以是同一個(gè)服務(wù)器。

(2)作用不同：分布式：不同模塊部署在不同服務(wù)器上，分布式主要解決的是網(wǎng)站高并發(fā)帶來問題。微服務(wù)：各服務(wù)可獨(dú)立應(yīng)用，組合服務(wù)也可系統(tǒng)應(yīng)用。

(3)粒度不同：微服務(wù)相比分布式服務(wù)來說，它的粒度更小，服務(wù)之間耦合度更低，由于每個(gè)微服務(wù)都由獨(dú)立的小團(tuán)隊(duì)負(fù)責(zé)，因此它敏捷性更高，分布式服務(wù)最后都會(huì)向微服務(wù)架構(gòu)演化，這是一種趨勢(shì)，不過服務(wù)微服務(wù)化后帶來的挑戰(zhàn)也是顯而易見的，例如服務(wù)粒度小，數(shù)量大，后期運(yùn)維將會(huì)很難。

SpringCloud和Dubbo

• SpringCloud和Dubbo都是現(xiàn)在主流的微服務(wù)架構(gòu)，SpringCloud是Apache旗下的Spring體系下的微服務(wù)解決方案，Dubbo是阿里系的分布式服務(wù)治理框架

• 從技術(shù)維度上,其實(shí)SpringCloud遠(yuǎn)遠(yuǎn)的超過Dubbo,Dubbo本身只是實(shí)現(xiàn)了服務(wù)治理。dubbo就像組裝機(jī)，springcloud就像品牌一體機(jī)，更加強(qiáng)大，它是微服務(wù)架構(gòu)下的一站式解決方案

• 服務(wù)的調(diào)用方式Dubbo使用的是RPC遠(yuǎn)程調(diào)用,而SpringCloud使用的是 Rest API,其實(shí)更符合微服務(wù)官方的定義

• 服務(wù)網(wǎng)關(guān),Dubbo并沒有本身的實(shí)現(xiàn),只能通過其他第三方技術(shù)的整合,而SpringCloud有Zuul路由網(wǎng)關(guān)

• 作為路由服務(wù)器,進(jìn)行消費(fèi)者的請(qǐng)求分發(fā),SpringCloud還支持?jǐn)嗦菲?與git完美集成分布式配置文件支持版本控制,事務(wù)總線實(shí)現(xiàn)配置文件的更新與服務(wù)自動(dòng)裝配等等一系列的微服務(wù)架構(gòu)要素

Rest和RPC對(duì)比

? ? ? 其實(shí)如果仔細(xì)閱讀過微服務(wù)提出者馬丁福勒的論文的話可以發(fā)現(xiàn)其定義的服務(wù)間通信機(jī)制就是Http Rest。RPC最主要的缺陷就是服務(wù)提供方和調(diào)用方式之間依賴太強(qiáng),我們需要為每一個(gè)微服務(wù)進(jìn)行接口的定義,并通過持續(xù)繼承發(fā)布,需要嚴(yán)格的版本控制才不會(huì)出現(xiàn)服務(wù)提供和調(diào)用之間因?yàn)榘姹静煌a(chǎn)生的沖突。REST是輕量級(jí)的接口,服務(wù)的提供和調(diào)用不存在代碼之間的耦合,只是通過一個(gè)約定進(jìn)行規(guī)范,但也有可能出現(xiàn)文檔和接口不一致而導(dǎo)致的服務(wù)集成問題,但可以通過swagger工具整合,是代碼和文檔一體化解決,所以REST在分布式環(huán)境下比RPC更加靈活。

SpringBoot和SpringCloud

? ? ? SpringBoot是Spring推出用于解決傳統(tǒng)框架配置文件冗余,裝配組件繁雜的基于Maven的解決方案,旨在快速搭建單個(gè)微服務(wù)，而SpringCloud專注于解決各個(gè)微服務(wù)之間的協(xié)調(diào)與配置,服務(wù)之間的通信,熔斷,負(fù)載均衡等；技術(shù)維度并相同,并且SpringCloud是依賴于SpringBoot的,而SpringBoot并不是依賴與SpringCloud,甚至還可以和Dubbo進(jìn)行優(yōu)秀的整合開發(fā)。

• SpringBoot專注于快速方便的開發(fā)單個(gè)個(gè)體的微服務(wù)

• SpringCloud是關(guān)注全局的微服務(wù)協(xié)調(diào)整理治理框架,整合并管理各個(gè)微服務(wù),為各個(gè)微服務(wù)之間提供,配置管理,服務(wù)發(fā)現(xiàn),斷路器,路由,事件總線等集成服務(wù)

• SpringBoot不依賴于SpringCloud,SpringCloud依賴于SpringBoot,屬于依賴關(guān)系

• SpringBoot專注于快速,方便的開發(fā)單個(gè)的微服務(wù)個(gè)體,SpringCloud關(guān)注全局的服務(wù)治理框架

Eureka和ZooKeeper

????分布式系統(tǒng)中的三個(gè)重要特性：

• 一致性(Consistency)

• 可用性(Availability)

• 分區(qū)容錯(cuò)性(Tolerance of network Partition)

? ? ? CAP原理是指這三個(gè)要素最多只能同時(shí)實(shí)現(xiàn)兩點(diǎn)，不可能三者兼顧。因此在進(jìn)行分布式架構(gòu)設(shè)計(jì)時(shí)，必須做出取舍。而對(duì)于分布式數(shù)據(jù)系統(tǒng)，分區(qū)容忍性是基本要求，否則就失去了價(jià)值。因此設(shè)計(jì)分布式數(shù)據(jù)系統(tǒng)，就是在一致性和可用性之間取一個(gè)平衡。對(duì)于大多數(shù)WEB應(yīng)用，其實(shí)并不需要強(qiáng)一致性，因此犧牲一致性而換取高可用性，是多數(shù)分布式數(shù)據(jù)庫產(chǎn)品的方向。

ZooKeeper保證的是CP,Eureka保證的是AP，ZooKeeper在選舉期間注冊(cè)服務(wù)癱瘓,雖然服務(wù)最終會(huì)恢復(fù),但是選舉期間不可用的，Eureka各個(gè)節(jié)點(diǎn)是平等關(guān)系,只要有一臺(tái)Eureka就可以保證服務(wù)可用,而查詢到的數(shù)據(jù)并不是最新的。

自我保護(hù)機(jī)制會(huì)導(dǎo)致：

• Eureka不再從注冊(cè)列表移除因長時(shí)間沒收到心跳而應(yīng)該過期的服務(wù)

• Eureka仍然能夠接受新服務(wù)的注冊(cè)和查詢請(qǐng)求,但是不會(huì)被同步到其他節(jié)點(diǎn)(高可用)，當(dāng)網(wǎng)絡(luò)穩(wěn)定時(shí),當(dāng)前實(shí)例新的注冊(cè)信息會(huì)被同步到其他節(jié)點(diǎn)中(最終一致性)

• Eureka可以很好的應(yīng)對(duì)因網(wǎng)絡(luò)故障導(dǎo)致部分節(jié)點(diǎn)失去聯(lián)系的情況,而不會(huì)像ZooKeeper一樣使得整個(gè)注冊(cè)系統(tǒng)癱瘓

ZooKeeper有Leader和Follower角色，而Eureka各個(gè)節(jié)點(diǎn)平等；ZooKeeper采用過半數(shù)存活原則,Eureka采用自我保護(hù)機(jī)制解決分區(qū)問題；Eureka本質(zhì)上是一個(gè)工程,而ZooKeeper只是一個(gè)進(jìn)程。

???????eureka自我保護(hù)機(jī)制

? ? ? ?當(dāng)Eureka Server 節(jié)點(diǎn)在短時(shí)間內(nèi)丟失了過多實(shí)例的連接時(shí)(比如網(wǎng)絡(luò)故障或頻繁啟動(dòng)關(guān)閉客戶端)節(jié)點(diǎn)會(huì)進(jìn)入自我保護(hù)模式，保護(hù)注冊(cè)信息，不再刪除注冊(cè)數(shù)據(jù)，故障恢復(fù)時(shí)，自動(dòng)退出自我保護(hù)模式。

GetMapping、PostMapping區(qū)別，PutMapping、DeleteMapping

• @GetMapping用于將http?get請(qǐng)求映射到特定處理程序的方法注解，屬于組合注解，是@RequestMapping(method=RequestMethod.GET)的縮寫

• 請(qǐng)求資源應(yīng)該使用GET??

• 添加資源應(yīng)該使用POST??

• 更新資源應(yīng)該使用PUT??

• 刪除資源應(yīng)該使用DELETE

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎(jiǎng)勵(lì)來咯，堅(jiān)持創(chuàng)作打卡瓜分現(xiàn)金大獎(jiǎng)

總結(jié)

以上是生活随笔為你收集整理的springcloud 相同服务名_浅谈分布式与微服务的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。