負荷分散サービス

並行性を提供するために、時にはサービスプロバイダに複数（財やサービス）を展開することができます。コールは、特定の責任に基づいてコールのロードバランシング戦略を完了するには、このクライアント。
ここに画像を挿入説明
1）サービスプロバイダクラスタ

2）負荷分散サービスの消費者が使用されています

クラスタサービスプロバイダ - 同じサービス（サービス名）、複数を展開します

実際の生産は少数のサーバが同じサービスを展開する以上で、開発は区別するためにポートを使用することです。

8001のコピー
メインクラスを変更する - と改名
変更8002yml、ポート
サービスプロバイダ
再起動し、登録センター、および2つのサービスプロバイダ

達成するための技術のバランスをとるサービスの消費者共通の負荷

リボン

ここに画像を挿入説明

Javaの習慣に沿って、よりFeign-

装う底部またはリボン、単にパッケージには、私たちがインターフェイス経由で呼び出されてみましょう

統計は、呼び出しが完了し完成したプロキシオブジェクトを介して、代理オブジェクトインタフェースを実装することができます。

XXXXの
アドレス
YYYY（）

リボンロード・バランシング・コール

リボンは、クライアント・ロード・バランサ、サービス利用者の役割である
リボンネットフリックスは、中間層のサービスのクラウドのオープンソースプロジェクトにリリースされた、主な機能は、クライアントのロードバランシングアルゴリズムを提供することです。リボンクライアントコンポーネントは次のように再試行し、そのような接続タイムアウト、として、構成要素の包括的な範囲を提供します。簡単に言えば、リボンは、クライアント・ロード・バランサが、我々はリアロードバランサの設定ファイル内のすべてのマシンを一覧表示することができますで、リボンは接続する（など単純なポーリング、ランダム接続、など）一定のルールに基づいて自動的にあなたを助けますこれらのマシンは、我々はロードバランシングアルゴリズムリボンカスタマイズを使用することは非常に簡単でもあります。

リボンは、クライアント・ロード・バランサである、それはまた、カスタムをサポートして一定のルールに従って通話のバランスをとるマルチサーバーの負荷を行うことができます

統合の原則

ここに画像を挿入説明

ロードバランシング戦略

リボンの後。コールを完了するために一定の規則に従ってサービスインスタンスを選択するために来て、サービス名によるサービスのリストを取得するには、このルールは、戦略ロードバランシングと呼ばれています。

iRuleは
異なるサブクラスののiRuleを構成することによって、あなたは、サービスコールを完了するための具体的な戦略を選択するために、サービスリストから、ある別の負荷分散戦略を選択することができます。もちろん、あなたもカスタマイズすることができます。だから、バランスをとる戦略は、内蔵およびカスタムに分けることができますロードします。
内蔵の負荷分散戦略

内蔵の負荷分散ルール・クラスルール説明
RoundRobinRule（デフォルト）、単純なポーリングサービスのリストサーバーを選択します。これは、ルールのバランスを取るリボンデフォルトの負荷です。
AvailabilityFilteringRuleは、次の二つのサーバでは無視する：
デフォルトでは（1）接続が3回失敗した場合、このサーバは、このサーバは、「ショート」の状態に設定されます。30秒間短絡状態の接続が再び失敗した場合、短絡の継続時間は指数関数的に地面が増加します。
注：あなたが短絡状態が設定loadbalancer..connectionFailureCountThresholdを変更することで、接続失敗に設定された後の回数を変更することができます。デフォルトは3回です。
（2）同時高いサーバの数。サーバーへの同時接続の数が多い場合、configureクライアントAvailabilityFilteringRuleルールは無視されます。同時接続の回線数は、クライアント..ActiveConnectionsLimitプロパティで設定することができます。

WeightedResponseTimeRuleは、各サーバの重み値を与えられました。長いサーバー応答時間、サーバに軽量。このルールは、ランダムに重み値は、サーバーの選択に影響を与えるだろう、サーバーを選択します。
サーバーの選択に基づいてサーバに利用できるZoneAvoidanceRuleエリア。サーバーを使用してゾーンの分類は、ゾーンは、コンピュータ室、ようにラックとして理解することができます。
どのような短絡サーバは無視BestAvailableRule、同時サーバーの下の番号を選択しています。
ランダムに利用可能なサーバーを選択RandomRule。
選択論理リトライリトライメカニズム

装うロードバランシング

