『フェニックスアーキテクチャ』第1章 - サービスアーキテクチャの進化史

序文

最初は、ByteByteGo についていくつかの記事を書いたのと同じように、記事に記載されているすべての内容を理解することに決め、すべての文を理解しました。ただし、「フェニックスアーキテクチャ」では、これは少々手間がかかり、不要なため、実際には使用しないものもあるかもしれませんが、内容を十分に紹介するために、この記事ではそれらについても言及します。そのため、私自身の質問や知りたいことについては、今でも追加のメモを作成しています。
当初はブログ形式で記事をまとめようと考えていたのですが、途中でまとめるのが難しく、どの一文も必要な内容で、本当に辛口で収穫の多い本でした。

要約する

本来の分散時代：コンピュータの性能不足が深刻で、分散の予備的検討が行われる。

モノリシックシステム時代：小規模システムの場合は開発、テスト、展開が容易だが、大規模システムの場合、全体として階層化アーキテクチャの原則に従うため、最大の問題は切り離せないものであり、拡張が困難である、コードまた、コードを再利用して管理するためにモジュールと機能に従って分割され、Jar、War などの複数のメソッドを展開して負荷分散を通じて拡張要件を満たすことができます。その本当の問題は、第一に、エラーの拡大を阻止できないことです。コードのどこかにエラーがあると、プログラム全体に影響を与える可能性があります。第二に、動的更新には不便で、プログラムを停止して更新することは不可能です。 3つ目は、技術的な異質性を実現することが容易ではなく、同じ言語、さらには同じアーキテクチャを使用する必要があることです。マイクロサービスの代替を推進する根本的な理由はもう一つあります。それは、本来の「エラーを最小限に抑えること」から「エラーは避けられないこと」への考え方の変化であり、エラーを許容することがマイクロサービスの最大の利点です。

SOA 時代: サービス指向アーキテクチャとも呼ばれ、リモートサービス呼び出しの方法に基づいて、分散の包括的な調査を実施し、非常に明確な指針を提示し、分散環境の主な問題を首尾よく解決し、ソフトウェア開発も提案します。方法論。技術だけでなく、研究開発のプロセスにも注目しています。しかし、仕様が厳しすぎる、複雑すぎる、汎用性が低いという欠点があり、結局失敗しました。

マイクロサービスの時代: 単一のアプリケーションは、分散ガバナンス、異種テクノロジ、リモート呼び出し、誰もが開発するだけでなく、テスト、運用および保守など、データの分散化、強力なターミナルと弱いパイプライン、RESTful スタイルを使用した簡素化された通信メカニズム、耐障害性と進化、ソフトウェア開発をより自由にする自動化など。欠点は、統一された仕様と制約がないと、ソフトウェアアーキテクチャの設計の難易度が大幅に上がることです。

ポストマイクロサービス時代: マイクロサービス時代では、人々はソフトウェアコードレベルで分散問題を解決します。ポストマイクロサービス時代では、Kubernetes を使用することでハードウェアレベルで分散のきめ細かい管理機能を直接実装できるため、これまで問題となっていた技術的問題が解消されます。ビジネスとは何の関係もありません問題がソフトウェアレベルから取り除かれるため、ソフトウェア開発はビジネスのみに集中できます。

ノーサービス時代: ノーサービスのビジョンは、開発者が技術コンポーネント、導入方法、コンピューティング能力、運用とメンテナンスを考慮することなく、純粋にビジネスに集中するだけでよく、これらのすべてが完了したクラウドコンピューティングビジネスによって提供されるというものです。しかし、現在のテクノロジーはあまり成熟しておらず、複雑なビジネスロジックやサーバーのステータスへの依存などの問題にはまだ対応できません。

メインコンテンツ

サービスアーキテクチャの進化の歴史:

