聊一聊SpringCloud的五大元件
聊一聊SpringCloud的五大元件
1.初始SpringCloud
微服務是一種架構方式，最終肯定需要技術架構去實施。
微服務的實現方式很多，但是最火的莫過於Spring Cloud了。為什麼？
後臺硬：作為Spring家族的一員，有整個Spring全家桶靠山，背景十分強大。
技術強：Spring作為Java領域的前輩，可以說是功力深厚。有強力的技術團隊支撐，一般人還真比不了
群眾基礎好：可以說大多數程式設計師的成長都伴隨著Spring框架，試問：現在有幾家公司開發不用Spring？SpringCloud與Spring的各個框架無縫整合，對大家來說一切都是熟悉的配方，熟悉的味道。
使用方便：相信大家都體會到了SpringBoot給我們開發帶來的便利，而SpringCloud完全支援SpringBoot的開發，用很少的配置就能完成微服務框架的搭建
1.1.簡介
SpringCloud是Spring旗下的專案之一，官網地址：http://projects.spring.io/spring-cloud/
Spring最擅長的就是整合，把世界上最好的框架拿過來，整合到自己的專案中。
SpringCloud也是一樣，它將現在非常流行的一些技術整合到一起，實現了諸如：配置管理，服務發現，智慧路由，負載均衡，熔斷器，控制匯流排，叢集狀態等等功能。其主要涉及的元件包括：
netflix
Eureka：註冊中心
Zuul：服務閘道器
Ribbon：負載均衡
Feign：服務呼叫
Hystix：熔斷器
以上只是其中一部分，架構圖
2.Eureka註冊中心
2.1.認識Eureka
問題分析
在剛才的案例中，user-service對外提供服務，需要對外暴露自己的地址。而consumer（呼叫者）需要記錄服務提供者的地址。將來地址出現變更，還需要及時更新。這在服務較少的時候並不覺得有什麼，但是在現在日益複雜的網際網路環境，一個專案肯定會拆分出十幾，甚至數十個微服務。此時如果還人為管理地址，不僅開發困難，將來測試、釋出上線都會非常麻煩，這與DevOps的思想是背道而馳的。
網約車
這就好比是 網約車出現以前，人們出門叫車只能叫出租車。一些私家車想做出租卻沒有資格，被稱為黑車。而很多人想要約車，但是無奈計程車太少，不方便。私家車很多卻不敢攔，而且滿大街的車，誰知道哪個才是願意載人的。一個想要，一個願意給，就是缺少引子，缺乏管理啊。
此時要叫車的人，只需要開啟APP，輸入你的目的地，選擇車型（服務型別），滴滴自動安排一個符合需求的車到你面前，為你服務，完美！
Eureka做什麼？
Eureka就好比是滴滴，負責管理、記錄服務提供者的資訊。服務呼叫者無需自己尋找服務，而是把自己的需求告訴Eureka，然後Eureka會把符合你需求的服務告訴你。
同時，服務提供方與Eureka之間通過“心跳”機制進行監控，當某個服務提供方出現問題，Eureka自然會把它從服務列表中剔除。
這就實現了服務的自動註冊、發現、狀態監控。
2.2.原理圖
基本架構：
3.負載均衡Robbin
什麼是Ribbon：
4.Hystix
4.1.簡介
Hystix，即熔斷器。
主頁：https://github.com/Netflix/Hystrix/
Hystix是Netflix開源的一個延遲和容錯庫，用於隔離訪問遠端服務、第三方庫，防止出現級聯失敗。
4.2.熔斷器的工作機制：
正常工作的情況下，客戶端請求呼叫服務API介面：
當有服務出現異常時，直接進行失敗回滾，服務降級處理：
當服務繁忙時，如果服務出現異常，不是粗暴的直接報錯，而是返回一個友好的提示，雖然拒絕了使用者的訪問，但是會返回一個結果。
這就好比去買魚，平常超市買魚會額外贈送殺魚的服務。等到逢年過節，超時繁忙時，可能就不提供殺魚服務了，這就是服務的降級。
系統特別繁忙時，一些次要服務暫時中斷，優先保證主要服務的暢通，一切資源優先讓給主要服務來使用，在雙十一、618時，京東天貓都會採用這樣的策略。
5.Feign
feign的中文意思是偽裝，為什麼叫偽裝？
Feign可以把Rest的請求進行隱藏，偽裝成類似SpringMVC的Controller一樣。你不用再自己拼接url，拼接引數等等操作，一切都交給Feign去做。
專案主頁：https://github.com/OpenFeign/feign
6.Zuul閘道器
使用Spring Cloud實現微服務的架構基本成型，大致是這樣的：
我們使用Spring Cloud Netflix中的Eureka實現了服務註冊中心以及服務註冊與發現；而服務間通過Ribbon或Feign實現服務的消費以及均衡負載；通過Spring Cloud Config實現了應用多環境的外部化配置以及版本管理。為了使得服務叢集更為健壯，使用Hystrix的融斷機制來避免在微服務架構中個別服務出現異常時引起的故障蔓延。
在該架構中，我們的服務叢集包含：內部服務Service A和Service B，他們都會註冊與訂閱服務至Eureka Server，而Open Service是一個對外的服務，通過均衡負載公開至服務呼叫方。我們把焦點聚集在對外服務這塊，直接暴露我們的服務地址，這樣的實現是否合理，或者是否有更好的實現方式呢？
先來說說這樣架構需要做的一些事兒以及存在的不足：
首先，破壞了服務無狀態特點。
為了保證對外服務的安全性，我們需要實現對服務訪問的許可權控制，而開放服務的許可權控制機制將會貫穿並汙染整個開放服務的業務邏輯，這會帶來的最直接問題是，破壞了服務叢集中REST API無狀態的特點。
從具體開發和測試的角度來說，在工作中除了要考慮實際的業務邏輯之外，還需要額外考慮對介面訪問的控制處理。
其次，無法直接複用既有介面。
當我們需要對一個即有的叢集內訪問介面，實現外部服務訪問時，我們不得不通過在原有介面上增加校驗邏輯，或增加一個代理呼叫來實現許可權控制，無法直接複用原有的介面。
面對類似上面的問題，我們要如何解決呢？答案是：服務閘道器！
為了解決上面這些問題，我們需要將許可權控制這樣的東西從我們的服務單元中抽離出去，而最適合這些邏輯的地方就是處於對外訪問最前端的地方，我們需要一個更強大一些的均衡負載器的 服務閘道器。
服務閘道器是微服務架構中一個不可或缺的部分。通過服務閘道器統一向外系統提供REST API的過程中，除了具備服務路由、均衡負載功能之外，它還具備了許可權控制等功能。Spring Cloud Netflix中的Zuul就擔任了這樣的一個角色，為微服務架構提供了前門保護的作用，同時將許可權控制這些較重的非業務邏輯內容遷移到服務路由層面，使得服務叢集主體能夠具備更高的可複用性和可測試性。
6.1.簡介
官網：https://github.com/Netflix/zuul
Zuul：維基百科：
電影《捉鬼敢死隊》中的怪獸，Zuul，在紐約引發了巨大騷亂。
事實上，在微服務架構中，Zuul就是守門的大Boss！一夫當關，萬夫莫開！
6.2.Zuul加入後的架構
不管是來自於客戶端（PC或移動端）的請求，還是服務內部呼叫。一切對服務的請求都會經過Zuul這個閘道器，然後再由閘道器來實現 鑑權、動態路由等等操作。Zuul就是我們服務的統一入口。
以上照抄自網路。