装うWebサービスのクライアントは、その目的は、Webサービスを簡単に呼び出しを行うために、宣言です。装うは、HTTP要求のためのテンプレートを提供し、書き込み、挿入注釈にシンプルなインターフェイスを介して、あなたは良い情報をHTTPリクエスト、フォーマット、アドレスなどのパラメータを定義することができます。装うがフルプロキシHTTP要求になり、私たちは、同じ方法でサービス要求と関連の処理を完了することができます呼び出すことのようにそれを呼び出す必要があります。明示的にこれらの二つの成分を使用するように装う統合リボンとHystrixは（Hystrixについて私たちは後で再訪）、あなたは私たちにはもはや必要性を聞かせすることができます。

集合的に、ふりは、以下の特性を有する：
ふりJAX-RS注釈やメモを含むプラグ可能なアノテーションをサポートし、;
プラガブルAN HTTPエンコーダとデコーダと
支持Hystrixそのフォールバック、
支持リボンロードバランシング。
HTTPリクエストとレスポンスのサポート圧縮。
それは少し私たちのspringmvcモードのマッピングコントローラ層をRequestMappingのように見えます。このモデルは、私たちの非常にお気に入りです。装うは、サービスをマッピングする@FeignClientです。

装うインタフェースモードはむしろRestTemplate、装う底部またはリボンによってコールよりも、起動され、それがカプセル化され、私たちはもっと幸せにそれらを呼びましょう。

Hystrixブレーカー

理想的な条件の下では、依存保健サービスが利用できるアプリケーションは、我々はすべての通常の要求を処理することができます。
ここに画像を挿入説明
サービス内の特定の遅延は、すべての要求は、依存サービスの依存関係I.でブロックされているとき

、私は障害物を依存している場合は、ほとんどのスレッドプールのサーバが（BLOCK）ブロックされたように見え、全体の回線サービスの安定性に影響を与える
ここに画像を挿入説明
複雑でを分散アプリケーションのアーキテクチャは、多くの依存関係を持っている、それは必然的にいくつかの点で失敗します。同時高い失敗のリスクがない場合は検疫措置に依存して、現在のアプリケーションおよびサービスがダウンしてきました

雪崩現象：一部のサービスの問題、雪崩現象の多くの問題が生じるが呼び出されます

ソリューション

    对依赖做隔离,Hystrix就是处理依赖隔离的框架,同时也是可以帮我们做依赖服务的治理和监控.。
  	当我们使用了Hystrix时，Hystrix将所有的外部调用都封装成一个HystrixCommand或者			HystrixObservableCommand对象，这些外部调用将会在一个独立的线程中运行。我们可以将出现		问题的服务通过熔断、降级等手段隔离开来，这样不影响整个系统的主业务

Hystrixそのマイクロサービスグループを確保する堅牢なフレームワークであり、ヒューズ、降格および他の操作を単離した。最終的にはない特定のサービスの問題は、アバランシェ現象によって引き起こされるので、グループ全体が死んだように。

Hystrixプロフィール

Hystrix外国のよく知られた動画サイトネットフリックスは、非常に人気のあるオープンソースの高可用性アーキテクチャフレームワークです。Hystrixは、分散システムアーキテクチャに最適なソリューションは、技術的な一連の問題に直面した高可用性サービスを作成することができます。

Hystrix「ヤマアラシは、」自分自身を保護する能力を持っています。アバランシェ効果のメカニズムに従うことによって問題を解決するためにhystrix。

リソースアイソレーション（制限）は：サービスコール分散リソースの使用を制限する、スレッドプールのセマフォ隔離検疫を含め、サービスの問題への呼び出しは、他のサービスコールには影響を与えません。

ヒューズは：故障率を自動的にしきい値に達する（/タイムアウトが生じネットワーク障害の結果として故障率）ダウングレードをトリガするとき、ヒューズ障害が急速に急速な回復をトリガします。

ダウングレードのメカニズム：タイムアウト格下げ、リソース（スレッドやセマフォ）の欠如ダウングレードは、ダウングレード後にデータを返すために、バッキングとのインターフェイスをダウングレードすることがあります。

キャッシュ：キャッシュは、要求を提供し、達成するために合併を要求します。

原理分析 - コマンドモード

Hystrix使用命令模式(继承HystrixCommand(隔离)类)来包裹具体的服务调用逻辑(run方法), 并在命令模式中添加了服务调用失败后的降级逻辑(getFallback).
同时我们在Command的构造方法中可以定义当前服务线程池和熔断器的相关参数.
ここに画像を挿入説明
在使用了Command模式构建了服务对象之后, 服务便拥有了熔断器和线程池的功能.