元の分散時代:
初期の頃、コンピュータのパフォーマンスは深刻に不十分でした。コンピュータのパフォーマンスと計算能力を向上させるために、リモートサービス (サービスディスカバリ) がどこにあるのか、いくつ (ロードバランス）、ネットワーク分割、タイムアウト、またはサービスエラー（ヒューズ、分離、ダウングレード）、メソッドパラメータを表現して結果を返す方法（シリアル化プロトコル）、情報を送信する方法（トランスポートプロトコル）、およびサービス権限を管理する方法（認証）、認可）、通信セキュリティを確保する方法（ネットワークセキュリティ層）、同じ結果を返すために異なるマシンのサービスを呼び出す方法（分散データの一貫性）など、将来的に非常に影響力のある多くの理論が提唱されています。
モノリシックシステムの時代:
Wikipedia の定義によると、「モノリスとは自己完結型を意味します。モノリシックアプリケーションとは、同じテクノロジープラットフォームのさまざまなコンポーネントで構成される単層ソフトウェアを指します。」
まず第一に、小規模な単一システムの利点は明白で、開発、テスト、展開が簡単であり、システム内の各関数、モジュール、メソッドの呼び出しプロセスがプロセス内呼び出しであり、プロセス間呼び出しがないためです。通信が発生し、すべてのモジュールとメソッドが呼び出されます。ネットワークの分割、オブジェクトのレプリケーション、パフォーマンスの損失を考慮する必要はありません。したがって、作業効率が非常に高いです。
単一のシステムがないということについては、ソフトウェアのパフォーマンス要件がスタンドアロンを超えており、ソフトウェア開発者の規模が明らかに「2 Pizza Team」（チームの規模を測る数量詞）を超えているためです。アマゾンの創設者が提案したもので、ピザ 2 枚で食べられるという意味です。満腹人数 (約 6 ～ 12 人) は議論の価値があります。
大規模なモノリシックシステムの場合、分割できず拡張が難しいため、ますます大規模なソフトウェアをサポートできないと言われます。この考えは実は偏っています。垂直方向の観点から見ると、階層化されたアーキテクチャに従います。受信した外部リクエストは、さまざまな形式のデータ構造で層間で送信され、最後のデータベースにアクセスした後、逆の順序で応答します。水平方向の観点から見ると、モノリシックアーキテクチャは、コードの再利用と管理を行うために、テクノロジ、機能、および責任の次元に応じてソフトウェアをさまざまなモジュールに分割することもサポートしています。モノリシックシステムとは、全体的なプログラムのパッケージ化形式が 1 つだけであることを意味するものではありません。複数の Jar、War、またはその他のモジュール形式で完全に構成できます。負荷分散の方法では、同じ単一システムの複数のコピーが同時にデプロイされ、トラフィック圧力を共有する効果が得られます。これも非常に一般的な拡張機能です。。実際の問題は次の点です。
1)モノマーがエラーの伝播をブロックするのは困難です。。分裂後は自主性や孤立性は得られない。コードのいずれかの部分に欠陥があると、特定が困難なグローバルな影響が生じ、メモリリーク、スレッド爆発、ブロッキング、無限ループなど、プログラム全体に影響を及ぼします。問題がポート番号やデータベース接続プールのリークなど、より高レベルのパブリックリソースにある場合でも、マシン全体の通常の動作や、クラスター内の他の単一コピーにさえ影響を及ぼします。
(上で述べたように、複数の Wars と Jar が水平に展開されている場合、1 つの Jar が壊れると、他の Jar も壊れますか? これはこれについての話ではなく、実際のモノマーの話です) 2)プログラムを動的に更新するのは不便です。分離することはできません (OSGi を使用できますが、非常に複雑です)。また、コードの特定の部分を個別に停止、更新、アップグレードすることも不可能であることを意味します。そのため保守性が悪く、グレースケール公開やA/Bテストがしにくい。
3)技術的な異質性という困難に直面している。分離の難しさは、通常、各モジュールのコードを同じプログラミング言語、または同じプログラミングフレームワークを使用して開発する必要があるという事実にもつながります (JNI では Java に C または C++ を混在させることができますが、これは通常最後の手段です)エレガントな選択ではありません）。
上記の問題は、モノリシックシステムをマイクロサービスに置き換える今日のトレンドの根本的な原因ではありません。著者は、最も重要な理由は次のとおりであると考えています。このアーキテクチャスタイルの根底にある概念は、システムのすべての部分、コードのすべての部分が、それらはすべて可能な限り信頼性が高く、欠陥がまったくないか、ほとんどないことで信頼性の高いシステムを構築できます。しかし、いくら戦術レベルが高くても、戦略レベルの不足を補うことは難しく、高品質に頼って高い信頼性を確保するという考え方は、小規模なソフトウェアではうまく機能しますが、規模が大きくなるほど、システム規模、信頼性の高いモノマーの供給システムはますます困難になっています。ソフトウェアアーキテクチャの進化と、信頼性の高いシステムを構築するという概念が「エラーを最小限に抑えること」から「エラーは避けられないこと」に直面することへの変化によってこそ、マイクロサービスアーキテクチャが挑戦し、徐々にモノリシックアーキテクチャに取って代わり始めます。何十年にもわたって運用されており、そこに自信があります。
システム規模が小さい場合にはメリットがありますが、システム規模が大きくなったり、プログラムの変更が必要になったりすると、導入コストや技術アップグレードのための移行コストが高額になります。プログラムが間違いを犯すことを許容し、分離性と自律性の能力を獲得し、技術的な異質性を達成するために、プログラムはパフォーマンスと計算能力の後に再び分散型を選択する理由になります。
SOA 時代:
中国語名はサービス指向アーキテクチャ (サービス指向アーキテクチャ) 大きな単一システムを分割するために、各サブシステムを独立して展開、実行、更新できる SOA の登場まで、開発者は多くの試みを行ってきました。 1)チムニーアーキテクチャ。
他の関連情報システムとの相互運用や調整がまったく行われない設計パターンを指します。企業と部門を例に挙げると、企業内にまったく対話しない部門が本当に存在するでしょうか? さらに、このような「独立分割」と「独立老死」のシステムは、企業が望むことのできないものであることは明らかである。
2) マイクロカーネルアーキテクチャ: チムニーアーキテクチャでは、ビジネス関係のないシステムでも、人員、組織、権限などのパブリックマスターデータを共有する必要がある場合があるため、これらのマスターデータを他のサブシステムと一緒に配置することもできます。各サブシステムによって使用される可能性がある使用されるパブリックサービス、データ、およびリソースは、すべてのビジネスシステムによって共通に依存されるコアとなるためにまとめられます。特定のビジネスシステムは、スケーラブルな、柔軟で自然に分離された機能、マイクロカーネルアーキテクチャ。

