SpringCloud マイクロサービス学習 (1)
SpringCloud アリババ
1.1. モノリシック分散クラスター
モノリス: スタンドアロン構造とも呼ばれ、プロジェクトはすべて 1 つのサーバーにデプロイされ、プロジェクト全体のすべてのサービス リソースはこのサーバーによって提供されます。
分散型: プロジェクトが大きくなるにつれて、単一システム内のサーバーの処理能力が制限されるため、プロジェクトサービスとMySQL サービスはそれぞれ 2 つ以上のサーバーに格納され、合理的な配置によってサーバー ハードウェアを制御できます。プロジェクトのカスタマイズ。
クラスタ: 分散構造では、単一障害点の問題が発生する可能性があります. このとき、サービスはバックアップされて同じサービスを提供するため、「クラスタ」が形成されます. クラスタ内の各サーバーはノードです.これらのノードを作成する順序は、すべて同じワークロードを持つことができ、ロード バランサーが機能します。
| 名前 | アドバンテージ | 欠点 |
|---|---|---|
| モノマー | 開発、展開、テストが容易 | 1 台のマシンの処理能力には限界があり、ビジネスがある程度成長し、ハードウェア リソースがビジネス ニーズを満たすことができない |
| 分散 | プロジェクトに従ってサーバーハードウェアを構成し、リソースを合理化します | 単一障害点の問題があり、サーバーがダウンするとサービスを提供できなくなります |
| 集まる | 1 台のマシンの障害、負荷分散の問題を解決 | 実装が比較的複雑で、クラスタが巨大になると、各ノードを維持するのが難しくなります |
1.2. システムアーキテクチャの進化
単一アプリケーション アーキテクチャ -> 垂直アプリケーション アーキテクチャ -> 分散アーキテクチャ -> SOA アーキテクチャ -> マイクロサービス アーキテクチャ
1.2.1. モノリシック アプリケーション アーキテクチャ
インターネットの黎明期には、アプリケーションは比較的小さく単純であり、開発、展開、および保守のコストを削減するために、すべての機能コードがまとめて展開されていました。
利点:
- プロジェクトの構造がシンプルで、小規模なプロジェクトの開発コストが低い
- プロジェクトは 1 つのノードにデプロイされるため、保守が容易です
短所:
- すべての機能が 1 つのプロジェクトに統合されているため、大規模なプロジェクトの開発と保守は容易ではありません
- プロジェクト モジュール間の密結合、低い単一点フォールト トレランス
- 異なるモジュールに対してターゲットを絞った最適化と水平展開を実行できない
1.2.2. 垂直アプリケーションのアーキテクチャ
アクセス数の増加に伴い、単一構造はノードを追加することでしか対応できませんが、すべてのモジュールでアクセス数が多いわけではないことがわかりました. 上記の e コマースを例にとると、ユーザーのアクセス数の増加は、影響 ユーザー モジュールとオーダー モジュールのみが使用されますが、メッセージ モジュールへの影響は比較的小さいため、現時点ではメッセージ モジュールではなく、オーダー モジュールをさらにいくつか追加したいと考えています。され、縦のアプリケーションを使用する必要があります. そして誕生しました.
いわゆる垂直アプリケーション アーキテクチャとは、元のアプリケーションを複数の独立したアプリケーションに分割して効率を向上させることです。たとえば、上記の e コマースの単一アプリケーションを次のように分割できます。
- ECシステム（ユーザー管理、商品管理、注文管理）
- バックグラウンドシステム（ユーザー管理・注文管理・顧客管理）
- CMSシステム（広告運営・マーケティング運営）
利点:
- システム分割は、トラフィック共有を実現し、並行性の問題を解決し、さまざまなモジュールに対して最適化および水平方向に拡張できます
- 1 つのシステムの問題が他のシステムに影響しないため、フォールト トレランスが向上します。
短所:
- システムは互いに独立しており、互いに呼び出すことはできません
- システムは互いに独立しており、開発作業が繰り返されます。
1.2.3、レイヤード アーキテクチャ
しかし、バーティカル アプリケーションが増えるにつれて、ビジネス コードの重複がますます増えていきます。プレゼンテーション層とサービス層を組み合わせた階層化アーキテクチャを形成する反復コードの抽出を検討します。ビジネス レイヤーにはビジネス ロジックが含まれ、プレゼンテーション レイヤーはページのやり取りを処理するだけで済みます。
利点:
- 共通機能をサービス層として抽出し、コードの再利用性を向上
短所:
- システム間の結合度が高くなり、アプリケーション間の関係が複雑になり維持が困難になる
1.2.4、SOA アーキテクチャ
分散型開発の下で、小規模なサービス リソースの浪費が徐々に発生しており、クラスターをリアルタイムで管理するスケジューリング センター、ユーザー リソースのスケジューリングおよびガバナンス センターを追加し、サービス指向を強調します。
利点:
- 登録センターを使用して、サービス間の通話関係の自動調整を解決します
短所:
- サービス間には依存関係があり、特定のリンクがうまくいかないと、より大きな影響を与えます (サービス雪崩)。
- サービス関係が複雑で、O&M、テスト、導入が難しい
1.2.5. マイクロサービスのアーキテクチャー
マイクロサービス アーキテクチャは、サービスの「完全な分割」をより重視するサービス指向アーキテクチャ SOA の継続的な開発における次のステップと言えます。
利点:
- サービスの細分化、独立したパッケージ化、展開とアップグレード、各マイクロサービスの明確なタスク分割を保証し、拡張を容易にします
- マイクロサービスは、RESTful などの軽量の Http プロトコルを使用して相互に呼び出します
短所:
- 分散システム開発の技術コストが高い (フォールト トレランス、分散トランザクションなど)。
1.3. マイクロサービスアーキテクチャーの紹介
マイクロサービス アーキテクチャ: 簡単に言えば、単一のアプリケーションをさらに小さなサービスに分割することであり、各サービスは独立して実行できるプロジェクトです。
1.4. Spring Cloud の紹介
Spring Cloud はフレームワークのコレクションです。Spring Boot 開発を使用すると、サービス ディスカバリ登録、構成センター、メッセージ バス、ロード バランシング、サーキット ブレーカー、データ監視などの分散システムの開発が簡素化されます。Spring Cloud は、さまざまな企業の成熟したテスト済みフレームワークを組み合わせて、最終的に開発します。理解、展開、保守が容易な分散システム開発ツールのセット。
SpringBoot は個々のマイクロサービスの迅速かつ便利な開発に焦点を当てていますが、SpringCloud はグローバル マイクロサービスの調整とガバナンス フレームワークに焦点を当てており、SpringBoot によって開発された個々のマイクロサービスを統合および管理して、構成管理、サービス検出、サーキット ブレーカー、ルーティングなどの統合サービスを提供します。イベントバス、分散システムなど 一般に、SpringBoot は個々のマイクロサービスの迅速かつ便利な開発に重点を置いており、SpringCloud はグローバル サービス ガバナンス コンポーネントのコレクションに重点を置いています。
サービス ガバナンス Nacos Discovery
2.1. サービスガバナンスとは
サービス ガバナンス: マイクロサービス アーキテクチャの最もコアで基本的なモジュールであり、ユーザーは各マイクロサービスの自動登録と検出を実現できます。
サービス登録: 各サービスユニットは、まず、登録センターに自身のサービスの詳細情報を登録します。サービス登録センターは、リスト内のサービスが利用可能かどうかをハートビートでチェックし、利用できないサービスを排除します。
Service Discovery : サービスの呼び出し元は、サービス登録センターに問い合わせて、特定のサービス インスタンスにアクセスします。
2.2. 共通登録センター
- Zookeeper: これは分散サービス フレームワークであり、主に分散アプリケーションのデータ管理の問題 (状態同期サービス、クラスター管理など) を解決するために使用されます。
- Eureka: 主な機能は、サービスの登録と検出です。
- Consul: 主に、分散型およびサービス指向システムのサービス登録、サービス検出、および構成管理機能を提供します。
- Nacos: クラウドネイティブ アプリケーションを簡単に構築できる、動的なサービス検出、構成管理、およびサービス管理プラットフォームです。
2.3 ナコスの紹介
nacos は、マイクロサービスの検出、構成、および管理に取り組んでおり、動的なサービス検出サービス構成、サービス メタデータ、およびトラフィック管理を迅速に実現します。
コア機能:
- サービスの登録: REST リクエストを送信して、独自のサービスを Nacos サーバーに登録します。
- サービス ハートビート: Nacos サーバーはハートビート メカニズムによって維持されます, サービスが排除されるのを防ぐために常に利用可能であることを示します. デフォルトでは, ハートビートは 5 秒ごとに送信されます
- サービスの同期: クラスタはサービス インスタンスを相互に同期して、サービス情報の一貫性を確保します。
- サービス ディスカバリ: サービス コンシューマは、Nacos Server に登録されているサービス リストを取得し、それを Nacos Client でローカルにキャッシュし、Nacos Client でスケジュールされたタスクを開始して、サービスの最新のレジストリ情報を取得し、ローカル キャッシュに更新します。
- サービス ヘルス チェック: サービス インスタンスのヘルスをチェックするスケジュールされたタスクを開始します.インスタンスに 15 秒以上ハートビートがない場合、その health プロパティは false に設定され、インスタンスに 30 秒以上ハートビートがない場合. インスタンスを直接削除し、削除されたインスタンスがハートビートに応答する場合は再登録します
2.4. Nacos を使い始める
2.4.1. Nacos のインストール
下载地址: https://github.com/alibaba/nacos/releases
下载zip格式的安装包，然后进行解压缩操作,上课使用的Nacos Server版本是1.3.2
2.4.2. ナコスの起動
# 进入bin目录
cd bin
#在cmd中启动
startup.cmd -m standalone
2.4.3. Nacos へのアクセス
ブラウザを開き、http://localhost:8848/nacos と入力してサービスにアクセスします。デフォルトのパスワードは nacos/nacos です。
2.5. プロジェクトでの使用方法
2.5.1. pom.xml に Nacos 依存関係を追加
<!--nacos客户端-->
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>
2.5.2. **@EnableDiscoveryClient** アノテーションをスタートアップ クラスに貼り付けます
@SpringBootApplication
@EnableDiscoveryClient
public class ProductServer {
public static void main(String[] args) {
SpringApplication.run(ProductServer.class,args);
}
}
2.5.3. application.yml に Nacos サービスアドレスを追加
spring:
cloud:
nacos:
discovery:
server-addr: localhost:8848
リモート コール ロード バランシング リボン
負荷分散：複数の運用単位に負荷を分散して運用することで、発生箇所によってサーバー側負荷分散とクライアント側負荷分散に分けられます。
マイクロサービスでは、通常、クライアント側の負荷分散を使用します。つまり、サービスを呼び出す側が提供するサービスを決定します。
