4つの主流ソフトウェアアーキテクチャについて語る: サーバーレス、マイクロサービス、分散、モノリシック

ソフトウェア開発者がソフトウェアアーキテクチャの進化を理解していない場合、技術の選択と開発者の生存および昇進の余地が制限されます。ここでは、ソフトウェア開発者の知識を広げるために、4 つの主要なソフトウェア アーキテクチャとその長所と短所をリストします。

1. モノリシックアーキテクチャ

モノリシック アーキテクチャは比較的基本的なもので、典型的な 3 レベル アーキテクチャは、フロントエンド (Web/モバイル) + 中間ビジネス ロジック層 + データベース層です。これは、Java Spring MVC または Python Drango フレームワークの典型的なアプリケーションです。アーキテクチャ図は次のとおりです。

モノリシックアーキテクチャ

モノリシック アプリケーションは、展開とテストが簡単です。プロジェクトの初期段階では、モノリシック アプリケーションは問題なく動作します。しかし、需要が増加し続け、開発チームに加わる人が増えるにつれて、コードベースは急速に拡大しました。徐々に、モノリシック アプリケーションは肥大化し、保守性と柔軟性が徐々に低下し、保守コストがどんどん高くなります。モノリシック アプリケーションの欠点は次のとおりです。

• 複雑性が高い: 数百万行のコードを持つ単一のアプリケーションを例にとると、プロジェクト全体に多数のモジュールが含まれており、モジュールの境界はあいまいで、依存関係は不明瞭で、コードの品質は不均一で、無秩序に積み重なっています。ご想像のとおり、プロジェクト全体は非常に複雑です。コードを修正するたびに恐怖を感じます。単純な機能を追加したり、バグを修正したりするだけでも、隠れた欠陥が生まれます。
• 技術的負債: 時間が経つにつれて、要件が変化し、人員が変わると、アプリケーションの技術的負債が徐々に形成され、蓄積されます。 「壊れていないものは修理しない」というのはソフトウェア開発では非常に一般的な考え方ですが、モノリシック アプリケーションではさらに一般的です。アプリケーション内の他のモジュールが予期しない方法で使用する可能性があるため、使用されるシステム設計またはコードを変更することは困難です。
• デプロイ頻度が低い: コードの量が増えると、ビルドとデプロイにかかる時間も長くなります。モノリシック アプリケーションでは、機能の変更や欠陥の修正ごとに、アプリケーション全体を再デプロイする必要があります。完全な展開方法は時間がかかり、影響範囲が広く、リスクが高いため、単一のアプリケーション プロジェクトのオンライン展開の頻度が低くなります。デプロイメント頻度が低いと、リリース間で多数の機能変更とバグ修正が発生し、エラー率が比較的高くなります。
• 信頼性が低い: 無限ループやメモリ オーバーフローなどのアプリケーション バグにより、アプリケーション全体がクラッシュする可能性があります。
• スケーラビリティの制限: モノリシック アプリケーションは全体としてのみ拡張でき、ビジネス モジュールのニーズに応じて拡張することはできません。たとえば、アプリケーション内の一部のモジュールは計算負荷が高く、強力な CPU を必要とします。一部のモジュールは IO を集中的に使用するため、より大きなメモリを必要とします。これらのモジュールは一緒に展開されるため、ハードウェアの選択において妥協が必要になります。
• 技術革新の妨げ: モノリシック アプリケーションでは、多くの場合、すべての問題を解決するために統合されたテクノロジ プラットフォームまたはソリューションが使用されます。チームのメンバー全員が同じ開発言語とフレームワークを使用する必要があるため、新しいフレームワークや新しいテクノロジー プラットフォームを導入することが非常に困難になります。

2. 分散アプリケーション

