マイクロvsモノリシックサーバーアーキテクチャ

現在、新しい製品/プロジェクトに取り組んでいます。これは、特定の特定の産業/サービス企業向けのクライアント/サーバーアプリケーションです。Javaフロントエンドを備えたTCP上でカスタムプロトコルを実行するサーバー（C言語およびLinuxのみ）を構築しています。私たちはコーディング作業に約20％取り組んでおり、マイクロカーネルアーキテクチャまたはモノリシックカーネルアーキテクチャを選択する必要がある状況に直面しています。

Micro vs. Monolithicは通常カーネルアーキテクチャに関連していることは承知していますが、具体的にはサーバーについて話しています。

既存のサーバーではなく、カスタムサーバーが必要な理由

• UIのニーズは非常に大きく、非常に動的であるため、Web / Webブラウザーベースのソリューションは適切ではありませんでした。
• 統計処理はクライアント側で重要であるため、ブラウザーもほとんど役に立ちませんでした。（もちろん、サーバー側で処理を実行し、処理されたデータをクライアントに渡すこともできますが、これはサーバーの負荷が大きくなり、クライアントリソースが浪費されることを意味します）。
• さらに、少なくとも3つのテクノロジー（JS / HTML / CSS）で1つのイベントを管理することで、砂漠の嵐の中で家を一掃するような全体の体験ができます。

マイクロサーバーとモノリシックサーバーはどうですか？あなたは何をしゃべってますか？

次の（仮想の）クライアント要求を検討してください。

request-id: 123
request-service: HistoricDataSets
request-message: Fetch all records upto the year 2010

そのようなリクエストを受信すると、サーバーは通常、次のことを行います（簡単にするために、スレッドやフォークなどの同時実行技術は無視しています）。

• リクエスト文字列を解析する
• アクションを特定する（HistoricDataSets LIMIT Year (2010)この場合はフェッチ）
• 永続化レイヤー（この例ではOracle、と言うことができます）と対話して、データをフェッチします。

• プロトコルに従ってデータをフォーマットします。例：

  response-id：123
  success：true
  response-text：DataSets

• このようにフォーマットされたデータでクライアントに応答します。

これは、モノリシックサーバー（すべてのOSの動作がカーネル空間で行われるモノリシックカーネルに似ています）と呼ばれるものです。

再度、同じリクエストを受け取り、今回はサーバーを考慮します（簡単にするため、共有メモリのみをIPCと仮定しました）。

• Parserプロセスの共有メモリに要求を入れます
• Parserタスクを特定し、文字列を解析し、指示するExecutionerタスクを実行するためのプロセス。
• 次にExecutioner、Fomatterプロセスにデータを渡し、データをプロトコル文字列にフォーマットした後、サーバーに戻ります。
• サーバーはそれをクライアントにディスパッチします（応答）。

もちろん、代わりのParser、ExecutionerそしてFormatterそれは、単一のが、別のプロセスだったかもしれません。これは、私たちがマイクロサーバーと呼んでいるものです（マイクロカーネルが最低限必要なことをやっていることに似ています）。サーバーは実質的にリスニングと応答のみを行いますが、すべてのステップは異なるプロセスによって処理されます。

どれを選ぶべきですか？混乱しています！モノリシックサーバーは試行およびテストされていますが（ほとんどのHTTP-Webサーバー？）、プログラミングが容易であり、同時実行性を非常にうまく処理できます。マイクロサーバーは、一見、迅速で、1つのタスクを実行する1つのプログラムというUNIXの原則に沿っているように見えますが、特に開発が複雑です。並行性を念頭に置いてください。

質問
-各アプローチの長所と短所は何ですか（場合によっては）。
-どちらを使用するか （一般的な質問として解釈することもできます：IPCを使用するタイミング？）
-マイクロカーネルを選択した場合、コアサーバーの一部である必要がある機能とそうでない機能

類似/関連する質問

• 巨大なモノリシックアプリケーションの危険性
• 外部対埋め込みブラウザ（接線）
• モノリシックアプリをマルチスレッド（接線）に変換するためのアドバイス

• 見込み客は次の2つのカテゴリに分類できます。
  • 大：1分あたり約1,700-2,000リクエスト
  • 小：毎分約650-700リクエスト
• 要求サイクル（要求および後続の応答）ごとのデータ量は、平均で約1.20 MB、最悪の場合は約250-300 MBで正規分布していると想定できます。
• 製品のコンセプトは比較的新しいものですが、中核業務に影響を与える能力があるため、顧客の予算は展開後一定のラグ（9-12か月）を過ぎた場合にのみ柔軟になり、クライアントが受け入れるハードウェアの量が制限されます特にコミットする 小さなもの。
• 各顧客には、独自のクライアントサーバースタックがあります。サーバーは顧客のチームが管理する顧客のハードウェア上で実行され、クライアントは職務上の従業員のマシンに展開されます。
• クライアントアプリケーションとサーバーアプリケーションの両方のリモート更新は必須です
• PUSH製品がクリックした場合、サーバーによるリアルタイムサービスが「非常に」望ましい場合があります。

経済学は、選択の背後にあるコア理論よりもはるかに重要な答えを支配することがあります。最も重要なことは、あなたのアプリケーションが本当に厳しい展開を必要とする場合、あなたのケースで「広大な」何かを見ているなら、あなたが自分で発明する車輪の数が少ないほど良いということです。動作する場合、モノリシックかマイクロかは気にしません。それが気に入らなければ、私も気にしません！

