聊聊分佈式開發 Spring Cloud

概述

本文章只是簡單介紹了微服務開發的一些關鍵詞，若是須要知道具體實現和能夠評論留言 我會及時的增長鏈接寫出具體實現(感受沒人看 就沒寫具體實現)。

持續更新中。。。。。。

SpringCloud和Dubbo的區別

Dubbo的定位始終是一款基於傳輸層(TCP)的RPC框架，RPC(Remote Procedure Call)通訊過程在傳輸層中完成(HTTP通訊在應用層完成)，

因此RPC調用方式須要服務端與客戶端之間創建Socket鏈接來實現二進制數據的交換

SpringCloud拋棄了Dubbo的RPC通訊，採用的是基於HTTP的REST方式(Spring Cloud就真正的將整個Rest做爲RPC實現技術)。 

而SpringCloud的目標是微服務架構下的一站式解決方案。

服務治理和服務發現Eureka

Spring的服務治理是使用Netflix的Eureka做爲服務治理的，它是咱們構建Spring Cloud分佈式最爲核心和最爲基礎的模塊，

他的做用是註冊和發現

@EnableEurekaServer ：在啓動類上添加@EnableEurekaServer註解，聲明這是一個Eureka Server

@EnableEurekaClient：將微服務註冊到Eureka Server上

@EnableDiscoveryClient：將微服務註冊到Eureka Server上

註解@EnableEurekaClient上有@EnableDiscoveryClient註解，
能夠說基本就是EnableEurekaClient有@EnableDiscoveryClient的功能
其實@EnableEurekaClientz註解就是一種方便使用eureka的註解而已，

Spring Boot服務，並提供監控管理功能。

每個微服務均可以像服務治理中心註冊多個節點(服務名稱相同，更改端口號 在啓動一次便可)

不少時候 咱們也但願服務治理中心也是多個節點，這纔可能知足高可用和負載均衡的要求

解決辦法: 咱們能夠採用服務治理中心互相註冊來保持相互監控

服務治理中心名稱保持不變，將當前的服務治理中心節點A註冊到服務治理中心節點B，而後將服務治理中心節點B註冊到服務治理中心節點A。

Eureka心跳機制

微服務客戶端之因此能夠和Eureka保持聯繫，依靠的是心跳機制，也就是說你客戶端能夠本身來進行心跳的配置處理。

若是最大心跳時間間隔微服務沒有進行心跳(如配置2s心跳心跳一次 最大心跳時間間隔5s)，則認爲該微服務已經死宕機了(Eureka會默認出現紅字提醒)

微服務之間的調用

Rabbion其實是一個RestTemplate對象，經過註解@LoadBalance 可讓RestTemplete實現站點層到服務層負載均衡

也就是經過這個restTemplete對象調用用戶微服務請求的時候，Ribbon會自動給用戶微服務實現負載均衡，請求會被分攤到微服務的各個節點上。

Feign聲明式調用。

使用restTemplete對象調用除了編寫URL，還須要注意這些參數的組裝和結果的返回操做。爲了克服這些不友好，Spring Cloud提供了聲明式調用組件Feign。

Feign是一個基於接口的編程方式，開發者只須要聲明接口和配置註解，在調度接口方法時，Spring Cloud就根據配置來調度對應的REST風格的請求。

斷路器—Hystrix

在互聯網中，某一個微服務可能出現故障，爲了避免蔓延到其餘微服務上面致使雪崩效應。斷路器會將產生故障的服務節點進行"熔斷"，保持各個微服務持續可用。

處理熔斷的方式有 限流、緩存、服務降級，下面介紹服務降級。

所謂降級服務，就是當請求發生超時或者發生故障時，就會使用自身服務的其餘方法進行相應。

對於Hystrix，Spring Cloud還提供了一個儀表盤進行監控短路的狀況。

路由網關Zuul

網關的功能對分佈式網站十分重要，首先他能夠將請求路由到真是服務器的IP地址，避免直接的攻擊真實服務器

其次它也能夠做爲一種負載均衡的手段，使請求按照必定的算法平攤到多個節點上，減緩單點的壓力。

程序啓動主類 註解：@EnableZuulProxy表示我如今要啓動的是一個Zuul的代理

zuul的配置：

表示zuul代理服務器home路徑下全部的請求轉發給user服務

反向代理層到站點層的負載均衡

Nginx和Zuul的區別

https://www.jianshu.com/p/29e12ac2ce42

SpringCloud Stream

Spring Boot之中爲了方便開發者，已經整合了消息組件，也提供了有一系列的處理支持。若是按照這樣的方式在Spring Cloud之中進行消息處理，有些人會認爲比較麻煩。

因此在Spring Cloud裏面將消息整合的處理操做進行了進一步的抽象操做，實現了更加簡化的消息處理。

簡單總結：SpringCloud Stream就是實現了MDB功能，同時能夠增長更加簡化方便的整合消息組件。

SpringCloud Config

顧名思義SpringCloudConfig的核心做用就在於配置文件的管理上。

當項目開發複雜微服務有特別多幾百個的時候，對於配置文件的管理就很是麻煩，若是想要進行某一個項配置文件的變動(舉例 數據庫驅動變動)，那麼就有可能修改上百個配置文件。

SpringCloudConfig藉助SVN、GITHUB來進行微服務配置文件的保存，SpringCloudConfig保存的配置就是咱們GIT倉庫。

至於配置文件的安全問題(舉例 配置的JDBC不能泄露)，在SpringCloudConfig之中還提供有一些安全加密處理 密鑰處理、jsk安全處理。

本質：SpringCloudConfig要求咱們全部的配置服務項都要求放到GIT之中，咱們使用的時候進行加載，方便整套微服務架構中配置文件的統一管理。

Docker

幾乎每一個有趣的應用都至少有一個相似數據庫或者消息中間件的基礎設施服務，咱們能夠選擇把這些基礎設施服務安裝在本身的機器上。

不幸的是安裝起來並不容易，就好比說以前在window上安裝mysql各類問題。若是有一鍵安裝的配置就完美了，而且咱們並不喜歡在本身的機器上裝滿各類亂七八糟的服務。

所以咱們要用docker容器，docker將做爲一個容器運行咱們須要的全部的服務。(Nginx Mq Redis Mysql 等等等等)

Docker幾個重要的概念

鏡像

通常狀況下，咱們首先須要將程序打包到Docker鏡像中，隨後才能將鏡像交給其餘人使用。

容器

當咱們獲取到Docker鏡像之後，能夠隨時運行該Docker鏡像，此時變會啓動一個Docker容器，該容器將運行鏡像中封裝的程序

若是咱們把Docker鏡像理解爲JAVA類的話，那麼Docker容器就至關於Java實列。

倉庫

集中存放鏡像文件的地方(能夠理解爲GitHub這樣的託管服務器)

Jenkins

咱們使用Git管理代碼，使用Maven構建項目，使用Docker封裝服務，這些事情都須要經過手工方式一步一步的完成，可否讓這些步驟自動的去執行呢？

也就是說開發人員將源代碼推送到Git遠程倉庫，自動進行Maven構建，並自動將構建生成的程序包放入Docker容器中。