このパターンはデスクトップアプリケーションに適しており、Web アプリケーションでもよく使用されます。ただし、マイクロカーネルアーキテクチャにも制限と前提条件があり、システム内のプラグインモジュールがお互いを知らないことを前提としており、どのモジュールがシステムにインストールされるかは予測できません。そのため、これらのプラグインはアクセスできます。カーネル内の一部のパブリックリソースですが、直接対話することはありません。しかし、企業情報システムであれ、インターネットアプリケーションであれ、多くのシナリオではこの前提が当てはまらないため、独立したシステムを分割するだけでなく、分割されたサブシステム間でスムーズな通信を可能にする方法を見つける必要があります。コミュニケーションをとること。
3) イベント駆動型アーキテクチャ: サブシステムが相互に通信できるようにするための実現可能な解決策は、サブシステム間に一連のイベントキューパイプラインを確立することです。システムの外部からのメッセージはイベントの形式でパイプラインに送信され、各サブシステムは関心があり、処理する必要があるイベントメッセージをパイプラインから取得します。これに基づいて、各メッセージハンドラーは独立しており、高度に分離されていますが、イベントパイプラインを通じて他のハンドラーと対話できます。

その後、リモートサービスの呼び出しによりSOAPプロトコルが誕生し、これを基にソフトウェアも正式にSOA時代に突入しました。将来のマイクロサービス時代の問題に直面して、そのほとんどは分散サービスが最初に提案されたときに予見できた困難でもあり、SOA はより体系的かつ具体的な調査を実行しました。
「より具体的な」ということは、SOA の操作性が優れているにもかかわらず、サービスのカプセル化、自律性、疎結合、再利用性、構成可能性、ステートレス性などのソフトウェア設計の明確な指針があること、呼び出しのプロトコル、さまざまなサブシステム間の通信対話を実現するエンタープライズサービスバス (ESB) と呼ばれるメッセージパイプラインなど。互いに密接に連携できるこの一連の技術コンポーネントのサポートにより、技術的な実現可能性の観点からのみ判断した場合、SOA は分散環境における主要な技術的問題を首尾よく解決すると見なすことができます。
「より体系的」とは SOA の壮大な理想を指し、その最終目標はトップダウンの一連のソフトウェア開発方法論を要約することであり、企業が SOA の考え方に従うだけでソフトウェア開発プロセスをパッケージで解決できることを期待しています。さらに、SOA はテクノロジーだけでなく、研究開発プロセスに関わる要件、管理、プロセス、組織にも注意を払います。
しかし、仕様定義が厳密すぎると過度の複雑さが生じます。そして、SOAP に基づいて構築された ESB や BPM などの多くの上部構造は、この複雑さをさらに悪化させます。結局のところ、情報システムの開発は定型的な記事ではなく、過度に洗練されたプロセスや理論を制御するには、複雑な概念を理解する専門家も必要となります。複数の異種大規模システム間の複雑な統合と相互作用を実現できますが、広く適用可能なソフトウェアアーキテクチャスタイルとして推進することは困難です。それも結局うまくいきませんでした。
マイクロサービスの時代:
マイクロサービスは、複数の小規模なサービスを組み合わせて単一のアプリケーションを構築するためのアーキテクチャスタイルであり、特定の技術標準ではなくビジネス機能を中心に構築されています。各サービスは、異なるプログラミング言語、異なるデータストレージテクノロジを使用し、異なるプロセスで実行でき、通信と運用保守を実現するために、軽量な通信メカニズムと自動展開メカニズムを採用しています。次のような特徴があります。
1) ビジネス能力を中心に構築します。これは、コンウェイの法則の重要性も強調しています。組織がシステムを設計するとき、それは組織のコミュニケーション構造によって制限されるため、製品は組織のコミュニケーション構造の縮図である必要があります。2) 分散型ガバナンス、マイクロサービスはより技術的な異質性が本当に必要な場合、「非統合」を選択する権利があるべきであることが強調されます; 3) サービスを通じて独立した自律的なコンポーネントを実現します。「ライブラリ」ではなく「サービス」を介してコンポーネントを構築することを強調する理由は、サービスがアウトプロセスコンポーネントであるのに対し、クラスライブラリはコンパイル時にプログラムに静的にリンクされ、ローカル呼び出しを通じて機能を提供するためです。 4) 製品思考、これまでは単一のアーキテクチャの下では、プログラムの規模により、すべての担当者が完全な製品に注意を払うことは不可能であると判断され、詳細な分業が行われていました。開発、運用保守、サポートなどの組織メンバーは皆、自分の仕事だけに集中していますが、マイクロサービスでは開発チーム全員がプロダクト思考を持ち、全体のあらゆる側面に気を配ることが可能です。 5) データの分散化、マイクロサービスこのサービスは、データが分散化された方法で管理、更新、保守、保存されるべきであることを明確に提唱しています。単一のサービスでは、システムの各機能モジュールは通常同じデータベースを使用します。集中型ストレージは本質的に一貫性の問題を回避するのが容易ですが、同じデータエンティティの抽象形式は、異なるサービスの観点からは異なることがよくあります。例えば店内の書籍であれば、販売欄では価格、保管欄では在庫数量、商品陳列欄では書籍の紹介情報に注目する集中ストレージとして利用する場合、すべてのフィールドを変更し、同じエンティティにマップする必要があるため、異なるサービスが相互に影響を及ぼし、独立性を失う可能性があります。分散環境で一貫性の問題に対処するのは非常に困難ですが、従来のトランザクション処理を使用して一貫性を保証することは不可能なことがよくありますが、2 つの悪影響のうち小さい方であれば、必要なコストを支払う価値は依然としてあります。6) 強力な端末と弱いパイプ、弱いパイプは、SOAP と ESB に対するほぼ直接の名前です。一連の複雑な通信メカニズム、つまり通信パイプライン上に構築されたこれらの機能は、特定のシステムのサービスの特定の部分には必要かもしれませんが、他の多くのサービスにとっては負担となります。サービスに上記の追加の通信機能が必要な場合は、通信パイプライン上のパッケージではなく、サービス自体のエンドポイントで解決する必要があります。マイクロサービスは、古典的な UNIX フィルターに似たシンプルで直接的な通信方法を提唱しています。マイクロサービスでは、RESTful スタイルの通信がより適切な選択肢になります。7) フォールトトレラント設計では、依存するサービスが迅速なフォールト検出を実行できるための自動メカニズムが必要です。、エラーが持続する場合は隔離し、サービスが復元された場合は再接続する; 8) 進化的設計、フォールトトレラント設計はサービスが失敗することを認め、進化的設計はサービスが使用されずに破棄されることを認めます。適切に設計されたサービスは廃止できるべきであり、永遠に存続するとは期待できません。システム内に変えられない、かけがえのないサービスが存在する場合、それはそのサービスがいかに優れているか、重要であるかを意味するのではなく、むしろシステム設計の脆弱性の表れであり、マイクロサービスが追求する独立性と自律性にも反するこの脆弱性の顕在化; 9) インフラストラクチャの自動化、CI/CD の迅速な開発などのインフラストラクチャの自動化により、構築、リリース、運用保守作業の複雑さが大幅に軽減されます。マイクロサービスでは、単一のアーキテクチャに比べて運用・保守の対象が桁違いに増えるため、マイクロサービスを利用するチームはインフラの自動化への依存度が高まり、人間が数百、数千、さらには数万をサポートすることが困難になります。のサービスです。の迅速な開発により、構築、リリース、運用、保守作業の複雑さが大幅に軽減されます。マイクロサービスでは、単一のアーキテクチャに比べて運用・保守の対象が桁違いに増えるため、マイクロサービスを利用するチームはインフラの自動化への依存度が高まり、人間が数百、数千、さらには数万をサポートすることが困難になります。のサービスです。の迅速な開発により、構築、リリース、運用、保守作業の複雑さが大幅に軽減されます。マイクロサービスでは、単一のアーキテクチャに比べて運用・保守の対象が桁違いに増えるため、マイクロサービスを利用するチームはインフラの自動化への依存度が高まり、人間が数百、数千、さらには数万をサポートすることが困難になります。のサービスです。
上記のマイクロサービスの定義と特徴から、マイクロサービスは、SOA で破棄できるほとんどすべての制約や規制を放棄し、より自由なアーキテクチャスタイルを追求していることは明らかです。しかし、統一された仕様や制約がなければ、かつてSOAで解決されていた分散サービスの問題が突然再発してしまうのではないだろうか？実際、マイクロサービスにおけるこれらの問題に対する統一的な解決策はもはや存在しないでしょう。Java の範囲内で使用されるマイクロサービスのみを議論するとしても、サービス間のリモート呼び出しの問題だけが解決策の候補リストに含まれる可能性があります。 RMI (Sun/Oracle)、Thrift (Facebook)、Dubbo (Alibaba)、gRPC (Google) など。
マイクロサービスがもたらす自由は諸刃の剣である一方で、SOA によって定められた複雑な技術標準を遮断します。単純なサービスが分散化におけるすべての問題に同時に直面するとは限りません。 SOA の重い技術的負担を宝物袋のように持ち運ぶ必要はなく、どのような問題を解決する必要があるか、どのようなツールを導入するかにかかわらず、解決する必要があります。一方で、この自由度により、ソフトウェアアーキテクチャの設計の難易度は大幅に上昇しました。
ポストマイクロサービス時代:
マイクロサービスの時代では、人々はこれらの分散問題をハードウェアのインフラストラクチャレベルではなくソフトウェアのコードレベルで解決することを選択します。これは主に、ハードウェアで構成されるインフラストラクチャがソフトウェアで構成されるインフラストラクチャに追いつけないためです。アプリケーションサービスの柔軟性は無力です。ソフトウェアはキーボードコマンドだけで複数のサービスに分割でき、コピーして起動するだけでサービスのスケールや拡張ができるハードウェアは対応するアプリケーションサーバー、ロードバランサー、DNSサーバー、ネットワークを変更することはできないのではないかキーボードを入力してこれらの機能をリンクしますか? この問題を解決するのがコンテナです
が、初期のコンテナは、サービスの配布と展開を容易にするためのクイックスタートサービスの動作環境としてのみ使用できます。プログラム. この段階では、単一のアプリケーション用にパッケージ化されていますコンテナは、分散問題の解決には実際には関与しません. 本当の変化は、Kubernetes の開発の成功から来ています. 次の図は、Kubernetes の技術的ソリューション間の比較を示しています分散問題と従来のマイクロサービスソリューションを解決します。出発点が異なるため、問題解決の方法と効果は異なりますが、これは間違いなく、問題を解決するための新しくてより有望な方法を提供します。

