【SpringCloud5】SOAアーキテクチャとマイクロサービスアーキテクチャの関係

1.システムアーキテクチャの進化

インターネットの発展に伴い、ウェブサイトアプリケーションの規模は拡大し続けています。需要の急増は技術的な圧力をもたらします。したがって、システムアーキテクチャは常に進化、アップグレード、および反復されています。単一のアプリケーションから、垂直分割、分散サービス、SOA、そして今やホットなマイクロサービスアーキテクチャ、そしてGoogleが主導する急増するサービスメッシュまで。マイクロサービスボートに乗って遠くを航海するべきですか、それともただ通り過ぎるべきですか？

実際、人生は現在だけでなく、詩や距離にも関係しています。そこで本日は、歴史を振り返り、システムアーキテクチャの進化を見て、現在を把握し、最も人気のある技術アーキテクチャを学び、将来を楽しみにして、優れたJavaエンジニアになるよう努めます。

1.一元化されたアーキテクチャ

Webサイトのトラフィックが非常に少ない場合、必要なアプリケーションは1つだけで、すべての機能が一緒に展開されて、展開ノードとコストが削減されます。現時点では、追加、削除、変更、およびチェックのワークロードを簡素化するために使用されるデータアクセスフレームワーク（ORM）が、プロジェクト開発の鍵となります。

図に示すように、このシステムは3層アーキテクチャ、プレゼンテーション層、ビジネスロジック層、およびデータアクセス層を採用しています。3層アーキテクチャは、コード間の複雑な呼び出しとアプリケーションでの不明確なコードの責任の問題を解決します。しかし、彼はアプリケーションを物理的なレイヤーではなく、論理的に3つのレイヤーに分割するだけです。コンパイル、パッケージ化、展開の後、最終的には同じマシン上の同じプロセスで実行されます。この種の機能は一元化され、コードは一元化されます。 、リリースパッケージ、展開後に同じプロセスで実行されるアプリケーション。通常、これをモノリシックアプリケーションと呼びます。

モノリシックアプリケーションの利点は何ですか？

• 開発が簡単
• テストが簡単
• 展開が簡単

既存の問題：

• コード結合、開発と保守が難しい
• 異なるモジュール用に最適化することはできません
• 水平方向に拡大縮小できません
• シングルポイントの耐障害性が低く、同時実行性が低い
• テクノロジーの選択にはコストがかかります。モノリシックアプリケーションでは、新しいフレームワークと言語を採用することが非常に困難になります。たとえば、XYZフレームワークを使用して200万行のコードがある場合、ABCフレームワークを使用してコードを書き直したい場合、時間とコストの両方が非常に高くなります。新しいフレームワークが優れていても、これは新しいテクノロジーの使用の障害になります。
• 長い納期-一般的にリリーストレイン方式が採用されており、使用するすべての機能はリリース前に準備ができている必要があります。

2.垂直分割

訪問数が徐々に増えると、1つのアプリケーションで需要を満たすことができなくなります。現時点では、より高い同時実行性とビジネス要件に対応するために、ビジネス機能に応じてシステムを分割します。

利点：

• システム分割はトラフィック共有を実現し、同時実行の問題を解決します
• さまざまなモジュールに最適化できます
• 便利な水平方向の拡張、負荷分散、および改善された障害耐性

短所：

• システムは互いに独立しているため、開発作業が繰り返され、開発効率に影響します。

3.分散サービス

垂直型アプリケーションが増えると、アプリケーション間の相互作用が避けられなくなり、コアビジネスが独立したサービスとして抽出され、安定したサービスセンターが徐々に形成されるため、フロントエンドアプリケーションは変化する市場の需要に迅速に対応できます。現時点では、ビジネスの再利用と統合を改善するための分散型コールが重要です。

利点：

• 基本的なサービスが抽出され、システムが相互に呼び出しを行うため、コードの再利用と開発効率が向上します。

短所：

• システム間の結合度が高くなり、呼び出し関係が複雑になり、維持が困難になります

4.サービスガバナンスSOA

マイクロサービスとSOA

SOA

• SOAの最初の登場は、企業のさまざまなシステム間の統合の問題を解決し、サービスの再利用とメッセージバスを提案することです。
• SOAには多くのオーケストレーションがあり、通常はメッセージバスを介してビジネスロジックを実行し、重量のある集中型ミドルウェアを構築します。
• SOAの大きな問題はバスです。この考えによれば、これらのシステムは常に特定のリンクに集中化されるため、分散化は完全ではありません。

マイクロサービス

• 目標：企業が変更に迅速に対応できるようにする
• 目的：分散化

サービスが増えると、容量の評価や小さなサービスリソースの浪費が徐々に現れますが、このとき、アクセス圧力に基づいてクラスター容量をリアルタイムで管理し、クラスターの使用率を向上させるディスパッチセンターを追加する必要があります。現時点では、マシンの使用率を改善するために使用されるリソーススケジューリングおよびガバナンスセンター（SOA）が重要です

