分散アーキテクチャの難しさ:
- 分散は複数のサービスに分割され、当初は 1 台のサーバーで直接実行されていたコードが N 台のサーバーで実行されるように分割され、異なるプログラミング言語も使用される場合があります。その結果、このビジネスのチェーンは大規模かつ「長く複雑」になっているため、分散利用を決定する前に、問題が発生した場合に迅速に解決できるように、通信ルールを決定し、監視の問題を検討する必要があります。
異種システムの標準的な問題
- 複雑なシステムは複雑な社会のようなものです。これは、秦の始皇帝が六国を統一した後に行使された「同じテキストの本、同じ軌道の車」のようなもので、ルールが異なる6か国がすべて同じ規範を使用するようになります。これにより、さまざまな場所間のコミュニケーションが軽減され、生活や仕事の効率が向上します。
- したがって、分散システムにおいても統一された仕様が必要となり、各システムはこの仕様に従うことになる。より協力し、生産性を向上させるため。
適切な構成管理は 3 つの層に分割する必要があります。最下層はオペレーティング システムに関連し、中間層はミドルウェアに関連し、最上層はビジネス アプリケーションに関連します。
したがって、最下位層とミドルウェア層はユーザーが柔軟に変更することはできず、ユーザーのみが選択することができます。たとえば、オペレーティング システムの関連構成は、人々がランダムに構成するのではなく、人々が選択できるテンプレートを形成する必要があります。構成システムが仕様を形成する場合にのみ、多くのシステムを保持することができます。
システムアーキテクチャにおけるサービスの依存関係の問題
- 分散アーキテクチャでは、サービスには依存関係が存在するため、サービス依存関係チェーン上のサービスがハングアップすると、ドミノ効果が発生する可能性があります。
- 非クリティカルなビジネスがクリティカルなビジネスに依存している場合、非クリティカルなビジネスがクリティカルなビジネスになってしまいます。
- マイクロサービスでは、サービスを分割するだけでなく、各サービスに対応するデータベースを分割することも必要です (サービスがデータベースを引きずって消滅するのを防ぐため)。
分散障害が発生する可能性が高くなります
- 分散システムには、多数のマシンとサービスが存在します。対照的に、故障の頻度は従来のモノマーよりも高くなります。
- 単一のシステム障害が大きな影響を与える
- 分散システム (分離とクラスタリングにより影響を軽減できる場合)
- 障害はひどくないが、復旧に時間がかかり、影響が大きい。
- したがって、分散システムは十分に監視される必要がありますが、すべての指標を監視する必要はありません。監視指標が多すぎるため、監視を行わないことになりますが、ログを確認する時間が増加します。
しかし、機械やサービスが急増するにつれて、人間の不完全さがボトルネックになります。なぜなら、人は複雑なものを細部まで管理することはできないからです。
人間を助けることができるのは機械の自動化だけです。つまり、人間がコードを管理し、コードが機械を制御し、人間は機械のことを気にしません。
マルチレイヤーアーキテクチャの運用と保守の複雑さはさらに大きくなります
通常、システムはベース層、プラットフォーム層、アプリケーション層、アクセス層の 4 つの層に分かれています。
- 基本層はマシン、ネットワーク、ストレージです
- プラットフォーム層はミドルウェア層であり、Tomcat、MySQL、Redis、Kafka などのソフトウェアです。
- アプリケーション層は当社のビジネス ソフトウェアまたはサービスです
- 参加層は、ユーザー要求、負荷分散または CDN、DNS などのゲートウェイです。
各層は全体的な問題につながります。
統一されたビューと管理がなければ、運用と保守が分離され、より複雑になります。トラブルシューティングを容易にするために、各層には統一されたロゴが必要であり、各層のリクエストがどの順序であるかをマークする必要が
あります。
分業は問題ではなく、分業後の連携が統一・標準化されているかが問題である