仮想化されたハードウェアがソフトウェアの柔軟性に対応できるようになると、ビジネスに関係のない技術的な問題がソフトウェアレベルから取り除かれ、ハードウェアインフラストラクチャ内で静かに解決され、ソフトウェアはビジネスのみに集中できるようになります。分散アーキテクチャによって引き起こされるさまざまな問題に独立して対処するソフトウェアレベルから、アプリケーションコードとインフラストラクチャ、ソフトウェアとハードウェアの統合、アーキテクチャの問題に対処するための共同作業の時代に至るまで、メディアによって「クラウドネイティブ」と呼ばれることが多くなりました。かなり抽象的ですが、名前を宣伝するためのものです。
ただし、Kubernetes はまだすべての分散問題を完全に解決できていません。「不完全」とは、純粋な Kubernetes が機能の観点から以前の Spring Cloud ソリューションほど優れていないことを意味します。これは、一部の問題はアプリケーションシステムとインフラストラクチャのエッジにあり、インフラストラクチャレベルで微調整することが非常に困難であるためです。たとえば、マイクロサービス A は、マイクロサービス B の 2 つのサービス (B1 と B2 と呼ばれます) を呼び出します。この場合、B1 は正常に動作するが、B2 には連続 500 エラーが発生すると仮定し、雪崩効果を避けるために、特定のしきい値に達した後に B2 を融合する必要があります。インフラレベルでのみ対応すると、AからBへのネットワーク経路が切断されるとB1の通常の通話に影響が出るが、切断されなければB1のエラーの影響を受け続けるというジレンマが発生する。 B2.
Spring Cloudのようなアプリケーションコードで実装されるマイクロサービスでは、上記の問題への対応は難しくありませんが、論理的であればプログラムコードで解決するため、どのような機能を実現したいかは開発者の想像力によって制限されます。しかし、インフラストラクチャはコンテナ全体に対して管理され、粒度は比較的粗く、コンテナレベルまでしかないため、単一のリモートサービスを効果的に管理および制御することが困難になります。
このような問題を解決するために、KubernetesのPodに通信プロキシサーバーを注入し、静かに引き継ぐことを指す「Sidecar Proxy」（サイドカープロキシ）、現在では「サービスメッシュ」と呼ばれていますが導入されました。アプリケーションが認識することのない、アプリケーションのすべての外部通信。このエージェントは、通常のサービス間通信（データプレーン通信といいます）を実現するほか、コントローラからの指示を受けて（コントロールプレーン通信といいます）、コントロールプレーンの設定に従ってデータプレーン通信の内容を解析・処理します。サーキットブレーカー、認証、測定、モニタリング、ロードバランシングなどのさまざまな追加機能を実現します。これにより、アプリケーションレベルで新たな処理コードを追加する必要がなく、プログラムコードと同等のきめ細かな管理機能を実現します。
アプリケーションシステムと同じリソースコンテナ内で実行されるプロキシサービスをソフトウェアとみなすべきかインフラストラクチャとみなすべきかを概念的に判断することは困難ですが、アプリケーションに対して透過的であり、ソフトウェアコードを変更することなくサービスガバナンスを実現できれば十分です。「どの通信プロトコルを選択するか」、「トラフィックをスケジュールする方法」、「認証と認可を行う方法」などの技術的な問題をプログラムコードから分離し、今日の Spring Cloud ファミリバケットのほとんどのコンポーネントの機能を置き換えます。ビジネスを考える独自のロジックに基づいた、理想的なスマートターミナルソリューションです。
ノーサービスの時代:
ノーサービスの特に権威ある「公式」定義はまだありませんが、その概念は以前のアーキテクチャほど複雑ではありませんもともと、ノーサービスも「シンプル」を主な売りにしていますポイントは、バックエンド機能と機能という 2 つのコンテンツだけです。
バックエンド設備とは、ビジネスロジックの動作をサポートするために使用されるデータベース、メッセージキュー、ログ、ストレージなどを指しますが、ビジネス上の意味はありません。これらのバックエンド設備はすべてクラウド上で実行されます。サービスとして」。
関数とはビジネスロジックのコードを指します。ここでの関数の概念と粒度は、プログラムコーディングの観点から見ると関数に非常に近いです。違いは、どのサービスの関数もクラウド上で実行されず、考慮する必要がないことです。コンピューティング能力またはキャパシティプランニング、これを「サービスとしての機能」と呼びます。
サーバーレスのビジョンは、開発者が純粋にビジネスに集中するだけでよく、技術コンポーネントを考慮する必要がないことです。バックエンドの技術コンポーネントは既製であり、調達、著作権、モデルの選択などの手間をかけずに直接使用できます。導入方法を考慮する必要がない導入プロセスは完全にクラウド上でホストされ、作業はクラウドによって自動的に完了しますデータセンター全体とコンピューティング能力によってサポートされるコンピューティング能力を考慮する必要はありません電力は無制限と考えられ、運用保守を気にする必要がなく、システムの継続的かつ安定した稼働を維持するのがクラウドコンピューティングです。サービスプロバイダーの責任は開発者の責任ではなくなります。
サーバーレスアーキテクチャの長期的な見通しは良好に見えますが、著者はサーバーレスの短期的な発展についてはそれほど楽観的ではありません。複雑なビジネスロジックがあり、サーバーのステータスや応答速度に依存し、長いリンクを必要とするアプリケーションには適していません。これは、ノーサービスでは「無制限の計算能力」を前提としているため、消費する計算能力の規模を制御するために使用量に応じて課金する必要があるため、その機能がサーバー上に常にアクティブな状態で留まるわけではありません。、リクエストが到着したときにのみ実行を開始するため、関数がサーバーの状態に依存するのは不便であり、また関数のコールドスタート時間が発生し、応答パフォーマンスがあまり良くありません（現在、サービスのコールドスタートプロセスはおそらく数十から数百ミリ秒のレベルですが、Java の場合、このクラスはアプリケーションを低いパフォーマンスで起動し、場合によっては数秒に近いレベルになります)。

