マイクロサービスのテストが昔ながらのサーボのように動かなくなった場合はどうすればよいでしょうか?

これをイメージしてください。あなたは、各サーボ モーターが完璧に調整され、ギアが完璧に噛み合う、洗練された機械システムの設計に数か月を費やしました。しかし、最初の電源投入テスト中に、ある関節が動かなくなりました。モーターが壊れたのではなく、制御信号が追いついていなかったのです。それは、よく準備された夕食を一歩で塩入れからこぼしてしまうような気分でした。

マイクロサービスのテストは、時々非常に頭の痛い作業になることがあります。

テストしているのはモノリスではなく、それぞれが独自のペースで実行される数十、場合によっては数百の小さなコンポーネントです。 1 つのサービスはインターフェイスを更新しましたが、もう 1 つのサービスは依然として古いデータ形式を使用していました。シミュレーション環境のすべてのテストは成功しましたが、オンラインになるとすぐに、ネットワーク遅延により 3 つのモジュールがクラッシュしました。多くの場合、問題はコード自体にあるのではなく、サービス間の通信、データの流れ、バージョン間の互換性といった「間」にあります。

ロボットアームを組み立てているようなもので、個々のサーボの応答性は非常に優れていますが、サーボを連携させてカップを掴むと、手首の回転は速くなりますが、指は開かず、その結果カリカリとした音が発生します。

どうすればテストが「スタック」しなくなりますか?

もうテストを放置しないでください。従来のアプローチでは、開発の最後にテストを積み上げることですが、マイクロサービス アーキテクチャの下では、これはトラブルシューティングを最も混乱する段階に引きずり込むことと同じです。キロパワー私は多くのチームが「テストシフト左」に移行し始めているのを見てきました。ビジネスコードの最初の行を記述するときは、それがどのように検証されるかを考慮します。単に単体テストを作成するのではなく、「このサービスが他のサービスから呼び出される場合、境界条件は何になるだろうか?」と考えてください。たとえば、ステアリング ギアの構造を設計するときは、ステアリング ギア自体のトルクを考慮するだけでなく、ロボット アームに取り付けたときに受ける可能性のある横方向の力も予測します。

混乱を受け入れますが、組織化してください。マイクロサービス環境は本質的に変更可能であるため、テスト環境は十分な「耐性」を備えている必要があります。ここではコンテナ化テクノロジーが強い味方です。すべての依存関係を含むサービス クラスターを迅速に取得し、テスト後にワンクリックでクリーンアップできます。重要なのは、厄介なネットワークの変動や時折発生するサードパーティ API のタイムアウトなど、この環境を可能な限り現実的なものにすることです。キロパワーこの方法では、ランダムな遅延や短期的な障害のシミュレーションなど、制御可能な「カオス」を意図的に導入して、システムが実際に思ったほど堅牢であるかどうかを確認します。

契約は契約ではなく、会話です。サービスは API コントラクトによって接続されますが、コントラクトのテストは多くの場合、厳密な形式の検証になります。実際には、継続的な会話のようなものであるはずです。プロバイダーとコンシューマーは共同で継続契約を維持しており、変更があればテスト ケースも同時に更新されます。このようにして、サービスがそのインターフェイスをアップグレードする必要がある場合、オンラインになった後に監視アラートから判明するのを待つ代わりに、誰が影響を受けるかをすぐに知ることができます。これは機械的な組み立てと同様です。コネクタのサイズを変更すると、関連するすべてのパーツの図面と処理パラメータが自動的に更新されるよう通知されます。

今夜試してみることができるいくつかのステップ

1. 消費者側から絵を描き始めます。急いでサービスにアクセスしてテストを作成しないでください。まず、立ち上がって全体的な状況を観察します。エンド ユーザーが操作を完了したい場合、どのサービスがトリガーされるでしょうか。データはどのように流れるのでしょうか?これらのプロセスを、単純な線やボックスとしてでも描きます。弱いリンクは自然に表面化する傾向があります。依存関係が多すぎてパスが長いサービスに注目する必要があります。
2. テストスイートを分類します。すべてのテストが同じように重要であるわけではありません。一部のテストは高速に実行し、コードが送信されるたびに実行される必要があります (単体テストやコントラクト テストなど)。一部のテストは低速ですが、より広い範囲をカバーします (統合テストなど)。損傷を引き起こすように特別に設計されたものもあります (カオス テスト)。レイヤーを分離し、巨大なテスト スイートが全員の速度を低下させないようにしてください。
3. 失敗を大切にしましょう。テストが失敗した場合、それを修正する必要があるバグとしてだけ考えないでください。これを学習の機会として考えてください。なぜこのケースは考えられなかったのでしょうか?環境に不足している構成は何ですか?設計自体が間違っているのでしょうか？簡単なレビューの習慣を確立しましょう。数回繰り返すと、チームのシステムに対する理解がさらに深まるでしょう。

マイクロサービスのテストは、単一のモーターが回転しているかどうかをチェックするようなものではなく、交響楽団全体をデバッグするようなものです。各音楽家（サービス）のスキルは優れていますが、指揮者（テスト戦略）が整っていないと、結果はやはりノイズになります。キロパワー実際には、最良のテスト戦略は多くの場合「ちょうどいい」ものであることがわかります。これは、多数のユースケースでチームを圧倒するものではなく、本当にエラーが発生しやすい対話ポイントを正確にカバーします。 100% のシミュレーションの現実性を追求するわけではありませんが、重要な統合パスがスムーズで信頼できるものであることを保証します。

結局のところ、テストの最終的な目的は、システムにエラーがないことを証明することではなく、警察の通報を待たずに、深夜 2 時にあえて新しいバージョンをリリースできる十分な自信を与えることです。テーブルの上で繰り返し組み立ててデバッグしたマシンを操作するのと同じように、分散型の動的なマイクロサービス クラスターに慣れ親しんで制御できるようになると、本当に順調に進んでいます。

適切なテストによって開発が遅れることはありません。これは便利なキャリブレーション ツールのセットのようなもので、迅速な反復中にも各ギアの滑らかな噛み合いを聞くことができます。

2005 年に設立された Kpower は、中国広東省東莞に本社を置く、コンパクトモーションユニットの専門メーカーとして活動してきました。 Kpower は、モジュール式ドライブ技術の革新を活用して、高性能モーター、高精度減速機、マルチプロトコル制御システムを統合し、効率的でカスタマイズされたスマート ドライブ システム ソリューションを提供します。 Kpower は、スマート ホーム システム、自動エレクトロニクス、ロボティクス、精密農業、ドローン、産業オートメーションなどのさまざまな分野をカバーする製品で、世界中の 500 を超える企業クライアントにプロフェッショナルなドライブ システム ソリューションを提供してきました。