概述
本文章只是簡單介紹了微服務開發的一些關鍵詞，如果需要知道具體實現和可以評論留言 我會及時的增加連接寫出具體實現(感覺沒人看 就沒寫具體實現)。
先說下分布式系統的CAP理論：
C：一致性 A：可用性P：分區容錯性
BASE Basically Available(基本可用)，Soft State(軟狀態)，Eventually consistent(最終一致性) 理論是CAP一致性和可用性的權衡結果
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風格的請求。
@FeignClient(value = "order")，它代表的是一個Feign客戶端，而配置的order是一個服務的ID(Service ID)它指向了用戶微服務
這樣Feign就會知道向用戶微服務請求，並實現負載均衡。這里的注解@GetMapping代表啟動HTTP的GET請求用戶微服務，
而方法中的注解@PathVariable代表從URL中獲取參數，(和SpringMVC規則相同)
斷路器—Hystrix
在互聯網中，某一個微服務可能出現故障，為了不蔓延到其他微服務上面導致雪崩效應。斷路器會將產生故障的服務節點進行"熔斷"，保持各個微服務持續可用。
處理熔斷的方式有 限流、緩存、服務降級，下面介紹服務降級。
所謂降級服務，就是當請求發生超時或者發生故障時，就會使用自身服務的其他方法進行相應。
在服務啟動類上加@EnableHystrix注解表示啟動斷路機制，
方法上增加@HystrixCommand注解，其屬性fallbackMethod則可以指定降級方法
對於Hystrix，Spring Cloud還提供了一個儀表盤進行監控短路的情況。
在注冊中心增加注解@EnableHystrixDashboard輸入URLhttp://127.0.0.1:8761/hystrix就可以看到Hystrix儀表盤首頁
路由網關Zuul
網關的功能對分布式網站十分重要，首先他可以將請求路由到真是服務器的IP地址，避免直接的攻擊真實服務器
其次它也可以作為一種負載均衡的手段，使請求按照一定的算法平攤到多個節點上，減緩單點的壓力。
程序啟動主類 注解：@EnableZuulProxy表示我現在要啟動的是一個Zuul的代理
從注解中可以看到，Zuul已經引入了斷路機制，之所以引入斷路機制，是因為在請求不到的時候，會進行斷路，以避免網關發生請求無法釋放的場景，導致微服務癱瘓。
zuul的配置：
表示zuul代理服務器home路徑下所有的請求轉發給user服務
https://www.jianshu.com/p/29e12ac2ce42
zuul和feign的區別
zuul的定位是網關，網關的作用是請求路由，相當於你服務的入口。然后根據請求的url不同轉發到不同的服務中去。就像nginx的反向代理。
需要通過Nginx負載均衡到不同的Zuul網關？？
feign是抽象的http請求工具。
Spring Cloud 通過Zuul路由到不同的服務，不同服務直接用Feign進行聲明式調用
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資源庫(只讀)，類似Win7操作系統中的光盤 如果想提供服務，還需要docker run命令，創建對應的容器並啟動服務
容器
是鏡像的實列，由Docker容器創建，類似我們的PC機，每一個PC機安裝了Win7的操作系統之后 都可以稱為Win7的實列
如果我們把Docker鏡像理解為Win7系統光盤的話，那么Docker容器就相當於裝了Win7系統的PC機。
倉庫
集中存放鏡像文件的地方(可以理解為GitHub這樣的托管服務器)
Jenkins
我們使用Git管理代碼，使用Maven構建項目，使用Docker封裝服務，這些事情都需要通過手工方式一步一步的完成，能否讓這些步驟自動的去執行呢？
也就是說開發人員將源代碼推送到Git遠程倉庫，自動進行Maven構建，並自動將構建生成的程序包放入Docker容器中。