重要な文

アーキテクチャの進化の最も重要な原動力、あるいはこの「大から小へ」の変化の流れの最も根本的な原動力は、常に、あるサービスのスムーズな「死」と「再生」を促進することです。個々のサービスの生死の変化は、システム全体が確実に存続できるかどうかに関わる重要な要素です。
アーキテクチャは発明されるものではなく、継続的な進化の結果です。
ソフトウェアアーキテクチャの進化により、信頼性の高いシステムを構築するという概念が「できる限りエラーが少ないことを追求する」から「エラーは避けられない」という考え方に変わりました。これが、マイクロサービスアーキテクチャがモノリシックアーキテクチャに挑戦し、徐々に置き換える基礎となっています。。
Unix DCE によって提案された分散サービスの設計目的は、「開発者がサービスがリモートかローカルかを気にせず、透過的にサービスを呼び出したり、リソースにアクセスしたりできるようにする」です。
ビジネスとテクノロジーは完全に分離され、リモートとローカルは完全に透明であり、おそらく今が最高の時代です。

他の

ユニックスとは何ですか?
簡単に言えば、ほとんどのオペレーティングシステム (Windows などではありません) の創始者です。次は Zhihu からの回答です。

現在のシステム Windows、Mac OS、Linux およびさまざまなディストリビューションなど。ただし、Windows 3.1 以降のバージョンの Windows カーネルが nt カーネルであることを除き、他のすべてのシステムおよびバージョンは基本的に Unix に由来します。Windows には 1 と 2 だけがあり、最下層は Unix に関連しており、それ以降のバージョンはまったく関係ありません。このうちMac OSは、Unixとカーネギーメロン大学の教授が開発したカーネルを混ぜた混合カーネルです。Linux は完全に UNIX に似ています。

