SpringCloud——學習筆記（一）

Spring Cloud

Spring cloud是一個基於Spring Boot實現的服務治理工具包，在微服務架構中用於管理和協調服務的。

爲何須要SpringCloud?

Monolith（單體應用）架構（最終部署的時候只有一份war包,其餘的以jar包的方式依賴來）：在項目很小的狀況下這種單體應用比較簡單。

Monolith（單體應用）架構存在的缺點（項目較大時）：

1. 編譯難，部署難，測試難。
2. 技術選擇難（技術不兼容）
3. 擴展難（單體應用中多個模塊的負載不均衡,咱們擴容高負載的時候,也把低負載的模塊也擴容,極大浪費了資源）

使用微服務架構就能夠解決單體項目缺點

MicroService(微服務)架構：

• 微服務就是把一個單體項目,拆分爲多個微服務,每一個微服務能夠獨立技術選型,獨立開發,獨立部署,獨立運維.而且多個服務相互協調,相互配合,最終完成用戶的價值。

1.優點：

• 複雜度可控：每個微服務專一於單一功能，並經過定義良好的接口清晰表述服務邊界。
• 獨立部署：當某個微服務發生變動時無需編譯、部署整個應用。
• 技術選型靈活：因爲每一個微服務相對簡單，故須要對技術棧進行升級時所面臨的風險就較低，甚至徹底重構一個微服務也是可行的。
• 容錯：在微服務架構下，故障會被隔離在單個服務中。
• 擴展：每一個服務能夠根據實際需求獨立進行擴展。

2.使用場景

• 單體應用架構：中小型項目(功能相對較少) crm 物流 庫存管理等
• 微服務架構：大型項目（功能比較多） 商城 erp等
• 微服務spring的解決方案
  • ①單個服務:springboot
  • ②服務間協調:springcloud

Spring Cloud & dubbo對比

• Dubbo：中國各互聯網公司在用。

• Spring cloud：dubbo曾經確實很牛逼，可是Spring Cloud是站在近些年技術發展之上進行開發，所以更具技術表明性。

Spring cloud是微服務架構中服務治理工具集，有不少產品組成。核心爲五大神獸。相較於dubbo更加靠譜

SpringCloud的組成

• 服務發現——Netflix Eureka
• 客服端負載均衡——Netflix Ribbon/Feign
• 服務網關——Netflix Zuul
• 斷路器——Netflix Hystrix
• 分佈式配置——Spring Cloud Config

等19個框架，開源的隨時在增長。

Eureka註冊中心

​ 1.Eureka是netflix的一個子模塊，也是核心模塊之一 。

​ 2.使用eureka的客戶端鏈接到eureka server並維持心跳鏈接，經過eureka server來監控系統中各個微服務是否正常運行。

​ 三大角色

​ Eureka server提供服務註冊和發現：Eureka Server提供服務註冊服務。

​ Service Provider服務提供方 ：將自身服務註冊到Eureka，從而使服務消費方可以找到。

​ Service Consumer服務消費方：從Eureka獲取註冊服務列表，從而可以消費服務。

​ 單機註冊中心搭建

​ 1.建立項目

​ 建立一個普通maven項目

2.導入jar,pom.xml

<!--springboot支持-->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-test</artifactId>
</dependency>

<!--Eureka服務端支持-->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
</dependency>

3.yml配置

server:
  port: 7001
eureka:
  instance:
    hostname: localhost
  client:
    registerWithEureka: false #是否要註冊到eureka
    fetchRegistry: false #表示是否從Eureka Server獲取註冊信息
    serviceUrl:
      defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/ #單機配置

4.主類

@SpringBootApplication
@EnableEurekaServer //標識是eureka服務端
public class EnrekaServerApplication_7001 {
    public static void main(String[] args) {
        SpringApplication.run(EnrekaServerApplication_7001.class);
    }
}

5.測試（http://localhost:7001/）

負載均衡

爲何須要?

​ 爲了提供併發量，有時同一個服務提供者能夠部署多個。這個客戶端在調用時要根據必定的負責均衡策略完成負載調用。

Ribbon負載均衡:

​ 提供客戶端負載均衡算法

集成原理

​

內置負載均衡規則類	規則描述
RoundRobinRule（默認）	簡單輪詢服務列表來選擇服務器。它是Ribbon默認的負載均衡規則。
AvailabilityFilteringRule	對如下兩種服務器進行忽略： （1）在默認狀況下，這臺服務器若是3次鏈接失敗，這臺服務器就會被設置爲「短路」狀態。短路狀態將持續30秒，若是再次鏈接失敗，短路的持續時間就會幾何級地增長。 注意：能夠經過修改配置loadbalancer.<clientName>.connectionFailureCountThreshold來修改鏈接失敗多少次以後被設置爲短路狀態。默認是3次。 （2）併發數太高的服務器。若是一個服務器的併發鏈接數太高，配置了AvailabilityFilteringRule規則的客戶端也會將其忽略。併發鏈接數的上線，能夠由客戶端的<clientName>.<clientConfigNameSpace>.ActiveConnectionsLimit屬性進行配置。
WeightedResponseTimeRule	爲每個服務器賦予一個權重值。服務器響應時間越長，這個服務器的權重就越小。這個規則會隨機選擇服務器，這個權重值會影響服務器的選擇。
ZoneAvoidanceRule	以區域可用的服務器爲基礎進行服務器的選擇。使用Zone對服務器進行分類，這個Zone能夠理解爲一個機房、一個機架等。
BestAvailableRule	忽略哪些短路的服務器，並選擇併發數較低的服務器。
RandomRule	隨機選擇一個可用的服務器。
Retry	重試機制的選擇邏輯

Feign負載均衡(經常使用):

​ Feign是一個聲明式的Web Service客戶端，它的目的就是讓Web Service調用更加簡單

​ Feign具備以下特性：

​ 可插拔的註解支持，包括Feign註解和JAX-RS註解;

​ 支持可插拔的HTTP編碼器和解馬器;

​ 支持Hystrix和它的Fallback;

​ 支持Ribbon的負載均衡;

​ 支持HTTP請求和響應的壓縮。

Feign是以接口方式進行調用,而不是經過RestTemplate來調用,feign底層仍是ribbo,它進行了封裝,讓咱們調用起來更加容易。

當對同一個服務部署多個時，就要涉及負載均衡調用了，這是能夠選擇Ribbon和Feign。