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

微服務

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

分布式

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

關? 系

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

區? 別

(1)架構不同：微服務的設計是為了不因為某個模塊的升級和BUG影響現有的系統業務。微服務與分布式的細微差別是，微服務的應用不一定是分散在多個服務器上，他也可以是同一個服務器。

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

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

SpringCloud和Dubbo

• SpringCloud和Dubbo都是現在主流的微服務架構，SpringCloud是Apache旗下的Spring體系下的微服務解決方案，Dubbo是阿里系的分布式服務治理框架

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

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

• 服務網關,Dubbo并沒有本身的實現,只能通過其他第三方技術的整合,而SpringCloud有Zuul路由網關

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

Rest和RPC對比

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

SpringBoot和SpringCloud

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

• SpringBoot專注于快速方便的開發單個個體的微服務

• SpringCloud是關注全局的微服務協調整理治理框架,整合并管理各個微服務,為各個微服務之間提供,配置管理,服務發現,斷路器,路由,事件總線等集成服務

• SpringBoot不依賴于SpringCloud,SpringCloud依賴于SpringBoot,屬于依賴關系

• SpringBoot專注于快速,方便的開發單個的微服務個體,SpringCloud關注全局的服務治理框架

Eureka和ZooKeeper

????分布式系統中的三個重要特性：

• 一致性(Consistency)

• 可用性(Availability)

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

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

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

自我保護機制會導致：

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

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

• Eureka可以很好的應對因網絡故障導致部分節點失去聯系的情況,而不會像ZooKeeper一樣使得整個注冊系統癱瘓

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

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

? ? ? ?當Eureka Server 節點在短時間內丟失了過多實例的連接時(比如網絡故障或頻繁啟動關閉客戶端)節點會進入自我保護模式，保護注冊信息，不再刪除注冊數據，故障恢復時，自動退出自我保護模式。

GetMapping、PostMapping區別，PutMapping、DeleteMapping

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

• 請求資源應該使用GET??

• 添加資源應該使用POST??

• 更新資源應該使用PUT??

• 刪除資源應該使用DELETE