分散型アーキテクチャ：原理、設計、実際の戦闘現在、会社は毎月支払う必要があり、請求書は前月のアカウントを毎月明確に計算することであるため、エラーに対する許容度はなく、誰も間違っています。、間違った顧客はあなたを見つけるでしょう、部分的な正確さ。フォーナインとファイブナインは、後で設計するためのものではなく、開発の最初に検討するためのものです。
分散サービスの開発履歴
- J2EEアーキテクチャ
一般にJEEとして知られています。5年以上の実務経験を持つベテランにとって、彼らはこの用語を聞いたはずです。基本的に3層に分かれています。
- ウェブコンテナ
- EJBコンテナ
- データベースとデータアクセスのためのORM
当時、コンテナ間に物理的な分離はなく、すべて同じjvmにデプロイされていました。そのため、時間の経過とともに、相互の結合と相互依存により、ビジネスは無尽蔵になり、新しいビジネスを追加および追加するために追加および変更すると、非常に複雑になり、サービスが利用できなくなることがよくあります。この時代にはレベルがありますが、レベルの前に物理的な隔離はありません。いくつかの問題をもたらします。
- SSHアーキテクチャ
オープンソースフレームワークSSH = struts + spring + hibernate、実際には基本的にJEEアーキテクチャに似ており、コンポーネントを3つのレイヤーに分割します。
- struts MVCUIコンポーネント
- ビジネスロジックを実装するSpringビジネスコンポーネント
- データベースに接続されたORMオブジェクト管理マッピングレイヤー
SSHは当時非常に人気がありました。当時、システムは従来の業界や製造業向けに構築されており、インターネット業界のSSHアーキテクチャは機能していなかったためです。
- Webサービスアーキテクチャ
インターネット業界はサービスを提供する傾向があります。最も人気のあるマイクロサービスはサービスから始まり、サービスは最初にWebサービスに組み込まれました。WebサービスはIBMが主導する主要企業によって設定された標準です。Webサービス機能の開発後、それらはWebサービスに展開されません。同じプラットフォーム。同じJVM上のマシンは、異なるサービスに分割されます。たとえば、図のWebサービス1、Webサービス2、およびWebサービス3には、独自の役割と機能があります。サービスとサービスは、以前はリモートToを介して呼び出されていました。相互の実現と通信を実現し、リモートコールは確立された標準に従います。当時の標準はSOAPプロトコルでした。このプロトコルは、xmlを送信するためのhttpプロトコルに基づいていました。これらのサービスで。サービス検出メカニズムが必要です。これは、Webサービスディレクトリを介して実現されます。外の世界にサービスを提供するすべてのサービスは、Webサービスに登録する必要があります。サービスUDDIを検索し、サービスWSDLを検索します。この時代のサービスの主な特徴は、職務の分離、サービス展開の分離、および契約へのサービス呼び出しのコンプライアンスです。Webサービスで定義されているプロトコルは非常に重いです。まず、xmlはシリアル化され、xmlには冗長タグがあり、サービスのパフォーマンスを向上させることはできません。Webサービスは通信ベースのサービスに登録し、通信ベースの登録サービスは高可用性を確保する必要があります。インターネットでの可用性が高くない場合、サービスは最適化されていません。
- ESBアーキテクチャ
エンタープライズサービスバス、エンタープライズサービスバスに焦点を当てています。上は提供されるサービスで、下はデータベースデータソース、メッセージキュー、ビッグデータ、ERPです。すべてのサービスとリソースがESBに入る限り、それらは特定の機能を完了するように調整されます。この期間中に、ESB機能は分割され、独自の責任もありました。これらはすべて、異なる物理マシン、異なるJVMで分割されました。主に、プラグイン可能なサービスの高速追加と削除、およびリソースの高速追加に反映されます。
- マイクロサービスアーキテクチャ
最も人気のあるアーキテクチャは、従来のアーキテクチャと一致しており、矛盾していません。階層化の概念を採用し、上位層のサービスは下位層のサービスに依存します。基本的に、第1層はビジネスサービス1、第2層はビジネスサービス2、3、4の2つの層があります。上層と次の層は依存していますが、循環的に依存していません。各サービスは独自のデータベースを使用します。実際、データベースキャッシュとメッセージキューは自律的です。これにより、マイクロサービスは自身を管理する権限を持つことができます。マイクロサービスは、ニーズをすばやく消化し、オンラインにすばやく接続して、開発と運用を改善できます。次元の効率性、マイクロサービスは以前はリモートサービス呼び出しを通じて実現されていました。リモートサービス呼び出しの場合、restfulまたはrpcのどちらを使用するかについての特定の要件はありません。サービス間に契約が必要です。契約は、サービスプロデューサーによって提案されるか、サービスコンシューマーによって提案されるサービスプロデューサー契約であるか、複数の場合があります。サービス。消費者はサービスのプロデューサーに一緒にリクエストを依頼し、サービスのプロデューサーは通信に問題がないことを確認するための公的契約を提供します。例：需要が発生した場合、最初にサービスを分割し、それを異なるマイクロサービスに分割します。マイクロサービスは良好な通信契約を結んでおり、外部機能に関係なく、需要はサービスで消化されます。オンラインに接続して市場に対応することも非常に機敏です。マイクロサービスの各ノードの分割は比較的単一であり、それらはすべて比較的詳細です。責任が単一になった後、専門家は専門的なことを行い、間違いを犯しにくくなり、システムの使いやすさが向上します。
- マイクロサービスのチーム管理
チームは実際には自律的です。マイクロサービスチームには、製品、運用、テスト、および開発が含まれる場合があります。システムがチームに割り当てられている場合、チーム内の開発は非常に迅速に通信でき、開発は迅速にオンラインになります。チーム間の通信やチーム間の調整は必要ありません。元のSSHを振り返ると、会社はUIグループに分かれており、開発チーム、テストチーム、DBチームが通信し、マイクロサービスではないチームは通信効率を低下させます。つまり、これがマイクロサービスの提唱者であるアジャイルであり、専門家は専門的なことを行います。
- 分散サービスアーキテクチャの本質
アジャイルオンラインとマイクロサービスの下での自律性は、利用できない要因を効果的に減らします。サービスとマイクロサービスはどちらも分割統治の考え方を使用しています。分散サービスと分散システムアーキテクチャでは、パフォーマンスの向上、スループットの向上、俊敏性の向上のいずれであっても。
- マイクロサービスアーキテクチャの問題点
- 一貫性
強い一貫性と弱い一貫性
- ハイパフォーマンス
容量評価とパフォーマンステスト
- 高可用性
49秒と59秒
- スケーラブル
変更可能で反復的な新機能、プラグ可能
- 調整可能
アプリケーション層とリソース層、ハードウェアへの投資の増加に伴い、パフォーマンスと容量はそれに応じて増加します
- 安全性
覗き見防止、漏洩防止、否認防止、改ざん防止、中間者攻撃防止
分散された一貫性を確保するための最良のソリューション
周王朝の間、分割統治し、後に周王に耳を傾けなかったため、矛盾が生じました。不整合によって引き起こされる問題点は大きいです。不整合を解決する方法。オンラインでのピットと要約された経験の共有。
- 一貫性の原則
基本的に、次の3つのタイプ、それらが何であるか、およびアプリケーションのシナリオを理解する必要があります。
ACID、データベース理論では、ACIDが強力な一貫性であることを私たちは皆学びました。4つの名詞は、すべてが成功するかすべて失敗するかのいずれかで、トランザクションを分割できないことを表します。従来のデータベースにはモノリシックアプリケーションがあり、モノリシックアプリケーション、特にリレーショナルデータベースは強力な一貫性を維持する必要があります。インターネットの高い同時実行性については躊躇してください。ユーザー数は数千、数万、数億と非常に多く、単一のサービスアーキテクチャと単一のデータベースでこれほど多くのユーザーをサポートすることは困難です。したがって、ユーザーを分割して征服する必要があります。インターネット、分離、分割されたシート。問題は、ネットワークに問題があるときにこれらのアプリケーションが正常に動作できるかどうかです。これにより、CAPの原則が導入されます。
CAPはそれらの間でネットワーク通信を行う必要があり、パーティションのフォールトトレランスが必要です。つまり、ノードネットワークが正常に通信できない場合です。ネットワークがダウンしているか断続的に発生している場合、相互に作業が続行されます。Pは絶対に必要です。原則として、3つがそのうちの2つしか選択できず、Pがすでに必要な場合は、CとAのどちらかを選択する必要があります。例：ネットワーク上にデータがあり、データをコピーして完成させます。1つはマスターデータ、もう1つはスレーブデータです。データのコピーをマスターデータに保存するときは、スレーブデータにもコピーを保存する必要があります。スレーブに問題がある場合は、続行するかどうかまたはマスターに戻る、これは一貫性と使いやすさの解釈です。マスターとスレーブの整合性が必要で、保存後にのみマスターとスレーブを返すことができる場合、整合性は保証され、可用性は良くありません。ネットワークに問題がある場合は、整合性を待ってから戻ります。限られた時間内にクライアントに返されないリクエストは可用性が低いため、一貫性と可用性は相互に排他的です。クライアントにすぐに返されると、可用性を維持するために一貫性が犠牲になる可能性があります。結論は、フォールトトレランスに基づいて、可用性と一貫性は相互に排他的であるということです。両方を持つことはできません。
BASEは基本的に利用可能で、中央がソフトな状態で、最終的には一貫性が保たれます。基本的な可用性が条件であり、一貫性が目標です。ソフト状態は事前にBASEメソッドであるため、1つのことを行う必要があります。目標を達成するプロセスには2つまたは3つの段階が必要です。1つの段階を終えた後、状態情報を記録し、次に2番目の段階を行います。問題のある場所から開始できます。場所は問題が発生した場所に復元されます。インターネット上の多くの同時実行性の高いプロジェクトは分散トランザクションを使用し、最終的な一貫性を実現するために割引されます。CAPは、BASEの原則を使用して、3つが同時に存在することは不可能であることを制限します。
- 適合協定
2段階のコーディネーター
三相コーディネーター
TCC（お試しください）
- 最終的な一貫性
クエリモード
補正モード
非同期保証モード
通常の校正モード
信頼できるメッセージモード
- サービスインタラクションモード
同期モード
非同期モード
メッセージモード
- 同期と非同期の選択
同期操作ではなく非同期操作を使用してみてください
同期によって解決できる問題、非同期を導入しない
- タイムアウトモード
2つの状態のインターフェースの同期がタイムアウトしました
2つの状態を同期するための内部タイムアウト
3つの状態を同期するための内部タイムアウト
非同期呼び出しタイムアウト
メッセージキュー送信タイムアウト
メッセージ一致受信タイムアウト
- 補償ゲーム
サービス1はサービス2を呼び出します。サービス2がサービス1に応答し、メッセージを受信したことをサービス1に通知すると、サービス1のタスクは終了します。サービス2が失敗した場合、サービス2は再試行または補償を担当する必要があります。この場合、通常、サービス2は最初にメッセージを永続化し、次にサービス1に受信が成功したことを通知し、サービス2は永続的なメッセージの処理を開始して、サービスプロセスが愚かに失われる状況を回避します。
サービス1がサービス2を呼び出します。サービス2が明確な受信応答を返さない場合、サービス2がメッセージを受信したことを明確に示していることを認識して、サービス1は再試行を続行する必要があります。この場合、メッセージの重複が発生しやすくなります。したがって、サービス2では通常、フィルターの重量またはべき等性が保証されます。
- キャッシュで使用される整合性モード
キャッシュは、一貫性を犠牲にして高速化に使用され、高いパフォーマンスを実現します。これは、特別なシナリオにのみ適しています。
データベースとキャッシュの間の強力な一貫性を維持することは誤った提案です
パフォーマンス要件がそれほど高くない場合は、ローカルキャッシュの代わりに分散キャッシュを使用してみてください。ローカルキャッシュは、読み取るときにオンになる場合があります。実際、他の人が別のときに読み取っています。考えてみると怖いです。それについて。
キャッシュの種類の場合は、完全である必要があります。キャッシュされたデータの一部が有効で、一部が無効である場合、データの一部をキャッシュに入れるよりも、キャッシュの種類をあきらめたいと思います。
通常の状況では、読み取りの順序を最初にキャッシュし、次にデータベースをキャッシュし、書き込みの順序を最初にデータベース、次にキャッシュする必要があります。
- 移行スイッチの設計パターン
新旧のシステムの移行。
統合構成スイッチは使用しないでください。スイッチは特定のビジネスで定義されています。1つのシステムでフィルターの重みを実行する方が、複数のシステムでフィルターの重みを実行するよりも簡単です。
ノードに依存しないスイッチは使用しないでください
移行スイッチは注文スイッチを使用する必要があります
スイッチは権限によって制御される必要があります。スイッチの重要性は、特定の経験を持つ人によって操作されます。
スイッチはオンとオフを切り替えることができる必要があります
移行スイッチは大小両方である必要があります
PS：分散アーキテクチャを理解することは、自分にとって一種の精神的な改善です。コードの入力は見下ろしているだけなので、楽しみにすることをお勧めします。建築の道をたどるのは簡単ではありません。前方の道を突破するには、より多くの接触、複数の旅行、複数の散歩が必要です。