マイクロサービスに対する誇大宣伝のピークは過ぎたようです。 「モノリスを 150 のサービスに移行した方法」という投稿を週に何度も読むことはなくなりました。 今では、「一枚岩が嫌いなわけではない。ただ効率を重視しているだけだ」という常識的な考えを聞くようになりました。 いくつかの移動も観察されました 。 XNUMX つの大規模なアプリケーションから複数の小規模なサービスに移行する場合、いくつかの新たな問題を解決する必要があります。 それらをできるだけ簡単にリストしてみましょう。
設定：基礎化学から量子力学まで
バックグラウンド プロセスを使用した基本的なデータベースとアプリケーションのセットアップは、非常に簡単なプロセスでした。 私は Github で Readme を公開していますが、多くの場合 8 時間、長くても XNUMX 時間後にはすべてが機能し、新しいプロジェクトを開始します。 コードの追加と実行は、少なくとも初期環境では初日に行われます。 しかし、マイクロサービスに挑戦すると、最初の起動時間は飛躍的に長くなります。 はい、オーケストレーションを備えた Docker と KXNUMX マシンのクラスターができましたが、初心者プログラマーにとって、これはすべてはるかに複雑です。 多くのジュニアにとって、これは本当に不必要な面倒な負担です。
システムがわかりにくい
しばらくジュニアに焦点を当てましょう。 モノリシック アプリケーションでは、エラーが発生した場合、それを追跡してすぐにデバッグに移るのが簡単でした。 ここで、サービスが、別のサービスを処理しているメッセージ バス上で何かをキューに入れている別のサービスと通信していると、エラーが発生します。 最終的に、サービス A がバージョン 11 を実行しており、サービス E がすでにバージョン 12 を待っていることを確認するには、これらすべての部分を組み合わせる必要があります。これは、標準の統合ログとは大きく異なります。つまり、対話型のターミナル/デバッガを使用して実行する必要があります。プロセスを段階的に進めていきます。 デバッグと理解は本質的により困難になっています。
デバッグできない場合は、テストしてみます
継続的統合と継続的開発は今や一般的になってきています。 私が目にする新しいアプリのほとんどは、新しいリリースごとに自動的にテストを作成して実行し、登録前にテストを受けてレビューする必要があります。 これらは放棄されるべきではない素晴らしいプロセスであり、多くの企業にとって大きな変化でした。 しかし、実際にサービスをテストするには、アプリケーションの完全に動作するバージョンを取得する必要があります。 8 のサービスからなる K150 クラスターを担当したあの新人エンジニアを覚えていますか? さて、ここで、これらすべてのシステムを起動して、すべてが実際に機能することを確認する方法を CI システムに教えます。 これはおそらく労力がかかりすぎるため、各部分を個別にテストすることにします。スペックは十分で、API はクリーンで、サービスの障害は分離されており、他には影響しないと確信しています。
すべての妥協には正当な理由があります。 右？
マイクロサービスに移行する理由はたくさんあります。 これは、柔軟性を高め、チームを拡張し、パフォーマンスを向上させ、より良い持続可能性を提供するために行われるのを見てきました。 しかし実際には、私たちは進化し続けるモノリスを開発するためのツールと実践に何十年も投資してきました。 私はさまざまなテクノロジーの専門家と協力しています。 私たちは通常、単一の Postgres データベース ノードの制限に遭遇するため、スケーリングについて話します。 会話のほとんどは、 .
しかし、私は常に彼らのアーキテクチャについて学ぶことに興味があります。 マイクロサービスへの移行のどの段階にありますか? モノリシック アプリケーションに満足していると言うエンジニアが増えているのは興味深いことです。 多くの人がマイクロサービスの恩恵を受けることになり、そのメリットは移行過程での困難を上回るでしょう。 しかし個人的には、私のモノリシック アプリケーション、つまりビーチにある場所を与えてください。私は完全に満足しています。
出所： habr.com