隔离：每次调用都只影响自己
熔断：调用同一个服务多个失败，后面再来调用时，就暂时不调用，隔一段时间再进行调用，如果能调用，就恢复。
降级：要给我一个保底处理。 --一点反应都没有，给他报一个错

资源隔离&限流

ここに画像を挿入説明

（1）线程池隔离模式：使用一个线程池来存储当前请求，线程池对请求作处理，设置任务返回处理超时时间，堆积的请求先入线程池队列。这种方式要为每个依赖服务申请线程池，有一定的资源消耗，好处是可以应对突发流量（流量洪峰来临时，处理不完可将数据存储到线程池队里慢慢处理）
（2）信号量隔离模式：使用一个原子计数器（或信号量）记录当前有多少个线程在运行，请求来先判断计数器的数值，若超过设置的最大线程个数则丢弃该类型的新请求，若不超过则执行计数操作请求来计数器+1，请求返回计数器-1。这种方式是严格的控制线程且立即返回模式，无法应对突发流量（流量洪峰来临时，处理的线程超过数量，其他的请求会直接返回，不继续去请求依赖的服务）
ここに画像を挿入説明

服务熔断

正常情况下，断路器处于关闭状态(Closed)，
如果调用持续出错或者超时，电路被打开进入熔断状态(Open)，后续一段时间内的所有调用都会被拒绝(Fail Fast)，
一段时间以后，保护器会尝试进入半熔断状态(Half-Open)，允许少量请求进来尝试，
如果调用仍然失败，则回到熔断状态
如果调用成功，则回到电路闭合状态;
ここに画像を挿入説明
熔断的参数配置

Hystrix提供了如下的几个关键参数，来对一个熔断器进行配置：

circuitBreaker.requestVolumeThreshold //滑动窗口的大小，默认为20
circuitBreaker.sleepWindowInMilliseconds //过多长时间，熔断器再次检测是否开启，默认为5000，即5s钟
circuitBreaker.errorThresholdPercentage //错误率，默认50%

3个参数放在一起，所表达的意思就是：
每当20个请求中，有50%失败时，熔断器就会打开，此时再调用此服务，将会直接返回失败，不再调远程服务。直到5s钟之后，重新检测该触发条件，判断是否把熔断器关闭，或者继续打开。

服务降级

有了熔断，就得有降级。所谓降级，就是当某个服务熔断之后，服务器将不再被调用，此时客户端可以自己准备一个本地的fallback回调，返回一个缺省值。
这样做，虽然服务水平下降，但好歹可用，比直接挂掉要强，当然这也要看适合的业务场景。
注意:
1 熔断是在服务提供方做
2 调用时不能使用feign调用(有自己熔断机制),要用ribbon调用

Zuul路由网关

Zuul 是netflix开源的一个API Gateway 服务器, 本质上是一个web servlet应用。
Zuul 在云平台上提供动态路由，监控，弹性，安全等边缘服务的框架。Zuul 相当于是设备和 Netflix 流应用的 Web 网站后端所有请求的前门，也要注册入Eureka.
ここに画像を挿入説明官网资料
https://github.com/Netflix/zuul

基本配置

pom

<!--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>

	<dependency>
			<groupId>org.springframework.cloud</groupId>
			<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
		</dependency>

		<dependency>
			<groupId>org.springframework.cloud</groupId>
			<artifactId>spring-cloud-starter-netflix-zuul</artifactId>
		</dependency>

yml

  server:
  port: 4399
spring:
  application:
    name: ZUUL-GATEWAY
eureka:
  client:
    service-url:
      defaultZone: http://localhost:7001/eureka #集群环境配置需要改一下
  instance:
    instance-id: gateway-9527.com
    prefer-ip-address: false

修改入口类
ここに画像を挿入説明

路由访问映射规则

安全加固：不用服务名,映射路径
2) 忽略原来服务名访问：原来模式不可以访问
3) 加上统一前缀

