微服務架構springcloud

碼雲地址：https://gitee.com/lpxs/lp-springcloud.git 有問題能夠多溝通：136358344@qq.com。

微服務架構

1、服務化簡介

服務化的核心就是將傳統的一站式應用根據業務拆分紅一個一個的服務，而微服務在這個基礎上要更完全地去耦合，而且強調DevOps和快速演化。

• 服務化之Nginx
  Nginx經過接受客戶端Http請求，根據路徑配置，轉發，跳轉相應的服務。

1. Nginx配置中存在服務調用的邏輯
2. 服務消費者不知道真正服務提供者的實例。
3. 服務不易管理。

• 服務化之Dubbo
  Dubbo是阿里開源的一個SOA服務治理解決方案。服務消費者和提供者均可將服務信息註冊到Register，造成了服務中心的組件。經過Monitor進行很好的服務管理，消費者能夠進行負載均衡，服務降級等。

1. 致命的缺點-維護中止（阿里目前又着手維護）
2. Dubbo嚴重依賴於第三方組件（Zookeeper／Redis）
3. 因爲Dubbo的RPC調用，使得服務提供方與消費方有着代碼層次的高強度耦合。

• 服務化之Spring Cloud
  SpringCloud提出是開發面向雲端的Application，爲微服務提供了全套的組件技術支撐。值得注意的是：Spring Cloud拋棄了Dubbo的RPC通訊，採用了基於Http的Rest方式通訊。

下面介紹下重點介紹下springcloud組成

2、Spring Cloud

Spring Cloud共集成了19個子項目，裏面都包含一個或者多個第三方的組件或者框架！

• Spring Cloud Config 配置中心，利用git集中管理程序的配置。
• Spring Cloud Netflix 集成衆多Netflix的開源軟件
• Spring Cloud Bus 消息總線，利用分佈式消息將服務和服務實例鏈接在一塊兒，用於在一個集羣中傳播狀態的變化
• Spring Cloud for Cloud Foundry 利用Pivotal Cloudfoundry集成你的應用程序
• Spring Cloud Cloud Foundry Service Broker 爲創建管理雲託管服務的服務代理提供了一個起點。
• Spring Cloud Cluster 基於Zookeeper, Redis, Hazelcast, Consul實現的領導選舉和平民狀態模式的抽象和實現。
• Spring Cloud Consul 基於Hashicorp Consul實現的服務發現和配置管理。
• Spring Cloud Security 在Zuul代理中爲OAuth2 rest客戶端和認證頭轉發提供負載均衡
• Spring Cloud Sleuth SpringCloud應用的分佈式追蹤系統，和Zipkin，HTrace，ELK兼容。
• Spring Cloud Data Flow 一個雲本地程序和操做模型，組成數據微服務在一個結構化的平臺上。
• Spring Cloud Stream 基於Redis,Rabbit,Kafka實現的消息微服務，簡單聲明模型用以在Spring Cloud應用中收發消息。
• Spring Cloud Stream App Starters 基於Spring Boot爲外部系統提供spring的集成
• Spring Cloud Task 短生命週期的微服務，爲SpringBooot應用簡單聲明添加功能和非功能特性。
• Spring Cloud Task App Starters
• Spring Cloud Zookeeper 服務發現和配置管理基於Apache Zookeeper。
• Spring Cloud for Amazon Web Services 快速和亞馬遜網絡服務集成。
• Spring Cloud Connectors 便於PaaS應用在各類平臺上鍊接到後端像數據庫和消息經紀服務。
• Spring Cloud Starters （項目已經終止而且在Angel.SR2後的版本和其餘項目合併）
• Spring Cloud CLI 插件用Groovy快速的建立Spring Cloud組件應用。

下面介紹下咱們經常使用的系統架構

服務註冊與發現 Eureka

對於微服務的治理而言，核心就是服務的註冊和發現。在Spring Cloud 中提供了多種服務註冊與發現組件：Eureka,Consul,Zookeeper。官方推薦使用Eureka

Ribbon

Ribbon是Netflix發佈的開源項目，主要功能是爲REST客戶端實現負載均衡。

• 怎麼實現負載均衡經過註解@LoadBalanced 來實現負載均衡
• Ribbon的工做： >

1. 第一步有限選擇Eureka Server，它優先選擇在同一個Zone且負載較少的Server，
2. 第二步在根據用戶指定的策略，在從Server取到的服務註冊列表中選擇一個地址。其中Ribbon提供了多重策略，例如輪詢round robin、隨機Random、根據相應時間加權等。

Feign

Spring Cloud爲Feign增長了對Spring MVC註解的支持，還整合了Ribbon和Eureka來提供均衡負載的HTTP客戶端實現。Feign也用到ribbon，當你使用@ FeignClient，ribbon自動被應用。 原理：

