マイクロサービスアーキテクチャの進化

マイクロサービスアーキテクチャの進化

マイクロサービスについて知る

サービスアーキテクチャの進化

モノリシック アーキテクチャ: すべてのビジネス機能を 1 つの開発プロジェクトに集中させ、パッケージとして展開します。

アドバンテージ：

• シンプルなアーキテクチャ
• 導入コストが低い

欠点:

• 高い結合度

分散アーキテクチャ: システムはビジネス機能に応じて分割され、各ビジネス モジュールはサービスと呼ばれる独立したプロジェクトとして開発されます。

アドバンテージ：

• サービス結合を減らす
• サービスのアップグレードと拡張に貢献

考慮すべき質問:

• サービス分割の粒度
• サービスクラスターアドレスを維持する方法
• サービス間のリモート呼び出しを実装する方法
• サービスの健全性ステータスを認識する方法

マイクロサービス

• 単一の責任: マイクロサービス分割の粒度はより小さく、各サービスは固有のビジネス機能に対応するため、単一の責任を実現し、繰り返しの開発を回避できます。
• サービス指向: マイクロサービスはビジネス インターフェイスを外部に公開します
• 自律性: チームの独立性、テクノロジーの独立性、データの独立性、展開の独立性
• 強力な分離: サービス コールは分離され、耐障害性があり、ダウングレードされ、連鎖的な問題が回避される必要があります。

マイクロサービステクノロジーの比較

ビジネスニーズ

スプリングクラウド

公式サイト：https://spring.io/projects/spring-cloud

サービス分割とリモート通話

サービス分割に関する注意事項:

• 異なるマイクロサービスに対して同じビジネスを繰り返し開発しないでください。
• マイクロサービス データは独立しており、他のマイクロサービスのデータベースにはアクセスしません
• マイクロサービスは、他のマイクロサービスが呼び出すためのインターフェイスとして独自のビジネスを公開できます。

リモート呼び出しメソッドの分析:

サービスリモートコール

RestTemplateクラスの使用

メインのスタートアップクラス

    @Bean
    @LoadBalanced
    public RestTemplate restTemplate() {
    
    
        return new RestTemplate();
    }

サービス

    @Autowired
    private RestTemplate restTemplate;

    public Order queryOrderById(Long orderId) {
    
    
        // 1.查询订单
        Order order = orderMapper.findById(orderId);
        Long userId = order.getUserId();
        String url = "http://userservice/user/"+userId;
        User user = restTemplate.getForObject(url, User.class);
        order.setUser(user);
        // 4.返回
        return order;
    }

プロバイダーと消費者

• サービスプロバイダー: ビジネス内の他のマイクロサービスによって呼び出されるサービス
• サービス利用者: ビジネスでは、他のサービスが呼び出されます。

エウレカ登録センター

サービスコールの問題

• サービス利用者はどのようにしてサービスプロバイダーのアドレス情報を取得するのでしょうか?

• • サービス提供者はサービス開始時に自身の情報をeurekaに登録します
  • エウレカはこの情報を保存します
  • コンシューマーはサービス名に基づいて eureka からプロバイダー情報を取得します。

• サービスプロバイダーが複数ある場合、消費者はどのように選択すればよいでしょうか?

• • サービス利用者は負荷分散アルゴリズムを使用してサービス リストから 1 つを選択します

• 消費者がサービス提供者の健康状態を知る方法

• • サービス プロバイダーは、ヘルス ステータスを報告するために 30 秒ごとに EurekaServer にハートビート リクエストを送信します。
  • エウレカはレコードサービスリストの情報を更新し、ハートビートが異常であれば削除します。
  • 消費者は最新情報を入手できる

エウレカ役

EurekaServer サービスを構築する手順は次のとおりです。

依存関係を導入する

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

@EnableEurekaServer アノテーションを追加

application.yml 構成ファイルを追加します

server:
  port: 10086 #服务端口
spring:
  application: # eureka的服务名称
    name: eurekaserver
eureka:
  client:
    service-url:  # eureka的地址信息
         defaultZone: http://127.0.0.1:10086/eureka

EurekaServiceの構成

依存関係を導入する

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

@EnableEurekaServer アノテーションを追加

application.yml 構成ファイルを追加します

server:
  port: 8081
spring:
  application: # eureka的服务名称
    name: userservice # user服务名称
eureka:
  client:
    service-url:  # eureka的地址信息
      defaultZone: http://127.0.0.1:10086/eureka

order-service でサービス プルを完了する

1. OrderService のコードを変更し、アクセスする URL パスを変更し、IP とポートの代わりにサービス名を使用します。

    public Order queryOrderById(Long orderId) {
    
    
        // 1.查询订单
        Order order = orderMapper.findById(orderId);
        Long userId = order.getUserId();
        String url = "http://userservice/user/"+userId;
        User user = restTemplate.getForObject(url, User.class);
        order.setUser(user);
        // 4.返回
        return order;
    }

2. order-service プロジェクトのスタートアップ クラス OrderApplication の RestTemplate に負荷分散アノテーションを追加します。

    @Bean
    @LoadBalanced
    public RestTemplate restTemplate() {
    
    
        return new RestTemplate();
    }