以前に何が起こったのですか？

• ますます多くのサービスが各サービスのアドレスを管理する必要があります
• 呼び出し関係は複雑で、依存関係を整理するのは困難です
• サービスが多すぎると、サービスステータスの管理が難しく、サービスの状況に応じて動的に管理できません。

サービスガバナンスは何をしますか？

• サービスアドレスを手動で記録することなく、自動サービス登録と検出を実現するサービス登録センター
• 自動サービスサブスクリプション、サービスリストの自動プッシュ、透過的なサービスコール、依存関係を気にする必要はありません
• 動的監視サービスステータス監視レポート、ヒューマンコントロールサービスステータス

短所：

• サービス間に依存関係があり、リンクが失敗すると、より大きな影響があります
• サービス関係は複雑で、運用と保守、テスト展開は困難であり、DevOpsのアイデアに準拠していません

2、マイクロサービス

上記のSOA、英語の翻訳はサービス指向です。サービスのように見えるマイクロサービスは、すべてシステムを分割しています。したがって、この2つは非常に混同しやすいですが、実際にはいくつかの違いがあります。

1.マイクロサービスの特徴

• 単一の責任：マイクロサービスの各サービスは固有のビジネス機能に対応し、単一の責任を達成します
• マイクロ：マイクロサービスのサービス分割の粒度は非常に小さく、たとえば、ユーザー管理をサービスとして使用できます。各サービスは小規模ですが、「すべての内臓を完備」しています。
• サービス指向：サービス指向とは、各サービスがサービスインターフェイスAPIを公開する必要があることを意味します。サービスの技術的な実装については気にせず、プラットフォームや言語とは関係がなく、Restのインターフェイスが提供されている限り、使用するテクノロジーを制限することはありません。
• 自律性：自律性とは、サービスが互いに独立していて、互いに干渉しないことを意味します
  • チームの独立性：各サービスは独立した開発チームであり、人数が多すぎることはありません。
  • テクノロジーの独立性：サービス指向であり、Restインターフェイスを提供するため、他の人が使用されているテクノロジーに干渉することはありません。
  • フロントエンドとバックエンドの分離：フロントエンドとバックエンドの開発を使用して、統一されたRestインターフェイスを提供します。バックエンドは、PCセグメントとモバイルセグメントに異なるインターフェイスを開発する必要はありません。
  • データベースの分離：各サービスは独自のデータソースを使用します
  • 展開は独立しています。サービス間に呼び出しがありますが、サービスの再起動は他のサービスに影響を与えません。継続的な統合と継続的な配信に役立ちます。各サービスは独立したコンポーネントであり、再利用可能、交換可能、結合を減らし、保守が容易です

マイクロサービス構造図：

2.マイクロサービスの設計原則

3.高い凝集力と低い結合

• 密接に関連するものをまとめる必要があります。各サービスは、1つのことをうまく行うことに焦点を当てた単一の責任のビジネス能力のカプセル化です（一度に変更する理由は1つだけです）。次の図に示すように、4つのサービスa、b、c、およびdがありますが、各サービスには異なる責任があります。Aはbを実行し、bはcを実行し、cは同時にaを実行します。調整後、関連するものを組み合わせると、不要なサービスを減らすことができます。
• 軽量通信方式
  • httpに基づく同期RESTful（GET / PUT / POST ...）は、サービス間の通信を標準化およびステートレスにすることができます。RESTfulAPIの成熟度については、を参照してください。Richardson为REST定义的成熟度模型
  • 非同期（メッセージキュー/公開およびサブスクライブ）
• サービス間でデータベースを共有しないでください

4.高度な自律性

• 独立した展開、運用、拡張
  • 各サービスは個別に展開して、プロセスで実行できます
  • この操作モードと展開モードにより、システムに柔軟なコード編成とリリースリズムを与えることができ、変更を迅速に提供して対応することができます。
• 独立した開発と進化
  • テクノロジーの選択は柔軟であり、レガシーシステムテクノロジースタックによって制限されません。
  • 適切なビジネス問題は、独立して進化できる適切なテクノロジースタックを選択できます
  • サービス間の統合に言語に依存しないAPIを使用する
• 独立したチームと自律性
  • チームは、サービスのライフサイクル全体を担当し、独立したコンテキストで作業し、サービスを開発し、維持します。

5.ビジネスに焦点を合わせる

• 各サービスは特定のビジネスロジックを表します
• 明確な境界コンテキスト
• ビジネスを中心にチームを編成する
• ビジネスの変化に迅速に対応できます
• 事業領域を再利用できるように、実装の詳細を分離します

柔軟なデザイン

