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

微服務(wù)

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

分布式

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

關(guān)? 系

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

區(qū)? 別

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

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

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

SpringCloud和Dubbo

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

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

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

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

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

Rest和RPC對比

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

SpringBoot和SpringCloud

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

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

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

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

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

Eureka和ZooKeeper

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

• 一致性(Consistency)

• 可用性(Availability)

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

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

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

自我保護機制會導(dǎo)致：

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

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

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

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

???????eureka自我保護機制

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

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

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

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

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

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

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

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

總結(jié)

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

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