マイクロサービスは、モノリスに取って代わる「銀の弾丸」として販売されることが多いようです。しかし、誰もがこのアプローチを好むわけではありません。実際、それは時々間違ってまたは不適切に使用されます。以下は、さまざまな企業でマイクロサービスを使用するときに直面した「ラッキー」な問題の例であり、今後は繰り返したくない問題です。
ファントムのスケーラビリティ
マイクロサービスアプローチの大きな利点は、スケーラビリティです。無限に大きいユーザーのフローと高負荷は避けられないと考えられています。このため、予備的な最適化に多くの時間が費やされており、有用なビジネス機能ではありません。実際、高負荷が常に存在するとは限りません。
事前最適化の最初の犠牲者は線形ビジネスプロセスです。多くのマイクロサービスに分解されます。責任の分割または架空のスケーリングの理由から、将来のための一種の予備。その結果、企業がITランドスケープをナビゲートし、ITと同じ言語を話すことは、開発者自身のソースコードをナビゲートすることの問題は言うまでもなく、より困難になります。
サービスの相互作用の問題
受け取られたサービスは、monorepaから別のリポジトリに分散されます。サービス自体をリンクすることが難しくなっています。この場合、マイクロサービスAPIのバージョンは、マイクロサービスクライアントの同じAPIのバージョンとは異なる可能性があります。次に、古き良きJSONをProtobufに、HTTPをgRPCに置き換えて、パフォーマンス、タイピング、および便利なAPIバージョン管理を実現します。
残念ながら、gRPC + Protobufのようなソリューションにはバグがありません。エラーの伝播と、サービスの入出力ペアの既知の不一致により、サービスが順次低下する可能性があります。コードベースはますます大きくなり、デバッグサービスはプレーンテキストデータよりもはるかに困難であり、まったく新しい問題が山積しています。
この問題は、通常のテストプロセスで解決する必要があります。特に、統合テスト。ただし、統合テストは、ビジネスプロセスの一部として、マイクロサービスとそのグループごとに作成して実行する必要があります。これはかなり複雑な作業であり、通常、余計な時間を費やしたくありません。この場合、マイクロサービス統合テストは、モノリスの単体テストの形に減らすことができます。
古い制限と習慣
これらすべてにより、モノリスの通常の制限はマイクロサービスに移行します。印象的な例：すべてのマイクロサービス用の1つのプログラミング言語と1つのデータベース。前者の場合、これはモノリスの以前の制限であり、後者の場合は、システム全体の「ボトルネック」になることを目指しているレガシーです。開発者による拒否と、異なるプログラミング言語で構築された異種システムの存在の可能性の管理により、緊急の問題を解決するための適切なツールを選択する可能性が失われます。
上記に加えて、個々のマイクロサービスには、開発者が責任を負わない場合があります。誰もがすべてをサポートし始め、誰も何にも責任を負いません。この場合、最後にコードを変更した人を除いて、個々のサービスの操作に関する知識は誰にもありません。開発者の非同期、サブジェクト領域内で解決されるタスクに関連するマイクロサービスの作業の本質の理解の喪失があります。
インフラ官僚
マイクロサービスは、モノリスよりも維持が困難です。サーバーのペアであったインフラストラクチャは、小さなプライベートクラウドになります。開発者がこのようなソリューションをサポートするには、多くの時間がかかり、将来の管理のために問題が発生します。追加の官僚制度の必要性ははるかに高まっています。個々の従業員が雇用され、個別のプロセスが作成されます。
このような場合、マイクロサービスを操作するためのルールセットを公開して、マイクロサービスループの整合性を維持できます。最悪のケースは、1回限りのスクリプトまたは移行を実行する可能性さえも拒否し、パスへの直接アクセスを妨げることです。要点は、スクリプトが本格的なサービスとしてスタイル設定され、マイクロサービスの長いリストに別の行を追加することです。
未来
有用な信号よりも何倍も多くのノイズがあるシステムであることがわかります。どこでも-インフラストラクチャから特定のサービスのコードまで。開発者によるサービス間の相互作用のスキームの理解から企業の管理まで。プログラマーは知らず知らずのうちにパズルの解法の達人になります。
もちろん、古典的なモノリスはそれ以上のものではありません。遅い、その状態を維持する、処理するのが難しい、単体テストや統合テストなどの対象外です。しかし、私たちはもっとうまくやることができます！マイクロサービスのmodのおかげで、他の多くの利点の中でも、CI / CDの増加を確認し、テストに取り組みました。マイクロサービスだけでなく、他のアプローチにもそれらを適用できるようになりました。
次に新しいシステムを開発したり、古いシステムをリサイクルしたりするときは、それがどんな規模であっても、よく考えてください。企業にはスケーラビリティが必要ですか？高負荷を処理する機能が必要ですか？あなたは本当にマイクロサービスの準備ができていますか？それとも、より保守的なアーキテクチャから始める方が良いでしょうか？
たぶんロケットを作るのではなく、シンプルなスクーターを作ってください。