• フォールトトレラントシステムを設計する
  • 失敗を受け入れ、既知のエラーの設計
  • 依存サービスがハングする
  • ネットワーク接続の問題
• 自己保護機能を備えたシステムを設計する
  • サービスの分離
  • サービスの低下
  • リソースの使用を制限する
  • カスケードエラーを防ぐ

6、Netfilix

Netfilixは、より優れたソリューションを提供します。具体的な対策には、ネットワークタイムアウト/要求数の制限/ブレーカーモード/ロールバックの提供などがあります。

Hystrixは、事前設定された制限を超える通話を記録します。回路遮断モードを実装しているため、応答のないサービスを際限なく待つ必要がありません。サービスのエラー率が事前設定値を超えると、Hystrixはサービスを中断し、サービスに対するすべての要求は一定期間内に直ちに無効になります。Hystrixは、キャッシュの読み取りやデフォルト値への復帰など、要求の失敗に対するフォールバック操作を定義できます。

7.ログと監視

製品環境に問題が発生した場合、問題を迅速に特定し、起こりうる事故や故障を検出する必要があります。ロギングとモニタリングは、迅速な位置決めと防止に最適であり、マイクロサービスアーキテクチャではさらに重要です。

• 非常に観察しやすいので、何が起こっているのかを全体的に把握する必要があります。
• ログを集約し、データを集約して、問題が発生したときに理由を詳細に分析できるようにします。
• 厄介な問題を再現する必要がある場合、またはシステムが実稼働環境でどのように相互作用するかを確認するだけの关联标识場合は、システム間の呼び出しを追跡するのに役立ちます。

監視には、主にサービスの可用性ステータス、リクエストフロー、コールチェーン、エラーカウント、構造化ログ、サービス依存関係の視覚化などが含まれるため、問題を時間内に修正したり、システム負荷をリアルタイムで調整したり、サービスの低下、過負荷保護などを必要に応じて行うことができます。システムと環境が効率的で高品質のサービスを提供できるようにします。

たとえば、商用ソリューションsplunk，sumologicとオープンソース製品のELKは、ログの収集、集約、表示に使用でき、特定の条件に基づいて検索機能を提供し、電子メールの警告をトリガーします。

Spring boot adminまた、サービスの可用性を監視するために使用することもできます。 hystrixヒューズメカニズムを提供するだけでなく、要求に関する基本情報（要求の応答時間、アクセス計算、エラー統計など）を収集し、情報を視覚化するための既製のダッシュボードを提供します。

パフォーマンスの監視とコールチェーンのトレースに関しては、dynatraceとzipkin / Sleuthの使用を検討してください

8.自動化

マイクロサービスアーキテクチャでは、次の課題に直面しています。

• 分散システム
• マルチサービス、マルチインスタンス
• 手動のテスト、展開、リリースには時間がかかりすぎる
• フィードバックサイクルが長すぎる

従来の手動操作やメンテナンス方法は必然的に排除されます。マイクロサービスの実装には、自動化という特定の前提条件があります。サービスが大規模になる自动化と、标准化効率を向上させ、コストを削減するために、ますます多くの方法が必要になります。

• 単一のブロックシステムと比較して、多数のサービスが適切に機能していることを確認するのはより複雑なプロセスであるため、自動テストは不可欠です。
• 統合されたコマンドラインを呼び出して、同じ方法でシステムを各環境に展開します。
• 異なる環境間の違いを明確にするために環境定義を使用することを検討してください。同時に、均一な方法で展開する機能を維持してください。
• カスタムイメージを作成して展開を高速化し、不変サーバーの完全自動作成の実践を採用することを検討してください。

自动化一切可以自动化的、次のような展開とリリースの難しさを軽減するために：継続的な統合と継続的な配信、自動コンパイル、テスト、セキュリティスキャン、パッケージング、統合テスト、展開、ますます多くのサービスとして、リリースプロセスでは、さらなる自動化の必要性グリーン展開（古いバージョンから新しいバージョンへのスムーズな移行を実現するため）では、パイプラインのプラクティスをコードとして使用し、コードを使用してパイプラインを記述することもできます。展開には多くのオプションがあり、仮想マシン、コンテナドッカー、または一般的なサーバーレスアーキテクチャラムダを使用できます（AWS Lambdaにも明らかな制限がいくつかあります。長時間実行されるサービスの展開には適していません。要求は、300秒以内に完了する必要があります。 、もちろん、ハッキングすることで時間を遅らせることができます）。

次に、Amazonのようなインフラストラクチャとコードプラクティスcloudformationをterrform使用し、コードを使用して、新しいサービスを迅速に提供し、必要な環境を構築し、それぞれを維持できるコンピューティングやネットワークなどのインフラストラクチャを記述できます环境的一致性。

9.マイクロサービスの利点は何ですか？

