1 はじめに
従来の開発では、サービスのアドレスは比較的静的であるため、対応するサービスの開発者を見つけて、対応するサービス インターフェイスのアドレスを学習するだけで済みます。
マイクロサービス アーキテクチャの開発プロセスで、RESTFul スタイルの API インターフェイスを呼び出す必要がある場合、対応するサービスがネットワーク上のどこにあるかを知る必要があります。つまり、サービスの IP とポート番号を知る必要があります。サーバ。マイクロサービスアーキテクチャや分散環境では、この問題を解決することが難しいため、サービスの登録と検出の技術が不可欠であり、プログラマが昇進するために習得しなければならないコア技術の1つでもあります。
2. アーキテクチャの進化
まず質問ですが、これからショッピングモールのプロジェクトをやろうとした場合、建築家としてシステムのアーキテクチャをどのように設計すればよいでしょうか? タオバオの構造を直接コピーするのは簡単ではない、と心の中で思っているはずです。しかし、実際の起業環境では、プロジェクトが瀕死の状態になることもあり、最初に多大な人的資源と資金を投資しても、一度プロジェクトが失敗すると大きな損失を被ることになります。
経験豊富な建築家として、会社の財務リソースと人的投資予算を組み合わせて、最適なアーキテクチャを選択するのが王道です。大規模なサイトは小規模なサイトから成長し、アーキテクチャも成長します。
大規模な Web サイトのアーキテクチャは最初から一定ではなく、ユーザー数とデータ量が増加し続けるにつれて継続的に進化し続けた結果です。
アーキテクチャが進化を繰り返す過程では、多くの問題に遭遇しますが、技術開発の本質は常に問題を発見し、それを解決することであり、問題を解決した後にまた問題が見つかります。
2.1 モノリシックアーキテクチャ
システム構築当初はユーザー数も多くなく、すべての業務をアプリケーションパッケージにパッケージ化してTomcatコンテナ上で実行し、サーバとデータベースを共有するこのアーキテクチャを一般にモノリシックアーキテクチャと呼びます。
初期段階では、このアーキテクチャの効率は非常に高く、ユーザーのフィードバックに基づいて迅速に繰り返し起動できます。しかし、ユーザー数が増えると、サービスのメモリと CPU が不足し、ボトルネックが発生しやすくなります。新たな問題を解決するにはどうすればよいでしょうか?
2.2 アプリケーションとデータの分離
ユーザー要求の量が増加するにつれて、サーバーのメモリと CPU は増加し続け、ユーザー要求に対する応答時間は遅くなります。このとき、アプリケーションとデータベースを分離し、それぞれにサーバーを使用することを検討できます。
ある日突然、掃除のおばさんが誤って電線に触れてしまい、サーバーの 1 台が停電し、ユーザーからのすべてのリクエストがエラーを報告し、その後、苦情の電話が相次いだのです。
2.3 クラスターの展開
単一のインスタンスは、サーバー障害やサービス容量のボトルネックなどの単一点の問題を簡単に引き起こす可能性があります。どうすればよいですか? 賢明な方は、クラスターを使用することを考えたはずです。
クラスタのデプロイメントとは、複数のサーバーまたは仮想マシンにアプリケーションをデプロイすることを指します。ユーザーは、サービス バランシングを通じてインスタンスの 1 つにランダムにアクセスし、複数のインスタンスのトラフィックのバランスがとれます。インスタンスに障害が発生した場合、そのインスタンスはオフラインにできますが、他のインスタンスはオフラインにされません。 Impact は引き続き外部にサービスを提供できます。
ユーザー数の急増に伴い、上司はチーム規模を拡大するために投資を増やすことを決定しました。開発チームが成長しても、開発チームの効率はそれほど向上していません。以前は小規模なチームであれば、週に 1 回繰り返しオンライン化できましたが、現在では少なくとも 2 ～ 3 週間かかります。
ビジネス ロジックはますます複雑になり、コード間の結合は非常に深刻になっており、コード行を変更すると、オンラインでいくつかの問題が発生する可能性があります。アーキテクトは、アーキテクチャのリファクタリングの必要性を認識しています。
2.4 マイクロサービスアーキテクチャ
モノリシック アーキテクチャがある程度進化すると、開発とテストの複雑さによりコストが増加し、チーム サイズの拡大により作業の結合もより深刻になります。
モノリシック アーキテクチャがボトルネックに遭遇したとき、マイクロサービス アーキテクチャが誕生しました。マイクロサービスは前者です