プロジェクトで発生した問題点のまとめ (2)

CAP理論

CAP理論は分散システムにおいて非常に重要な理論であり、分散システムでは一貫性(Consistency)、可用性(Availability)、分割耐性(Partition Tolerance)の3つの特性がせいぜい満たされるまでに限界があることを指摘しています。 2つ、3つの特性を同時に満たすことはできません。

具体的には、CAP 理論では、分散システムでは、ネットワークの分断やマシンの障害などの要因により、分散システム内の異なるノードが異なる状態になる可能性があるため、分散システムを設計する際には、これらの状態にどのように対処するかを考慮する必要があると説明しています。システム。CAP 理論では、一貫性 (Consistency)、可用性 (Availability)、およびパーティショントレランス (Partition Tolerance) という 3 つの特性を提案しています。

一貫性: 分散システムでは、すべてのノード間のデータは一貫しています。つまり、すべてのノードのデータはいつでも同じです。
可用性: 分散システムでは、すべてのノードのデータにいつでもアクセスできます。つまり、システムは高可用性を備えており、一部のノードの障害によって使用できなくなることはありません。
パーティショントレランス (パーティショントレランス): 分散システムでは、ネットワークの分割やマシンの障害などの要因によってノード間の通信が妨げられた場合でも、システムは引き続き動作できます。分散システムでは、ノードのネットワークが接続されている必要があります。しかし、何らかの障害により一部のノードが接続されず、ネットワーク全体がいくつかのエリアに分断されてしまいます。データは、これらの切断された領域に分散されています。これをパーティションと呼びます。

CAP 理論は、分散システムでは、同時に満たされる特性は最大 2 つであり、3 つの特性を同時に満たすことはできないと指摘しています。これは、ノードに障害が発生した場合やネットワークが分断された場合に、システムは一貫性と可用性の間でトレードオフを行う必要があるためです。一貫性を確保することを選択した場合は、サービスを停止し、障害が回復するかネットワーク接続が再開されるまでサービスの提供を続行するまで待つ必要があるため、システムの可用性が低下します。可用性を確保することを選択した場合は、次のことを行う必要があります。一貫性を高め、ノード間の不整合なデータを許容するため、システムの一貫性が低下します。

実際の分散システムでは、CAP 理論の 2 つの特性を実際のニーズに応じて選択し、トレードオフする必要があります。たとえば、金融システムなどの非常に高い一貫性要件を持つシステムの場合、一貫性とパーティション耐性を確保することを選択でき、その結果、可用性が犠牲になります。大規模なインターネットアプリケーションの場合は、ノード間のデータの不整合を許容するために、可用性の確保とパーティションのフォールトトレランスを選択できます。

ナコスではCPやAPは保証されていますか？

Nacos は CP モードと AP モードの両方をサポートしており、実際のニーズに応じて構成できます。

Nacos では、nacos.core.cluster.switch パラメーターを構成することで、CP モードまたは AP モードの使用を選択できます。このパラメータが nacos に設定されている場合は AP モードが使用され、このパラメータが raft に設定されている場合は CP モードが使用されます。

具体的には、Nacos の AP モードは、ネットワークの分断やノード障害が発生した場合でも、システムの可用性を確保するためにサービスを提供できることを意味します。Nacos の CP モードは、データの一貫性とパーティションのフォールトトレランスを保証し、比較的高いデータの一貫性を必要とする財務シナリオやその他のシナリオに対応できることを意味します。

たとえば、金融分野の資本取引システムなど、アプリケーションにデータの一貫性に対する高い要件がある場合、Nacos を CP モードで構成できます。CP モードでは、Nacos はすべてのデータをすべてのノードに同期してデータの一貫性を確保しますが、ノードの障害やネットワークの分断が発生した場合、システムの可用性が低下する可能性があります。高可用性を確保するために、展開に複数のノードを使用でき、負荷分散を通じて高可用性を実現できます。

インターネットアプリケーションなど、アプリケーションに高いデータ一貫性が必要ない場合は、Nacos を AP モードで構成できます。AP モードでは、Nacos はノード間のデータの不整合を許容し、システムの可用性を確保します。ただし、ノードに障害が発生したり、ネットワークの分断が発生したりすると、異なるノード間でデータの不整合が発生する可能性があるため、アプリケーション自体で対処する必要があります。

たとえば、以下は AP モードを使用した Nacos 設定ファイルのサンプルです。

# 使用AP模式
nacos.core.cluster.switch=nacos

上記の設定では、AP モードを使用するには、nacos.core.cluster.switch パラメーターを nacos に設定します。CP モードを使用する場合は、このパラメータを raft に設定するだけです。

この構成はどこで構成されていますか

この構成は、Nacos 構成ファイルで設定できます。具体的には、conf/application.properties ファイルでこのパラメータの値を設定して、CP モードと AP モードのどちらを使用するかを選択できます。

たとえば、Nacos を CP モードで構成する場合は、次の構成を conf/application.properties ファイルに追加できます。

# 使用CP模式
nacos.core.cluster.switch=raft

Nacos を AP モードで構成する場合は、次の構成を conf/application.properties ファイルに追加できます。

# 使用AP模式
nacos.core.cluster.switch=nacos

Nacos の設定ファイルを変更した後、有効にするために Nacos を再起動する必要があることに注意してください。さらに、構成ファイルが誤って変更されたり改ざんされたりすることを避けるために、安全な構成管理ツールを使用して実稼働環境で Nacos 構成ファイルを管理することをお勧めします。

Nacos はデフォルトで AP または CP を使用しますか?

Nacos はデフォルトで AP モードを使用します。もちろん、ユーザーは実際のニーズに応じて構成でき、Nacos を CP モードまたは AP モードで構成できます。デフォルトでは、Nacos はデフォルトで AP モードを使用します。つまり、nacos.core.cluster.switch パラメータのデフォルト値は nacos です。

