SpringCloud微服務

微服務架構：微服務是系統架構上的一種設計風格，它的主旨是將一個本來獨立的系統拆分紅多個小型服務，這些小型服務都在各自獨立的進程中進行，服務之間經過基於HTTP的RESTful API進行通訊協做。被拆分的每個小型服務都圍繞着系統中的某一項或一些耦合度較高的業務功能進行構建，而且每一個服務都維護着自身的數據存儲、業務開發、自動化測試案例以及獨立部署機制。因爲有了輕量級的通訊協做基礎，因此這些微服務可使用不一樣的語言來編寫。

微服務架構的九大特徵：

　　一、服務組件化

    　　組件：是一個能夠獨立更換和升級的單元，而不影響其餘單元

　　二、按業務組織團隊

   　　 按業務線的方式進行拆分

　　三、作「產品」的態度

   　　 每一個小團隊對其產品的整個生命週期負責，而不是以項目的模式，已完成開發與交付並將成果交接給維護者以最終目標

　　四、智能端點與啞管道

    　　在單體應用中，組件間經過函數調用的方式進行交互協做，而在微服務架構中，因爲服務不在一個進程中，組件間的通訊模式發生了改變，若僅僅將本來在進程內的方法調用改

　　　成rpc方式的調用，會致使微服務之間產生繁瑣的通訊，使得系統表現更爲糟糕，因此咱們須要更粗粒度的通訊協議

    　　（1）使用HTTP的RESTful API或輕量級的消息發送協議，實現信息傳遞與服務調用的觸發

    　　（2）經過在輕量級消息總線上傳遞消息，相似RabbitMQ等一些提供可靠異步交換的中間件

　　五、去中心化治理

　　六、去中心化管理數據

    　　讓每個服務來管理其自有的數據庫

　　七、基礎設施自動化

　　八、容錯設計

　　九、演進式設計

 

springboot 用於構建微服務的基礎框架

 

高可用：

　　高度可用性，用平均故障時間MTTF來度量，即計算機系統平均可以正常運行多長時間，才發生一次故障。

服務註冊：

　　在服務治理框架中，一般都會構建一個服務註冊中心，每一個服務單元向註冊中心提供的服務，將主機與端口號，版本號，通訊協議等一些附加信息告知註冊中心，註冊中心按服務名分類組織服務清單。

 

服務發現：

　　因爲在服務治理框架下運行，服務間的調用再也不經過指定具體的實例地址來實現，而是經過向服務名發起請求調用實現。因此，服務調用方在調用服務提供方接口的時候，並不知道具體的服務實例位置。所以，調用方須要向服務註冊中心諮詢服務，並獲取全部服務的實例清單， 以實現對具體服務實例的訪問。

 

高可用服務註冊中心：

　　實際上就是將本身做爲服務向其餘服務註冊中心註冊本身，這樣就能夠造成一組互相註冊的服務註冊中心，以實現服務清單的同步，達到高可用的效果。

 

服務發現與消費：

　　服務發現的任務由Eureka客戶端來完成，而服務消費的任務由Ribbon完成，Ribbon是一個基於HTTP和TCP的客戶端負載均衡器，它能夠在經過客戶端中配置的

　　RibbonServerList服務端列表去輪詢訪問以達到負載均衡的做用。當Ribbon與Eureka聯合使用時，Ribbon的服務實例清單 RibbonServerList會被DiscovEnableNIWServerList

 

Spring Cloud五大核心組件：

　　1、Eureka：服務註冊中心，維護一個註冊表，包含了各個服務所在機器的ip地址和端口號

　　2、Feign：使用@FeignClient註解在服務上聲明實際調用的服務，Feign Client會在底層根據你的註解，使用動態代理跟你指定的服務創建鏈接、構造請求、發起靕求、

　　　　獲取響應、解析響應，等等

　　3、Ribbon：提供了客戶端對服務調用的負載均衡，使用Round Robin輪詢算法

　　4、Hystrix：Hystrix是隔離、熔斷以及降級的一個框架

　　5、Zuul：爲微服務應用程序提供服務路由功能。Zuul是代理服務請求的服務網關

 

　　參考：

　　

　　Eureka：各個服務啓動時，Eureka Client都會將服務註冊到Eureka Server，而且Eureka Client還能夠反過來從Eureka Server拉取註冊表，從而知道其餘服務在哪裏

　　Ribbon：服務間發起請求的時候，基於Ribbon作負載均衡，從一個服務的多臺機器中選擇一臺

　　Feign：基於Feign的動態代理機制，根據註解和選擇的機器，拼接請求URL地址，發起請求

　　Hystrix：發起請求是經過Hystrix的線程池來走的，不一樣的服務走不一樣的線程池，實現了不一樣服務調用的隔離，避免了服務雪崩的問題

　　Zuul：若是前端、移動端要調用後端系統，統一從Zuul網關進入，由Zuul網關轉發請求給對應的服務