中間アーキテクチャ、分散アプリケーション、中間層分散 + データベース分散は、モノリシック アーキテクチャの同時拡張です。大規模なシステムを複数のビジネス モジュールに分割します。ビジネス モジュールは異なるサーバーに展開され、ビジネス モジュールはインターフェイスを通じて相互に対話します。データベースでは、Redis、ES、Solor などの分散データベースも広く使用されています。LVS/Nginx プロキシ アプリケーションを通じて、ユーザー リクエストはさまざまなサーバーに分散されます。アーキテクチャ図は次のとおりです。

分散アーキテクチャ

モノリシック アーキテクチャと比較して、このアーキテクチャは負荷分散機能を提供し、システムの負荷容量を大幅に向上させ、Web サイトの高い同時実行要件を解決します。その他の機能は次のとおりです:

• 結合の削減: モジュールを分割し、インターフェース通信を使用して、モジュール間の結合を削減します。
• 責任を明確にする: プロジェクトを複数のサブプロジェクトに分割し、異なるチームが異なるサブプロジェクトを担当するようにします。
• 拡張が簡単: 機能を追加する場合は、サブプロジェクトを追加し、他のシステムのインターフェースを呼び出すだけです。
• 簡単に導入可能: 分散導入を柔軟に実行できます。
• コードの再利用性の向上: たとえば、サービス層が分散 REST サービス アーキテクチャを採用していない場合、モバイル WAP モール、WeChat モール、PC、Android、iOS の各エンドにサービス層ロジックを記述する必要があります。開発量が多く、保守・バージョンアップを一括して行うことが困難です。このとき、サービス層を共有する分散レストサービス方式を採用することができます。
• デメリット: システム間のやり取りにはリモート通信が必要であり、インターフェース開発によって作業負荷が増加しますが、メリットがデメリットを上回ります。

3. マイクロサービスアーキテクチャ

マイクロサービス アーキテクチャは主に中間層を分解し、システムを多数の小さなアプリケーション (マイクロサービス) に分割します。マイクロサービスは、異なるサーバーにデプロイすることも、同じサーバー上の異なるコンテナにデプロイすることもできます。アプリケーションの障害が他のアプリケーションに影響を与えず、単一アプリケーションの負荷が他のアプリケーションに影響を与えない場合、代表的なフレームワークとしては、Spring cloud、Dubbo などがあります。そのアーキテクチャ図は以下のとおりです。

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

• 開発と保守が簡単: マイクロサービスは特定のビジネス機能にのみ焦点を当てているため、ビジネスが明確でコードが少なくなります。単一のマイクロサービスの開発と保守は比較的簡単です。アプリケーション全体は複数のマイクロサービスから構築されるため、アプリケーション全体が制御可能な状態に維持されます。
• 単一のマイクロサービスは起動が速い: 単一のマイクロサービスはコードが少ないため、起動が速くなります。
• ローカルの変更により、展開が容易になります。モノリシック アプリケーションが変更された場合、アプリケーション全体を再展開する必要があります。マイクロサービスがこの問題を解決します。一般的に、マイクロサービスを変更するには、サービスを再デプロイするだけで済みます。
• テクノロジー スタックに制限はありません。マイクロサービス アーキテクチャでは、プロジェクトのビジネスとチームの特性に基づいてテクノロジー スタックを合理的に選択できます。たとえば、一部のサービスではリレーショナル データベース MySQL を使用できます。一部のマイクロサービスにはグラフィックコンピューティングの要件があり、Neo4j を使用できます。必要に応じて、一部のマイクロサービスは Java で開発することも、一部は Node.js で開発することもできます。
• マイクロサービスには多くの魅力的な機能がありますが、無料で手に入るわけではなく、使用するにはそれなりの代償を払う必要があります。マイクロサービス アーキテクチャを使用する際の課題。
• O&M 要件の高まり: サービスが増えると、O&M 投資も増えます。モノリシック アーキテクチャでは、1 つのアプリケーションの正常な動作を保証するだけで済みます。マイクロサービスでは、数十、数百ものサービスの正常な動作と連携を確保する必要があり、運用と保守に大きな課題が生じます。
• 分散の固有の複雑さ: マイクロサービスを使用して構築されたシステムは分散システムです。分散システムの場合、システムのフォールト トレランス、ネットワークの遅延、分散トランザクションなどはすべて大きな課題となります。
• インターフェース調整コストが高い: マイクロサービスはインターフェースを介して相互に通信します。マイクロサービスの API を変更する場合、このインターフェースを使用するすべてのマイクロサービスを調整する必要がある可能性があります。
• 作業の重複: 多くのサービスが同じ機能を使用している場合がありますが、この機能はまだマイクロサービスに分解されるレベルに達していません。現時点では、各サービスがこの機能を開発し、コードが重複する可能性があります。共有ライブラリを使用してこの問題を解決することはできますが (たとえば、関数を共通コンポーネントにカプセル化し、関数を必要とするマイクロサービスがそのコンポーネントを参照する)、共有ライブラリは多言語環境では機能しない可能性があります。