AP モードでは、Nacos クラスター内の各ノードは、非同期通信を通じてデータの最終的な一貫性を維持します。このモードでは、ノード間にネットワークの分断がある場合、一部のノードでデータの不整合が発生する可能性がありますが、Nacos はサービスの可用性の確保を優先するため、このモードはインターネットアプリケーションや高データを必要としないその他のシナリオに適しています。一貫性。

CP モードでは、Nacos クラスター内の各ノードは整合性プロトコルを使用してデータの整合性を確保します。このモードでは、ノード間でネットワークの分断が発生した場合、データの整合性を確保するために一部のノードが一時的に無効になることがありますが、これにより一部のサービスが利用できなくなります。したがって、このモードは、金融分野のアプリケーションなど、高いデータ一貫性が必要なシナリオに適しています。

これは Nacos クラスターの AP と CP を指しますか?

はい、ここで言う Nacos のデフォルト AP モードとは、Nacos クラスターの AP モードを指します。デフォルトでは、データの最終的な整合性を維持するために非同期通信が使用されます。ただし、Nacos が CP モードで構成されている場合は、データの整合性を確保するために整合性プロトコルが使用されます。Nacos の AP モードと CP モードは両方とも Nacos クラスター用であり、単一インスタンス用ではありません。Nacos クラスターでは、データの一貫性とクラスターの正しい動作を確保するために、すべてのインスタンスが同じモードを使用する必要があります。

登録センターは CP と AP のどちらであるべきだと思いますか?

ほとんどの場合、登録センターは AP であるべきだと思います。登録センターが CP に属している場合、登録センターにインスタンスを登録するとき、またはインスタンスを削除するときに、登録センタークラスター内のデータが完了するのを待つ必要があることを意味します。ビジネスアプリケーションの規模が増大し、アプリケーションがオンラインとオフラインを頻繁に切り替えると、登録センターへの負荷が比較的高くなり、サービスの検出とサービスの呼び出しの効率に影響を及ぼします。登録センターが AP に属している場合、登録センタークラスターは何が起こってもサービスを提供できます。オフラインサービスノードですが、現在は一般的なマイクロサービスフレームワークまたはコンポーネントがサービスのフォールトトレランスと再試行機能を提供しているため、この問題も回避できます。 AP の場合、登録センターのリソースをあまり消費する必要がなく、リアルタイムでデータの整合性を確保するには、最終的な整合性を確保するだけで十分であるため、登録センターへの負担は少なくなります。 Zookeeper は CP を保証するため、登録センターとして使用されますが、クラスター内のほとんどのノードがハングした場合、それが失われると、たとえ Zookeeper ノードがいくつか残っていたとしても、これらのノードはサービスを提供できなくなるため、これは適切ではありません。、登録センターは、Euraka や Nacos と同様に、AP がより優れていることを保証する必要があります。デフォルトで保証されるのは AP です。

要約: AP はほとんどの場合、厳密なデータ整合性を必要とせず、最終的な整合性 (非同期通信) を確保するだけで済みますが、CP の場合、データの待機には常に時間がかかりました。

Nacos サービスはサービスインスタンスのステータスをどのように判断しますか?

サービスが登録されると、Nacos クライアントは定期的なハートビートを維持して Nacos サーバーに継続的に通知し、サービスが削除されないように常に利用可能であることを示します。デフォルトでは、ハートビートは 5 秒ごとに送信されます。Nacos サーバーは、登録されたサービスインスタンスの健全性をチェックするためにスケジュールされたタスクを開始します。15 秒を超えてクライアントハートビートを受信していないインスタンスの場合、その健全性属性は false に設定されます (クライアントサービスが正常に動作している場合、この属性は見つかりません)インスタンスが 30 秒以上ハートビートを受信しなかった場合、インスタンスは直接削除されます (ハートビートの送信を再開すると、削除されたインスタンスは再登録されます)。

Nacos の負荷分散の最下層はどのように実装されていますか?

Nacos の負荷分散はクライアントを通じて実装されますが、基礎となる実装はリボンを通じて実装されます。具体的には、Nacos Client は OpenFeign とリボンの 2 つのコンポーネントを統合しており、リボンはクライアントの負荷分散を担当し、OpenFeign はリボンに基づいてサービス呼び出しと負荷分散を実装します。

Nacos では、クライアントは Nacos クライアントを使用してサービスインスタンス情報をサブスクライブし、Nacos サーバーからサービスインスタンスの最新のリストを定期的に取得します。クライアントはサービスインスタンスのリストを取得した後、これらのインスタンスをリボンに渡し、リボンは負荷分散戦略に従って要求する最適なサービスインスタンスを選択します。サービスインスタンスが変更されると、Nacos クライアントは適時にリボンに通知し、リボンは動的な負荷分散を実現するためにサービスインスタンスを再選択します。

Nacos は、ラウンドロビン、ランダム、ウェイト、その他の戦略を含む、さまざまな負荷分散戦略をサポートしています。ユーザーは、実際のニーズに応じて、Nacos クライアントでさまざまな負荷分散戦略を構成できます。たとえば、リボンをロードバランサーとして使用する場合、次の構成を構成ファイルに追加できます。

# 使用轮询策略
ribbon.NFLoadBalancerRuleClassName=com.netflix.loadbalancer.RoundRobinRule

上記の構成では、ラウンドロビン戦略を使用するには、ribbon.NFLoadBalancerRuleClassName パラメーターを com.netflix.loadbalancer.RoundRobinRule に設定します。他の負荷分散戦略を使用する場合は、このパラメーターを対応するクラス名に設定するだけです。