非常に従来のWebページベースのアプリはあなたには向かないかもしれないことは事実かもしれません-しかし、あなたはもう少し広く見て、準備ができているものを使用して、後でその要素を何かに置き換えることができるかどうかを確認するためにあなたの方法を進化させる必要がありますより良い。そうすれば、最初の時間を節約できるだけでなく、実際の生活で本当に重要なことについての理解を深めることもできます。ここにあなたが考慮するかもしれないいくつかのポインターがあります。

1. 非常に高いスケーラビリティが本当に必要な場合は、サーバーが可能な限り高速に解約するのではなく、サーバーがタスクを分割する方法を検討してください。最終的には、Intelが地球上で最速のプロセッサを製造し、顧客が支払う準備ができていても、1台のサーバーが実際に処理できない負荷が発生します。そのため、要求ルーティングと負荷分散は、プロトコル自体の効率よりも重要です。

2. スケールアップが必要な場合は、HTTPが最適です。（ロードバランサーを使用すれば、簡単に購入できます）。カスタムプロトコルには、カスタムアレンジが必要です。

3. HTTPは、JavaスクリプトをHTMLで使用する必要があるという意味ではありません。通常のApacheサーバーとWebブラウザが必要なわけではありません。2つのカスタムクライアントと、通信が大きなデータ転送でない場合にライブラリとして使用できるAOLサーバーやlighthttpdなどの要素間でHTTPを使用できます。また、gSOAPなどのツールキットを使用して、両側でSOAPを使用することもできます。

4. HTTPが間違いなく法案に適合しない場合でも、物事をより効率的にするのに役立つBEEPのようなものを検討してください。あるいは、実績のあるRPC、RMIメカニズムが数多く存在します。

5. バックエンドで並列処理を行うことにより、最大限の作業ができることを確認してください。サーバーは、作業が完了したときにのみ照会されます。これが動作する場合-thereはのようなフレームワークですMPI、または助けになることができ、他の多くの分散コンピューティングツールキットがあります。

6. 最後に、私は正確なニーズを知る立場にはないかもしれませんが、両方が必要な場合は、大量のデータを配布するか、大量の計算を行う必要があります。

私にとって、新しいプロトコルを作成することと、新しいサーバーフレームワークを作成することは、一緒に行うべきではない二重の実験です。利害関係が非常に高い場合は、まず既存のツールを実際に試して、これまでに行われたことの限界を確認する必要があります。その場合にのみ、本当の課題を知ることができます。

分散システムの研究では、単なるWebアプリよりも多くのことが達成されています。ですから、それを調査する必要があります。

ディパン。

これは私にとって非常にアカデミックなようです。そして率直に言って、私は2番目のアプローチが同じようにモノリシックであると思います。これはあなたが行くべき限りです：

1. リクエストを解析する
2. リクエストを処理する

要求パラメーターに基づいて選択された要求ハンドラーは、要求処理のすべての側面をカプセル化する必要があります。ハンドラーがデータストアで実際にクエリを実行するかどうか、および標準の書式設定を使用してデータを返すかどうかは、上のレイヤーとは無関係です。実際のところ、おそらくそれはおそらくそれで十分でしょうが、それについて仮定をすることには価値がありません。

1. モノリシックカーネルはMicrokernelよりもはるかに古いです。Unixで使用されています。マイクロカーネルのアイデアは1980年代の終わりに登場しました。

2. モノリシックカーネルを持つOSの例は、UNIX、LINUXを マイクロカーネルを有するOSであるがQNX、L4、HURD、最初マッハ（ないMac OS Xの）後でハイブリッドカーネルに変換され、偶数MINIXは、デバイスドライバであるため、純粋なカーネルではありませんカーネルの一部としてコンパイルされます。

3. モノリシックカーネルは、マイクロカーネルよりも高速です。一方、最初のマイクロカーネルMachはMonolithicカーネルよりも50％遅いのに対し、L4のような最新バージョンはMonolithicカーネルよりも2％または4％遅いだけです。

4. モノリシックカーネルは一般にかさばります。一方、純粋なモノリシックカーネルは、プロセッサの第1レベルキャッシュ（第1世代のマイクロカーネル）に収まるようにサイズを小さくする必要があります。

5. モノリシックカーネルデバイスドライバーのカーネル空間に存在します。マイクロカーネルデバイスドライバーでは、ユーザー空間に常駐します。

6. デバイスドライバーはカーネル空間にあるため、モノリシックカーネルはマイクロカーネルよりも安全性が低くなります。（ドライバーの障害はクラッシュにつながる可能性があります）マイクロカーネルはモノリシックカーネルよりも安全であるため、一部の軍事用デバイスで使用されます。

7. モノリシックカーネルは信号とソケットを使用してIPCを保証し、マイクロカーネルアプローチはメッセージキューを使用します。1世代のマイクロカーネルはIPCの実装が不十分であったため、コンテキストスイッチが遅くなりました。

8. モノリシックシステムに新しい機能を追加するということは、カーネル全体を再コンパイルすることを意味 しますが、再コンパイルせずに新しい機能やパッチを追加することができます。