4. サーバーレスアーキテクチャ

私たちがコンテナの波の中で前進を続ける一方で、革命的な先駆者たちは、サーバーレス アーキテクチャという別のクラウド コンピューティングの戦場をひっそりと開拓してきました。

サーバーレスアーキテクチャ

2014 年 11 月 14 日、Amazon AWS は新しい製品 Lambda をリリースしました。当時、Lambda は、基盤となるコンピューティング リソースを気にすることなく、時間に応じてユーザー コードを実行するコンピューティング サービスと説明されていました。ある意味、Lambda は遅れて参加したと言えます。これはクラウド コンピューティングの PaaS コンセプトに似ています。顧客はビジネスに集中するだけでよく、ストレージやコンピューティング リソースについて心配する必要はありません。

その少し前の2014年10月22日、GoogleはリアルタイムバックエンドデータベースのスタートアップであるFirebaseを買収しました。 Firebase は、開発者が標準 REST API のさまざまなインターフェースを使用してデータを読み書きするには、API ライブラリ ファイルを参照するだけでよいと主張しています。 HTML + CSS + JavaScript のフロントエンド コードのみを記述すればよく、サーバー側のコードは必要ありません (統合が必要な場合でも、非常に簡単です)。

上記2社と比較すると、2014年2月にFacebookに買収されたParseは、一般的なバックエンドサービスの提供に重点を置いています。これらのサービスは、サーバーレスまたはサーバーなしと呼ばれます。 PaaS（Platform as a Service）をお考えですか？とても似ていますね。ユーザーはインフラストラクチャについて心配する必要はなく、ビジネスについてのみ注意する必要があります。これは後発の PaaS ですが、より実用的な PaaS でもあります。これにより、開発プロセス全体と従来のアプリケーション ライフサイクルに革命が起こる可能性があります。開発者がクラウド リソースの完全に自動化された作成と割り当てに慣れると、マイクロ アプリケーションでリソースを構成する必要があった時代に戻ることはできなくなるかもしれません。

サーバーレス アーキテクチャにより、開発者はコンピューティング リソースの取得とメンテナンスを気にすることなくアプリケーションを構築できます。このプラットフォームは、オンデマンドでコンピューティング リソースを割り当て、アプリケーション実行の SLA (サービス レベル契約) を保証します。課金は通話回数に基づいて行われるため、アプリケーション コストを効果的に節約できます。 ServerLess のアーキテクチャを上の図に示します。利点は次のとおりです。