リボンの負荷分散原理

プロセス

ソースコード

負荷分散戦略

負荷分散ルールを変更する

• コード メソッド: order-service の OrderApplication クラスで、新しい IRule を定義します。

    @Bean
    public IRule randomRule(){
    
    
        return new RandomRule();
    }

• 構成ファイルによる方法: order-service の application.yml ファイルで、新しい構成を追加すると、ルールを変更することもできます。

userservice:
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule

飢えがいっぱい

リボンはデフォルトで遅延読み込みを採用しています。つまり、LoadBalanceClient は初回アクセス時にのみ作成され、リクエスト時間は非常に長くなります。プロジェクトの開始時にハングリー ローディングが作成され、最初の訪問の時間が短縮されます。次の構成を通じてハングリー ローディングを有効にします。

ribbon:
	eager-load:	
  	enabled: true # 开启饥饿加载
  	clients: userservice # 指定对userservice这个服务饥饿加载

ナコス登録センター

公式サイト：https://nacos.io/zh-cn/docs/v2/quickstart/quick-start.html

nacosへのサービス登録

頼る

親プロジェクト内 (人気がある場合は、まず依存関係にインポートして Maven を更新し、次に dependencyManagement にインポートします)

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>com.alibaba.cloud</groupId>
      <artifactId>spring-cloud-alibaba-dependencies</artifactId>
      <version>2.2.5.RELEASE</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

サブプロジェクト

        <dependency>
            <groupId>com.alibaba.cloud</groupId>
            <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
        </dependency>

アプリケーション.yml

spring:
  application:
    name: orderservice
  cloud:
    nacos:
      server-addr: localhost:8848

nacos サービスの階層ストレージ モデル

サービスのクラスタ間呼び出しの問題

  cloud:
    nacos:
      server-addr: localhost:8848
    	# 集群配置
      discovery:
        cluster-name: HZ #集群名称

ナコスコントロールセンター

クラスターに基づいた負荷分散

1. order-service の application.yml を変更し、クラスターを HZ に設定します。

userservice:
  ribbon:
  	# 优先同区域再随机
    NFLoadBalancerRuleClassName: com.alibaba.cloud.nacos.ribbon.NacosRule

重量に基づいた負荷分散

実際の展開では、次のシナリオが発生します。

• サーバー機器のパフォーマンスはさまざまで、パフォーマンスの高いマシンにインスタンスが配置されている場合もあれば、パフォーマンスの悪いマシンに配置されているインスタンスもあります。パフォーマンスの良いマシンがより多くのユーザー リクエストを処理できることを期待しています。

Nacos では頻繁なアクセスを保証するための重み設定が用意されており、重みが大きいほどアクセス頻度が高くなります。

500 エラーが発生した場合は、次のようになります。

環境分離名前空間

Nacos のサービス ストレージとデータ ストレージの最外層は名前空間と呼ばれるもので、最外部の分離に使用されます。

構成

yml設定

spring:
  cloud:
      nacos:
        server-addr: localhost:8848
        discovery:
          cluster-name: HZ
      	# 命名空间配置
          namespace: 7c20c8b7-1a7b-46f2-8451-5190cf114fcb

nacos登録センターの詳細分析

非一時的なインスタンスを構成する

spring:
  cloud:
      nacos:
        server-addr: localhost:8848
        discovery:
          cluster-name: HZ
          namespace: 7c20c8b7-1a7b-46f2-8451-5190cf114fcb
          ephemeral: false

ナコスとエウレカの共通点

• どちらもサービスの登録とサービスのプルをサポートします。
• すべてのサービス プロバイダーの健全性検査のハートビート方式をサポートします。

ナコスとエウレカの違い

• Nacos は、サーバーがプロバイダーのステータスをアクティブに検出することをサポートします。一時インスタンスはハートビート モードを使用し、非一時インスタンスはアクティブ検出を使用します。
• 異常なハートビートのある一時的なインスタンスは削除されますが、一時的ではないインスタンスは削除されません。
• Nacos はサービス リスト変更のメッセージ プッシュ モードをサポートしており、サービス リストはタイムリーに更新されます。

spring:
  cloud:
      nacos:
        server-addr: localhost:8848
        discovery:
          cluster-name: HZ
          namespace: 7c20c8b7-1a7b-46f2-8451-5190cf114fcb
          ephemeral: false

ナコスとエウレカの共通点

• どちらもサービスの登録とサービスのプルをサポートします。
• すべてのサービス プロバイダーの健全性検査のハートビート方式をサポートします。

ナコスとエウレカの違い

• Nacos は、サーバーがプロバイダーのステータスをアクティブに検出することをサポートします。一時インスタンスはハートビート モードを使用し、非一時インスタンスはアクティブ検出を使用します。
• 異常なハートビートのある一時的なインスタンスは削除されますが、一時的ではないインスタンスは削除されません。
• Nacos はサービス リスト変更のメッセージ プッシュ モードをサポートしており、サービス リストはタイムリーに更新されます。
• Nacos クラスターはデフォルトで AP モードを使用します。クラスター内に非一時インスタンスがある場合は CP モードが使用され、Eureka は AP モードを使用します。