多かれ少なかれ成功した製品は、既存のコードベースに新しい機能を追加することが非常に難しくなるため、新しい機能のコストは、その使用によるすべての可能な利点を上回ります。 もちろん、優れた気配りのあるアーキテクトが事前にアプリケーションを処理し、開発を正しい方向に導きます。 現時点で最も人気のあるアプローチは、1つの大きなコードを多数の小さなプロジェクションに分割することです。それぞれのプロジェクションが特定の機能を担います。 このようなシステムを設計するとき、大きな責任がかかります。 将来の変更がすべてを地獄に書き直すことを必要としないように、これらの別々に横たわる部分の間のこのタイプの相互作用を考えて開発する必要があります。
もちろん、このようなアーキテクチャの重要性を示し、どのアーキテクチャを良いと呼ぶことができ、どれがあまり良くないかについて話す専門家の記事がネットワーク上にたくさんあります。 独自のプロトコルを使用した大規模アプリケーションの個々のプログラム間の相互作用、プロトコルとドキュメントのバージョン管理、プログラムインターフェイスでのドキュメントの作成、これらすべてを一緒に展開および同期する方法が多数あります。 もちろん、そのような記事または方法はそれぞれ論理的で一貫性があり、特に説明された方法が実践によって確認された場合は特にそうです。 しかし、問題は、デザイナーが最終的にどのシステムを取得したいかを知らないことではありません。 問題は、そのような正しいアーキテクチャに切り替える方法と、モノリシックなアプリケーションの作成を停止し、大人のマイクロサービスの作成を開始して、男の子が恥ずかしくないようにする方法です。
最初のモノリス
第一に、普及している「最初のモノリス」アプローチは完全に正当化されており、開発コストと開発速度の間の妥当な妥協案のようです。 小さなモノリシックアプリケーションには、いくつかの明らかな利点があります。主なものの1つは、新しい機能を追加する速度です。 モノリシックプロジェクトでは、コードベースの一貫性を確認し、追加されたばかりの新しい機能が動作することを確認する方が簡単です。 間違いなく、経験豊富な読者は、マイクロサービスがアプリケーションのさまざまな部分の不十分な接続を実現できることに気付くでしょうが、ほとんどの場合、モノリシックプロジェクトの積極的な開発には最高品質ではないコードベースがあることを忘れないでください。
マイクロサービスから逃げないでください
2番目のステートメントは、無限の機能を備えた無限に巨大なアプリケーションをモノリシックにすることはできないということです。 遅かれ早かれ、異なるサーバー、または少なくとも異なるプロセスで実行されるアプリケーションの一部が表示されます。
開始する主なもの
3番目の結論は最初の2つから導き出されており、モノリシックアプリケーションは遅かれ早かれアーキテクチャをマイクロサービスアプリケーションに変更すると述べています。 したがって、開発戦略を変更してマイクロサービスの導入を開始する必要があるアプリケーション開発の時点があります。
上記の3つのステートメントは、2つの質問を提起します。いつ、どのように。 順番に行きましょう。
すでにマイクロサービスを削減する時が来たと理解する方法は？
純粋に実際にこの問題に取り組み、上と下から希望の時点を制限しましょう。 間違いなく、すべてのチームメンバーがアプリケーションのいずれかの部分にまだ指向している場合、モノリスをカットするには時期尚早です。 また、モノリシックアーキテクチャの適時性の兆候は、チームの新参者が使い慣れた直後に簡単かつ自然に新しい機能の開発を開始できることです。
htmlページ全体をキャッシュする場合、マイクロサービスを割り当てるのはすでに遅くなっていますが、速度を上げるには、アプリケーションの半分を書き換えるか、ORMを置き換えるか、通常はすべてが問題なく、アプリケーションが遅くならない別の言語ですべてを書き換える必要があります。
モノリシックアプリケーションでファウラーのリファクタリングを簡単に適用できる場合、マイクロサービスアーキテクチャに切り替えるのは時期尚早です。 しかし、単純なリファクタリングが予見されない場合、または純粋にファウラーの方法で改革できるような場所を見つけることが一般に難しい場合、モノリシックアーキテクチャを長い間交換する必要があります。
そして、マイクロサービスアーキテクチャへの切り替えを開始する必要性の最も重要な基準は、新しい機能を追加するコストがこの機能の利点を超え始めたときです。
マイクロサービスを優先してアーキテクチャの移行を開始する場所
パラダイムを変更するには、いくつかの戦略があります。 最も単純で、ほとんど常に間違っているのは、次に示す例として、モノリシックアプリケーションを使用してゼロからマイクロサービスアーキテクチャを開発することです。 おそらく、このアプローチの普及は、マイクロサービス上で直接アプリケーションを作成する支持者の主な議論です。 しかし、これは最初のアプリケーション開発に真剣に価値を追加します。
モノリスからマイクロサービスへの移行へのより適切なアプローチは、マイクロサービスの段階的な発芽と、メインアプリケーションとは別に新しい機能の作成です。 このアプローチはうまく機能していますが、重大な欠点が1つあります。主要なモノリシックアプリケーションは、近い将来に消えることはありません。 その結果、独立したマイクロサービスのセットの代わりに、モノリスと一連の補助サービスができます。
最終的に、マイクロサービスアーキテクチャに切り替える正しい方法は、主要なモノリシックアプリケーションを、強力な相互接続性を備えた複数の大規模なアプリケーションに分割する方法です。 その後、サブアプリケーションは個別に検討およびリファクタリングされ、同時に近隣にヒットし、それらを一緒に適応させて変更するように強制します。 徐々に、このアプローチにより、接続性が低下し、各サブアプリケーションの確立されたインターフェイスが出現します。 このような十分に確立された時点に達すると、隣接するサブアプリケーションに影響を与えることなくサブアプリケーションに変更を加えることができるようです。 また、このサブアプリケーションは、モノリスがよりシンプルで低いと見なされます。 そして、彼と同様の手順が行われています。 徐々に、アプリケーションは、ほぼ等しい部分に勝ちます。 プロセスの一部は不要になり、一部は既存の部品を複製します。または、重複を排除するために1つの共通サービスにマージします。 その結果、遅かれ早かれ、マイクロサービスアーキテクチャ上で確立されたアプリケーションが判明しました。
結論の代わりに。
マイクロサービスは良いです。 モノリスは良いです。 良いコードは良いです。 作業コードは良いです。 この記事は、速度が低下したり、誤って記述されたり、意図とは異なる方法で記述されたりするアプリケーションの開発原則を緊急に変更するものではありません。 また、マイクロサービスアーキテクチャは、開発者のすべての問題に対する万能薬ではありません。 この記事では、モノリシックアーキテクチャからマイクロサービスアーキテクチャへの移行のポイントと方法について説明します。
「フォールトトレランス」、「配布」、「スケーラビリティ」は確かに優れていますが、これはマイクロサービスアーキテクチャの主な利点ではありません。 このアプローチが提供する最も重要なことは、変更のコストを削減することです。