• 低い運用コスト: ビジネス上の緊急事態が非常に多いシナリオでは、ビジネスのピークに対応するために、ピーク需要に対応できるシステムを構築する必要があります。このシステムはほとんどの時間アイドル状態であり、リソースの重大な浪費とコストの上昇につながります。マイクロサービス アーキテクチャでは、サービスを常に実行する必要があります。実際、高可用性を実現するために、各サービスには高負荷条件下で複数のインスタンスが存在します。サーバーレス アーキテクチャでは、ユーザーの呼び出し回数に基づいてサービスが課金されます。クラウド コンピューティングの従量課金制の原則によれば、何も実行されていない場合は料金を支払う必要がなく、使用コストを節約できます。同時に、ユーザーはネットワーク、ハードディスク、CPU などのコンピューティング リソースを共有し、ビジネス ピーク時には弾力的な拡張によってビジネス ピークに効果的に対応し、ビジネス ボトム時には他のユーザーとリソースを共有して、コストを効果的に節約できます。
• 機器の運用と保守を簡素化: 元の IT システムでは、開発チームはアプリケーションとハードウェア インフラストラクチャの両方を保守する必要があります。サーバーレス アーキテクチャでは、開発者はサードパーティが開発またはカスタマイズした API と URL に直面することになります。基盤となるハードウェアは開発者にとって透過的であり、技術チームは運用や保守作業に注意を払う必要がなくなり、アプリケーション システムの開発に集中できるようになります。
• 保守性の向上: サーバーレス アーキテクチャでは、アプリケーションは複数のサードパーティ機能サービスを呼び出して、最終的なアプリケーション ロジックを形成します。現在、ログイン認証サービスやクラウドデータベースサービスなどのサードパーティサービスは、セキュリティ、可用性、パフォーマンスの面で大幅に最適化されています。開発チームはサードパーティのサービスを直接統合して開発コストを効果的に削減できると同時に、アプリケーションの運用および保守プロセスを明確にし、アプリケーションの保守性を効果的に向上させることができます。
• 開発スピードの高速化: これは現在のインターネット スタートアップによく反映されています。スタートアップ企業は、人員や資金の問題により、すべての製品ラインを同時に開発できないことがよくあります。このとき、WeChatユーザー認証、Alibaba Cloudが提供するRDS、Jiguangメッセージプッシュ、サードパーティの支払いと地理的位置などのサードパーティBaasプラットフォームを検討することができ、これにより製品を迅速に開発し、ビジネスの実現に集中し、製品をより早く市場に投入することができます。

しかし、ServerLess アーキテクチャには欠点もあります。

• メーカー プラットフォーム バインディング: このプラットフォームは、AWS Lambda などの大手企業にサーバーレス アーキテクチャを提供します。実行するには、API Gateway、DynamoDB、S3 など AWS 指定のサービスを使用する必要があります。これらのサービス上で複雑なシステムを開発すると、AWS に縛られてしまい、価格を値上げするか、棚から撤去するかせざるを得なくなります。個別のニーズを満たすことが難しく、自由に移行できないか、移行コストが比較的高いため、必然的に何らかの損失が発生します。 Baas 業界の典型的な出来事としては、2016 年 1 月 19 日に Facebook が巨額の費用をかけて買収した Parse を閉鎖したことが挙げられます。これにより、ユーザーはこのプラットフォームで生成されたデータを 1 年以上にわたって移行する必要があり、間違いなく比較的大きな人的コストと時間が必要になりました。
• 成功事例が比較的少なく、業界標準がない: 現状は単純なアプリケーション開発にしか適しておらず、大規模な成功事例の推進が不足しています。サーバーレスについては統一された理解と対応する標準が欠如しており、すべてのクラウド プラットフォームに適応することはできません。

現在、4つのアーキテクチャの中ではマイクロサービスアーキテクチャが主流となっており、第1および第2のアーキテクチャを採用している多くの企業も徐々にマイクロサービスアーキテクチャへと移行しつつあります。今のところ、マイクロサービスの技術は2、3年前に比べて比較的成熟しており、第4のアーキテクチャは今後の発展のトレンドとなるでしょう。私の記事が気に入ったら、私の Jianshu をフォローしてください。後ほど、Spring Cloud と Docker を使用してマイクロサービスを簡単に楽しく構築する方法を説明します。