1.各マイクロサービスは非常に小さいため、特定のビジネス機能またはビジネス要件に焦点を当てることができます。マイクロサービスアーキテクチャパターンは、単一のコーディング方法を使用して実装するのが難しい機能にモジュラーソリューションを提供します。その結果、単一のサービスの開発、理解、および保守が容易になります。

2.マイクロサービスは、2〜5人の開発者で構成される小さなチームによって独立して開発できます。

3.マイクロサービスは疎結合であり、開発フェーズまたは展開フェーズのいずれかで独立している機能的に意味のあるサービスであり、展開をスピードアップできます。UIチームは、ABテストを使用して、変更をすばやく展開できます。マイクロサービスアーキテクチャモデルにより、継続的な展開が可能になります

4.マイクロサービスはさまざまな言語で開発できます。

5.マイクロサービスは、開発者が理解、変更、および保守しやすいため、小規模なチームは作業結果により多くの注意を払うことができます。価値を実現するために協力する必要はありません。

6.マイクロサービスを使用すると、最新のテクノロジーを利用できます。

7.マイクロサービスは単なるビジネスロジックコードであり、HTML、CSS、またはその他のインターフェイスコンポーネントと混合されることはありません。

10.マイクロサービスアーキテクチャのデメリットは？

1.マイクロサービスアーキテクチャは、操作が多すぎる可能性があります（サービス分割）

2.DevOpsスキルが必要です。

3.おそらく2倍の労力。

4.分散システムは複雑で、管理が難しい場合があります。開発者は、RPCまたはメッセージングのいずれかを選択し、プロセス間通信メカニズムを完了する必要があります。さらに、メッセージ配信の遅延や使用不可などのローカル障害に対処するためのコードを作成する必要があります。もちろん、これは難しい作業ではありませんが、言語レベルのメソッドまたはプロセス呼び出しによるモノリシックアプリケーションと比較すると、マイクロサービスでのこのテクノロジはより複雑です。

5.分散展開のため、追跡が困難です。

6.サービスの数が増えると、管理の複雑さが増します

7.パーティション化されたデータベースアーキテクチャ。商取引において、ニュースを複数のビジネスサブサブジェクトに同時に更新することは非常に一般的です。この種のトランザクションは、データベースが1つしかないため、モノリシックアプリケーションでは簡単です。マイクロサービスアーキテクチャアプリケーションでは、さまざまなサービスで使用されるさまざまなデータベースを更新する必要があります。CAP理論のためだけでなく、今日の高度にスケーラブルなNoSQLデータベースとメッセージングミドルウェアがこの要求をサポートしていないため、分散トランザクションの使用は必ずしも良い選択ではありません。最終的には、最終的に一貫性のある方法を使用する必要があり、開発者にとってより高い要件と課題が発生します。

3、RPCを知っている

RPC、つまりリモートプロシージャコール（リモートプロシージャコール）は、コンピュータ通信プロトコルです。このプロトコルにより、あるコンピューターで実行されているプログラムは、プログラマーがこの対話をプログラムする必要なしに、別のコンピューターのサブルーチンを呼び出すことができます。簡単に言うと、コンピュータAがサービスを提供し、コンピュータBはローカルサービスを呼び出すのと同じようにコンピュータAのサービスを呼び出すことができます。

上記の概念から、RPCの実現は主に2つのことを行うことがわかります。

• 他のコンピュータをリモートで呼び出すサービスを実現します
  • リモートコールを実現するには、データをネットワーク経由で送信する必要があります。プログラムAはサービスを提供し、プログラムBはネットワークを介してプログラムAに要求パラメーターを渡し、Aはローカル実行後に結果を取得し、その結果をプログラムBに返します。ここで気になる点が2つあります。
    • 1）どのネットワーク通信プロトコルが使用されていますか？
      • より一般的なRPCフレームワークは、基盤となる伝送プロトコルとしてTCPを使用するようになりました
    • 2）データ送信の形式は何ですか？
      • 2つのプログラムが通信するには、データ送信形式について合意する必要があります。2人がチャットしているようなもので、同じ言語を使用する必要があります。そうしないと、通信できません。したがって、要求と応答の形式を定義する必要があります。さらに、ネットワーク送信中にデータをシリアル化する必要があるため、統一されたシリアル化方法について合意する必要があります。
• ローカルサービスのようなリモートサービスを呼び出す 
  • リモートコールのみの場合、RPCはプロシージャコールを強調するため、RPCとは見なされません。コールのプロセスはユーザーに対して透過的である必要があります。ユーザーはコールの詳細を気にする必要はなく、ローカルサービスのようにリモートサービスを呼び出すことができます。したがって、RPCは呼び出しプロセスをカプセル化する必要があります。

RPCコールフローチャート：

 

前：[Spring Cloud4]高性能の大規模分散Webサイトの構築

次の記事：  SpringCloud学習の概要