Unix というと、Mac OS、Linux、AIX、HP-UX、Solaris など、連想される言葉がたくさんありますが、どれも Unix に似たシステムです。

Unix 類似システム (英語: Unix-like、UN X またはnix と呼ばれることが多い) は、FreeBSD、OpenBSD、SUN の Solaris などのさまざまな Unix 派生システムと、Minix、Linux などの従来の Unix に類似したさまざまなシステムを指します。、QNXなど。それらの中にはフリーソフトウェアやプロプライエタリソフトウェアもありますが、それらはすべてオリジナルの UNIX の特性をかなりの程度継承しており、多くの類似点があり、すべて POSIX 仕様にある程度準拠しています。
UNIX の商標は国際オープン標準化機構が所有しており、単一の UNIX 仕様に準拠する UNIX システムのみが UNIX という名前を使用でき、それ以外の場合は UNIX ライク (UNIX ライク) としか呼ぶことができません。

より単純なグラフ:
階層化の意味には

、私たちが最もよく知っている階層化アーキテクチャ、MVC アーキテクチャ、モデル (Model) - ビュー (View) - コントローラー (Controller) が含まれますが、これらの層の意味は何でしょうか。レイヤードデザインの本質は複雑な問題を単純化することですが、Zhihu 氏の答えは次のとおりです。

