前書き
建築スタイルの選択は、情報システムを構築する上での基本的な技術的解決策の1つです。このシリーズの記事では、アプリケーションを構築するための最も人気のあるアーキテクチャスタイルを分析し、いつ最も好ましいアーキテクチャスタイルであるかという質問に答えることを提案します。その過程で、モノリスからマイクロサービスまでの建築スタイルの発展を説明する論理的な連鎖を描くことを試みます。
ちょっとした歴史
開発者に「なぜマイクロサービスが必要なのか」という質問をしようとすると、さまざまな回答が得られます。マイクロサービスによってスケーリングが改善され、コードが理解しやすくなり、障害耐性が向上することがわかります。また、マイクロサービスを使用すると「コードをクリーンアップ」できると聞くこともあります。歴史に戻って、マイクロサービスの出現の目的が何であったかを理解しましょう。
要するに、私たちの現在の理解におけるマイクロサービスは次のように現れました。2011年、ジェームズルイスはさまざまな企業の仕事を分析し、サービス展開を加速するという観点からSOAを最適化する新しいパターン「マイクロアプリ」の出現に注目しました。少し後の2012年、アーキテクチャサミットで、パターンの名前がmicroserviceに変更されました。したがって、マイクロサービスを導入する最初の目標は、悪名高い市場投入までの時間を改善することでした。
マイクロサービスは2015年に「誇大広告」になりました。いくつかの研究によると、マイクロサービスのトピックに関する講演なしに完了した会議は1つもありませんでした。さらに、一部の会議はマイクロサービス専用でした。現在、多くのプロジェクトがこのアーキテクチャスタイルの使用を開始しており、プロジェクトに大量のレガシーコードが含まれている場合、マイクロサービスへの移行が積極的に実行されている可能性があります。
上記のすべてにもかかわらず、「マイクロサービス」という用語を定義できる開発者はまだかなりいます。しかし、これについては少し後で話します...
モノリス
アーキテクチャスタイルとマイクロサービスはモノリス（またはオールインワン）です。モノリスが何であるかを伝えることはおそらく意味がないので、アーキテクチャスタイルのさらなる開発を開始したこのアーキテクチャスタイルの欠点をすぐにリストします：サイズ、一貫性、展開、スケーラビリティ、信頼性、慣性。以下では、それぞれの欠点を個別に理解することを提案します。
サイズ
モノリスは非常に大きいです。そして、彼は通常、非常に大きなデータベースと通信します。アプリケーションが大きくなりすぎて、1人の開発者がまったく理解できなくなっています。このコードの背後で多くの時間を費やした人だけがモノリスでうまく機能できますが、初心者はモノリスを理解しようとすることに多くの時間を費やし、それを理解するという事実ではありません。通常、モノリスを扱う場合、モノリスを多かれ少なかれよく知っていて、他の新しい開発者を1年半叩きつける特定の「条件付き」シニアが常にいます。当然のことながら、そのような条件付きの先輩は失敗の単一のポイントであり、彼の出発はモノリスの死につながる可能性があります。
接続性
モノリスは「泥の大きな球」であり、その変化は予測できない結果につながる可能性があります。ある場所で変更を加えることにより、別の場所のモノリスに損傷を与えることができます（同じ「私の耳を傷つけた、* @が落ちた」）。これは、モノリスのコンポーネントが非常に複雑で、最も重要なこととして、非自明な関係にあるという事実によるものです。
展開
コンポーネント間の複雑な関係のため、モノリスの展開は、独自の儀式を伴う長いプロセスです。このような儀式は通常、完全に標準化されておらず、口コミで伝えられます。
スケーラビリティ
モノリスモジュールは、競合するリソース要件を持つ可能性があり、ハードウェアの観点から妥協する必要があります。モノリスがサービスAとBで構成されていると想像してください。サービスAはハードディスクのサイズを要求し、サービスBはRAMを要求しています。この場合、モノリスがインストールされているマシンが両方のサービスの要件をサポートしている必要があります。または、手動でサービスの1つを無効にする必要があります。
別の例（より古典的）：サービスAはサービスBよりもはるかに人気があるため、サービスAを100にし、サービスBを10にする必要があります。ここでも、2つのオプション：100個の本格的なモノリスを展開するか、一部の次に、サービスBを手動で無効にする必要があります。
信頼性
すべてのサービスが一緒になっているため、モノリスが落ちると、すべてのサービスが一度に落ちます。実際、これはそれほど悪くはないかもしれません。少なくとも分散システムで部分的な障害は発生しませんが、一方で、ユーザーの0.001％が使用する機能のエラーにより、システムのすべてのユーザーを失う可能性があります。
慣性
モノリスのサイズが大きいため、新しいテクノロジーに切り替えることは困難です。結果として、その条件付きシニアの保持は別のタスクです。プロジェクトの開始時に選択された技術スタックは、製品の開発を妨げるブロックになる可能性があります。
結論
次回は、コンポーネントとSOAに移って、人々がこれらの問題をどのように解決しようとしたかについて説明します。
続きを読む：