• 經過@EnableFeignCleints註解開啓FeignCleint
• 根據Feign的規則實現接口，並加@FeignCleint註解,來綁定該接口對應服務
• 程序啓動後，會進行包掃描，掃描全部的@ FeignCleint的註解的類，並將這些信息注入IOC容器中。
• 當接口的方法被調用，經過jdk的代理，來生成具體的RequesTemplate，RequesTemplate再生成Request
• Request交給Client去處理，其中Client能夠是HttpUrlConnection、HttpClient
• 最後Client被封裝到LoadBalanceClient類，這個類結合類Ribbon作到了負載均衡。

spring cloud config

• 每一個項目都散落着各類配置文件，若是採用分佈式的開發模式，須要的配置文件隨着服務增長而不斷增多。某一個基礎服務信息變動，都會引發一系列的更新和重啓。
• Spring Cloud Config項目是一個解決分佈式系統的配置管理方案。它包含了Client和Server兩個部分，server提供配置文件的存儲、以接口的形式將配置文件的內容提供出去，client經過接口獲取數據、並依據此數據初始化本身的應用。Spring cloud使用git或svn存放配置文件，默認狀況下使用git。
• 真正的數據存在Git等repository中,Config Server去獲取相應的信息,而後與Client Application,相互間基於HTTP,TCP,UDP等協議的通訊.
• 當配置更改時，標有@RefreshScope的Spring @Bean將獲得特殊處理。這解決了狀態bean在初始化時只注入配置的問題。RefreshScope是上下文中的一個bean，它有一個公共方法refreshAll()來清除目標緩存中的範圍內的全部bean。還有一個refresh(String)方法能夠按名稱刷新單個bean。此功能在/refresh端點（經過HTTP或JMX）中公開。

服務網關 Zuul

• 將細粒度的服務組合起來提供一個粗粒度的服務，全部請求都導入一個統一的入口，那麼整個服務只須要暴露一個api，對外屏蔽了服務端的實現細節，也減小了客戶端與服務器的網絡調用次數。這就是api gateway。
• 可是若是後端服務多達十幾個的時候，每個都這樣配置也挺麻煩的，spring cloud zuul已經幫咱們作了默認配置。默認狀況下，Zuul會代理全部註冊到Eureka Server的微服務，而且Zuul的路由規則以下：http://ZUUL_HOST:ZUUL_PORT/微服務在Eureka上的serviceId/**會被轉發到serviceId對應的微服務。

服務追蹤分析Sleuth

Spring Cloud Sleuth爲Spring Cloud實現分佈式跟蹤解決方案。其兼容了Zipkin, HTrace和log-based追蹤 利用Spring Cloud Sleuth來和Zipkin進行集成。Spring Cloud Sleuth是對Zipkin的一個封裝，對於Span、Trace等信息的生成、接入HTTP Request，以及向Zipkin Server發送採集信息等所有自動完成。zipkin的存儲方式有多種，默認是保存在內存中，可是其不能持久保存，容器重啓等一些其餘狀況可能致使數據的丟失 Spring Cloud Sleuth 提供了兩種追蹤信息收集的方式，一種是經過 http 的方式，一種是經過 異步消息 的方式

• 提供鏈路追蹤。經過sleuth能夠很清楚的看出一個請求都通過了哪些服務。能夠很方便的理清服務間的調用關係。
• 可視化錯誤。對於程序未捕捉的異常，能夠在zipkin界面上看到。
• 分析耗時。經過sleuth能夠很方便的看出每一個採樣請求的耗時，分析出哪些服務調用比較耗時。當服務調用的耗時隨着請求量的增大而增大時，也能夠對服務的擴容提供必定的提醒做用。
• 優化鏈路。對於頻繁地調用一個服務，或者並行地調用等，能夠針對業務作一些優化措施。

斷路器Hystrix

• Netflix建立了一個名爲Hystrix的庫,實現了斷路器的模式。「斷路器」自己是一種開關裝置，當某個服務單元發生故障以後，經過斷路器的故障監控（相似熔斷保險絲），向調用方返回一個符合預期的、可處理的備選響應（FallBack），而不是長時間的等待或者拋出調用方沒法處理的異常，這樣就保證了服務調用方的線程不會被長時間、沒必要要地佔用，從而避免了故障在分佈式系統中的蔓延，乃至雪崩。
• 除了隔離依賴服務的調用之外，Hystrix還提供了準實時的調用監控（Hystrix Dashboard），Hystrix會持續地記錄全部經過Hystrix發起的請求的執行信息，並以統計報表和圖形的形式展現給用戶，包括每秒執行多少請求多少成功，多少失敗等。Netflix經過hystrix-metrics-event-stream項目實現了對以上指標的監控。Spring Cloud也提供了Hystrix Dashboard的整合，對監控內容轉化成可視化界面