システムが行き詰まり始めたら、アーキテクチャを変更してみてはいかがでしょうか?

次のシナリオを想像してください。非常に人気のあるオンライン サービスは、最初は非常に高速に実行されますが、ユーザーの数が増加するにつれて、特定の機能モジュールが突然停止してしまいます。結果？システム全体の速度は朝のラッシュ時の都市部の幹線道路と同じくらい遅い。そこにはすべての車が立ち往生しており、誰も動けない。現時点では、その道路を広げるべきか、それとも小さな道路をさらにいくつか開けるべきか、考える必要があるかもしれません。

これは私たちがよく遭遇することです。もともと柔軟なシステムですが、すべてが連携しているため、一部にわずかな不具合があると、サービス全体が揺らいでしまいます。インターフェイスを更新したところ、バックエンド データベースがほぼ崩壊しました。これには聞き覚えがあるでしょうか？

「かさばる」ソフトウェアが頭痛の種を引き起こすのはなぜですか?

まずは本当のことについて話しましょう。すべての機能を「ビッグ Mac」アプリケーションにパッケージ化する従来のアプローチは、最初は確かに問題がありませんでしたが、ビジネスがますます複雑になるにつれて、問題が静かにやって来ました。

たとえば、ユーザー ログインの検証方法を変更したいだけですが、注文処理モジュールが関係しており、その注文モジュールが在庫管理に接続されていることがわかります... そうですね、ちょっとした変更でも、何かが対処されていないのではないかと心配して、アプリケーション全体を再テストする必要があります。リビングルームの照明を交換したいと思ったら、家全体の配線を確認しなければならないことが判明したような気がします。

さらに厄介なのは、スケーリングの問題です。画像アップロード機能が突然人気を博し、アクセス数が急増した場合、従来のアーキテクチャではサーバー全体をアップグレードするしかありません。しかし問題は、他の機能には明らかにそれほど大きなプレッシャーがないにもかかわらず、リソースも消費しなければならないことです。なんとももったいない。

マイクロサービス: 大規模なショッピング モールを専門店に分割する

システムを柔軟かつ保守しやすくする方法はあるでしょうか?はい、現在多くの人がマイクロサービス アーキテクチャについて議論しています。これは、あらゆるものを販売する大きなショッピング モールを、それぞれの特徴を持つ小さな店の列に分割したものと考えることができます。

各店舗は独立して運営されており、独自の明確な事業範囲を持っています。コーヒー販売者はコーヒーを作ることに重点を置き、パン屋はパンを製造することに重点を置きます。もちろん、コーヒーを買うときにクロワッサンを持参するなど、相互に協力する必要がありますが、それぞれのキッチン、レジ係、在庫はすべて独立しています。このようにすれば、パン屋のオーブンが一時的に修理されたとしても、コーヒーショップは通常どおり営業でき、顧客が完全に選択肢を失うことはありません。

ソフトウェアに対応する各マイクロサービスは、独立したビジネス機能を担当する小さな店舗のようなものです。ユーザー管理、注文処理、支払いインターフェース...それぞれが自己完結型であり、明確なインターフェースを通じて相互に通信します。サービスをアップグレードしたいですか?システム全体に影響を与えることなく、個別に処理するだけです。

Java を使用してマイクロサービスを構築するのは、レゴを構築するようなものです

実装方法について言えば、Java エコシステムには確かに便利なツールがたくさんあります。 Spring Boot を使用すると、独立したアプリケーションを簡単かつ簡単に作成できます。 Spring Cloud コンポーネントのセットを使用すると、サービス検出、構成管理、負荷分散がすべてすぐに実行できます。

たとえば、ユーザー行動分析モジュールなどの新しい機能を追加するとします。マイクロサービス アーキテクチャでは、これは、ブロック上に新しいデータ分析スタジオを開設することに相当します。この新しいサービスを構築し、所定の方法で他のサービスと通信させ、サービス リストに登録するだけで、動作を開始できます。従来のユーザーサービスやオーダーサービスは一切変更する必要がありません。まるで路面にできた新しいお店のようです。古くからの隣人は、挨拶するだけで協力を始めることができます。

プランを選ぶ際に注意すべきポイントは何ですか？

新しいアーキテクチャを試すことにした場合、考慮する価値のあるいくつかの実際的な要素があります。

チームが協力する方法は変わるでしょうか?マイクロサービスとは、多くの場合、開発から運用、保守まで、各小規模チームが 1 つまたは 2 つのサービスを担当することを意味します。これには、チームのより大きな自主性とプロフェッショナリズムが必要ですが、同時にチーム間の調整の損失も軽減されます。あなたのチーム構造はこの変化に対応する準備ができていますか?

運用と保守の複雑さは増加していますか?サービスが増えると、導入、監視、トラブルシューティングの複雑さが確実に増加します。現時点では、有用な監視システムと自動展開プロセスが必要になります。商店街の管理みたいな感じですね。明確な標識、均一なセキュリティ、タイムリーなメンテナンス サポートが必要です。

どこから始めるのが最も安全ですか?既存のシステムを変革する場合は、通常、境界が明確で比較的独立したモジュールから始めることをお勧めします。たとえば、まずユーザー認証を分離するか、支払いインターフェースを独立したサービスにします。変更を段階的に行うことで、中核となるビジネスが影響を受けないようにすることができます。

ここまで言うと、「原理は理解できたけれど、各ステップをどのように進めればよいのでしょう?」と考えているかもしれません。サービス境界の設計から通信メカニズムの構築、データの一貫性の確保に至るまで、検討する必要のある詳細は実際に数多くあります。

私たちキロパワーチームがクライアントによるこの種のアーキテクチャ変革の実装を支援する場合、チームは通常、まず既存のビジネス フローを整理し、本質的に独立したモジュールを特定することに時間を費やしてから、段階的な分離パスを計画します。結局のところ、アーキテクチャの変革は車輪の再発明ではなく、スムーズに実行しながらステップを踏むことです。走行中の車の部品を交換するのと同じように、正確さとタイミングが必要です。

優れたアーキテクチャは最終的にテクノロジーを目立たなくし、ビジネスを円滑に運営できるようにします。各機能モジュールを独立して拡張し、迅速に反復できるようになると、システム全体が本当に生き生きとします。システム全体は、もはや注意深く維持する必要のある巨大な存在ではなく、活気に満ちた協力的な有機体のグループとなります。

かつては頭痛の種だった「渋滞」の瞬間が徐々に少なくなり、システムの自己規制機能が強化されているように見えることがわかります。そして、これはおそらく技術設計の最も魅力的な部分です。構造上の知恵を使用して、ビジネスの自由な成長への道を静かに切り開きます。

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