zuul:
  routes:
    myUser.serviceId: user-provider # 服务名
    myUser.path: /myUser/** # 把myUser打头的所有请求都转发给user-provider
  ignored-services: "*" #所有服务都不允许以服务名来访问
  prefix: "/services" #加一个统一前缀

过滤器

Zuul作为网关的其中一个重要功能，就是实现请求的鉴权。而这个动作我们往往是通过Zuul提供的过滤器来实现的。

ZuulFilter

ZuulFilter是过滤器的顶级父类。其中定义的4个最重要的方法：

shouldFilter：返回一个Boolean值，判断该过滤器是否需要执行。返回true执行，返回false不执行。
run：过滤器的具体业务逻辑。
filterType：返回字符串，代表过滤器的类型。包含以下4种：
- pre：请求在被路由之前执行
- routing：在路由请求时调用
- post：在routing和errror过滤器之后调用
- error：处理请求时发生错误调用
filterOrder：通过返回的int值来定义过滤器的执行顺序，数字越小优先级越高。

过滤器执行周期

这张是Zuul官网提供的请求生命周期图，清晰的表现了一个请求在各个过滤器的执行顺序。
ここに画像を挿入説明

正常流程：
- 请求到达首先会经过pre类型过滤器，而后到达routing类型，进行路由，请求就到达真正的服务提供者，执行请求，返回结果后，会到达post过滤器。而后返回响应。
异常流程：
- 整个过程中，pre或者routing过滤器出现异常，都会直接进入error过滤器，再error处理完毕后，会将请求交给POST过滤器，最后返回给用户。
- 如果是error过滤器自己出现异常，最终也会进入POST过滤器，而后返回。
- 如果是POST过滤器出现异常，会跳转到error过滤器，但是与pre和routing不同的时，请求不会再到达POST过滤器了。

负载均衡与熔断

Zuul中默认就已经集成了Ribbon负载均衡和Hystix熔断机制。但是所有的超时策略都是走的默认值，比如熔断超时时间只有1S，很容易就触发了。因此建议我们手动进行配置：

zuul:
  retryable: true
ribbon:
  ConnectTimeout: 250 # 连接超时时间(ms)
  ReadTimeout: 2000 # 通信超时时间(ms)
  OkToRetryOnAllOperations: true # 是否对所有操作重试
  MaxAutoRetriesNextServer: 2 # 同一服务不同实例的重试次数
  MaxAutoRetries: 1 # 同一实例的重试次数
hystrix:
  command:
    default:
      execution:
        isolation:
          thread:
            timeoutInMillisecond: 3000 # 熔断超时时长：3000ms

SpringCloud Config分布式配置中心

微服务架构中，每个项目都有一个yml配置，管理起来麻烦，因为没有统一的地方管理，改了一点儿配置都需要改jar包。要使用spring cloud config来统一管理。

在分布式系统中，由于服务数量巨多，为了方便服务配置文件统一管理，实时更新，所以需要分布式配置中心组件。在Spring Cloud中，有分布式配置中心组件spring cloud config ，它支持配置服务放在配置服务的内存中（即本地），也支持放在远程Git仓库中。在spring cloud config 组件中，分两个角色，一是config server，二是config client。

操作

服务端配置

1.github创建配置文件
ここに画像を挿入説明
2.创建springboot项目并且导入jar

<dependencies>
    <!--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-client</artifactId>
    </dependency>
    <!--配置中心支持-->
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-config-server</artifactId>
    </dependency>
</dependencies>

3.Yml

server:
  port: 1299
eureka:
  client:
    service-url:
      defaultZone: http://eureka-7001.com:7001/eureka,http://eureka-7002.com:7002/eureka # 集群

  instance:
    prefer-ip-address: true
spring:
  application:
    name: spring-cloud-config-server
  cloud:
    config:
      server:
        git:
          uri: https://github.com/xxx/microservice-config.git
          username: xxx
          password: xxx

4).启动类

@SpringBootApplication
@EnableEurekaClient //加入注册中心
@EnableConfigServer //启用配置服务端
public class ConfigServerApplication_1299 {
 public static void main(String[] args) {
     SpringApplication.run(ConfigServerApplication_1299.class);
 }
}

客户端配置

新建config_client_3355 springboot项目，为了读取github的配置文件
导入jar

<dependencies>
    <!--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-client</artifactId>
</dependency>

    <!--configclient端-->
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-config</artifactId>
    </dependency>
</dependencies>

准备yml
全局bootstrap.yml

spring:
Application
Name 
  cloud:
    config:
      name: application-user #github上面名称
      profile: test #环境
      label: master #分支
      uri: http://127.0.0.1:1299 #配置服务器
eureka:
  client:
    service-url:
     defaultZone: http://eureka-7001.com:7001/eureka,http://eureka-7002.com:7002/eureka # 集群

  instance:
    prefer-ip-address: true #显示客户端真实ip

入口类

@SpringBootApplication
@EnableEurekaClient
public class ConfigClientApplication {
    public static void main(String[] args) {
        SpringApplication.run(ConfigClientApplication.class,args);
    }
}

早春一去又如何

公開された14元の記事・ウォンの賞賛5 ・ビュー674

プライベートの手紙の懸念

springcloud2