高い凝集性: レイヤード設計によりシステム設計が簡素化され、さまざまなレイヤーが特定のモジュールに集中できるようになります。
低結合: 各レイヤーはインターフェイスまたは API を介して対話し、依存当事者は依存当事者の詳細を知る必要がありません。再
利用: コードまたは関数の再利用は階層化後に実現できます。
スケーラビリティ: 階層化されたアーキテクチャにより、コードのスケールアウトが容易になります。
JAR、WAR
Jar と War はファイル圧縮と考えることができますが、このパッケージ化は実際にはコードと依存するものを一緒に圧縮することを目的としています。
Jar パッケージは Java パッケージであり、War パッケージは JavaWeb パッケージとして理解できます。Jar パッケージは Java で書かれたプロジェクトによってのみパッケージ化され、その中にはコンパイルされたクラスといくつかのデプロイメントファイルのみが含まれます。War パッケージには、記述されたコードからコンパイルされたクラスファイル、依存パッケージ、構成ファイル、HTML、JSP などのすべての Web サイトページなど、すべてが含まれています。War パッケージは、プロジェクトのすべての項目が含まれる Web プロジェクトとして理解できます。
グレースケールリリース
グレースケールリリースは、一部のユーザーが製品機能 A の使用を継続し、一部のユーザーが製品機能 B の使用を開始できるリリース方法です。ユーザーが B に異議がない場合は、段階的に範囲を拡大し、すべてのユーザーを B に移行します。このアプローチにより、システム全体に影響を与えることなく、新しい機能や変更をテストおよび検証できます。
マルチスレッドと同時実行の違い
まず、スレッドはプロセスの実行単位であり、プロセス内のスケジューリングエンティティであり、プロセスはアプリケーションごとに分離環境を提供するようなものです。
並行性と並列性について、並行性は、タスクのスケジュール設定とリソース管理に重点を置いて、複数のタスクが同じ期間内で交互に実行され、コンピューティングリソースを共有することを意味します。並列性は、複数の処理ユニットまたはリソースを使用して複数のタスクが同時に実行されることを意味します。コンピューティングリソース、および独立して、タスクの分割と実行に注意を払います。
マルチスレッドの目的は一般に並列コンピューティングであり、オペレーティングシステムはこれらのスレッドを複数の CPU に割り当てて同時に実行できます。そうなると、シングルコア CPU では並列コンピューティングを実現できなくなります。
突然の質問ですが、なぜ高い同時実行性についてはよく聞かれるのに、高い並列性についてはよく聞かれないのですか?
高い同時実行性は、システムが同時に多数のリクエストを処理できることを意味し、高い並列性は、システムが同時に実行できるタスクの数を意味します。リクエストは完了するために複数のタスクを必要とする場合や、複数のリクエストが同じタスクを共有する場合があります。したがって、高い並列性は、高い同時実行性を実現するための手段にすぎません。
高い同時実行性はユーザーまたはクライアントに関する概念であり、高い並列性はサーバーまたはプロセッサに関する概念です。ユーザーやクライアントが気にするのは、システムがリクエストに迅速に応答できるかどうかであり、システムが内部でタスクをどのように割り当てて実行するかは気にしません。サーバーまたはプロセッサーが重視しているのは、複数のコアまたは複数のマシンを使用してタスクの実行速度を向上させる方法です。したがって、高い同時実行性はシステムの外部サービス品質をよりよく反映することができ、高い並列性はシステムの内部動作モードをよりよく反映することができます。