建築様式の選択 (パート 2)

こんにちは、ハブル。 現在、私はコースの新しい流れの開始のために特別に書いた一連の出版物を続けています。 「ソフトウェアアーキテクト」.

導入

アーキテクチャ スタイルの選択は、情報システムを構築する際の基本的な技術的決定の XNUMX つです。 この一連の記事では、建築用途で最も一般的な建築スタイルを分析し、どのような建築スタイルが最も好ましいかという質問に答えることを提案します。 プレゼンテーションの過程で、モノリスからマイクロサービスに至るアーキテクチャ スタイルの発展を説明する論理的な連鎖を描こうとします。

В 前回 私たちはモノリスを検討し、モノリスにはサイズ、接続性、導入、拡張性、信頼性、剛性などの多くの問題があるという結論に達しました。

今回は、システムをモジュール/ライブラリ (コンポーネント指向アーキテクチャ) またはサービス (サービス指向アーキテクチャ) のセットとして編成する可能性について話すことを提案します。

コンポーネント指向のアーキテクチャ

コンポーネント指向アーキテクチャには、現在および将来のプロジェクトの両方で使用できるコンポーネントのセットとしてシステムを実行することが含まれます。 システムをコンポーネントに分割するときは、コンポーネントの再利用性、置換可能性、コンテキストの独立性、拡張性、カプセル化と独立性が考慮されます。

コンポーネントを適切に使用すると、「大きなゴミ」(サイズが大きい + 結合度が高い) の問題は解決され、コンポーネント自体がアセンブリ単位 (モジュール、ライブラリ) と展開単位 (サービス) の両方を表すことができます。 デプロイメント ユニットは、常に実行中のプロセスにマップされるわけではありません。たとえば、Web アプリケーションとデータベースは一緒にデプロイされます。

ほとんどの場合、モノリスはモジュールのセットとして開発されます。 このアプローチは独立した開発につながりますが、独立したスケーリングと展開、耐障害性、およびテクノロジー スタック全体からの独立性の問題が残ります。 そのため、モジュールは部分的に独立したコンポーネントです。

このようなモノリスの最大の問題は、モジュールへの分割が純粋に論理的であり、開発者によって簡単に違反される可能性があることです。 コア モジュールが出現し、徐々にガベージ ダンプと化したり、モジュール間の依存関係のグラフが拡大したりする場合があります。 このような問題を回避するには、開発は非常に成熟したチームによって実行されるか、フルタイムでコードレビューに従事し、論理構造に違反する開発者の手を打ち負かす「アーキテクト」の指導の下で実行される必要があります。

「理想的な」モノリスは、論理的に分離された一連のモジュールであり、それぞれが独自のデータベースを調べます。

サービス指向アーキテクチャー

システムが一連のサービスの形で組織されると想定されている場合、これはサービス指向アーキテクチャについて話していることになります。 その原則は、ユーザー中心のアプリケーションの相互運用性、ビジネス サービスの再利用、テクノロジー スタックの独立性、および自律性 (独立した進化、拡張性、展開) です。

サービス指向アーキテクチャ (SOA = サービス指向アーキテクチャ) は、モノリスで特定されたすべての問題を解決します。変更が発生したときに影響を受けるのは XNUMX つのサービスだけであり、明確に定義された API がコンポーネントの適切なカプセル化をサポートします。

しかし、すべてがそれほどスムーズに進むわけではありません。SOA は新たな問題を引き起こします。 リモート呼び出しはローカル呼び出しよりも高価であり、コンポーネント間での責任の再配分も大幅に高価になっています。

ちなみに、独立した展開が可能であることは、このサービスの非常に重要な機能です。 サービスを一緒に展開する必要がある場合、または特定の順序で展開する必要がある場合、システムはサービス指向であるとは言えません。 この場合、彼らは分散モノリス (SOA の観点だけでなく、マイクロサービス アーキテクチャの観点からもアンチパターンと考えられます) について話しています。

サービス指向アーキテクチャは、アーキテクチャ コミュニティとベンダーによって十分にサポートされています。 これは、多くのコースや認定資格、よく開発されたパターンの存在を意味します。 後者には、たとえば、よく知られているエンタープライズ サービス バス (ESB = エンタープライズ サービス バス) が含まれます。 同時に、ESB はベンダーからのお荷物であり、必ずしも SOA で使用する必要はありません。

サービス指向アーキテクチャの人気は 2008 年頃にピークに達し、その後衰退し始めましたが、マイクロサービスの出現 (~2015 年) 以降はさらに劇的になりました。

まとめ

サービスとモジュールの形式で情報システムを編成する可能性について説明した後、最後にマイクロサービス アーキテクチャの原則に進み、次の部分ではマイクロサービス アーキテクチャとサービス指向アーキテクチャの違いに特に注意を払うことを提案します。

建築様式の選択 (パート 2)

出所: habr.com

コメントを追加します