序文
もともと+予想外の発生が土曜日の台風と一致知っている車で旅行し、湖州市近くの観光スポットが全て閉鎖、唯一の最後の金曜日、土曜日ステッピング台風の後に終了する金曜日の三連休を計画上海のエッジは逃げました。そんなに難しい週末を飛ぶ、この時間は、何かの隠れ家のトピック、マイクロアーキテクチャ設計は、まずサービスについて話、第二、ユーレカとマイクロサービスにおける類似点と相違点についてRPCフレームワークダボの話が広く使われているサービスのガバナンスについて話をします。
まず、マイクロアーキテクチャ設計サービス
その理由は主に二つの新しいマイクロ・サービス・プロジェクトの最近の接触を実現、この話題について話をしたい - 二人の手によって二つのプロジェクトのアーキテクチャ設計を、同じデザインコンセプトを使用するための任意の意図せずに、プロジェクト構造は非常に似ています。思想はその後、プロジェクトに暴露され、会社の構造設計に取り組んでわずかなアイデアを出しバースト。議題へのマイクロアーキテクチャ設計サービス、非常に騒々しいQuchongバイアスなので、それを宣言する必要性と、紙が言った、ソフトウェア開発とアーキテクチャ設計不毛現在描か愚見でブロガーの浅い経験をベースとしている、だけで今避けることができない確証バイアスタイプの多くを含まなければならない言葉の一つが、。この記事の目的は、あなたとは何も自分のアイデアを共有しないことです。
自宅に近い、現在のスプレッドより広くし、デザインコンセプトのより多くの言及は、2004年にエリック・エヴァンスは、ドメイン駆動設計、すなわち、ドメイン駆動設計を上げDDDと呼ばれています。コンセプトはマイクロサービスはかなりの共生依存性を持っているということができるため、近年までは、マイクロサービスの台頭は、DDDのデザインコンセプトは人気がありました。デザインコンセプトは、最初のフィールドを決定した後、これに基づいて設計し、開発することです。そして、どのようにフィールドを理解するには？一般的な方法は、個別のサービスモジュールは、サービスエリアの範囲の境界を決定することが理解されるべきです。一例として、プロジェクトへの電力供給業者は、ショッピングカートをフィールドとして見ることができ、発注は、フィールド、フィールドとしてモール、そしてときのように、あまりにも大規模な開発時間の面積、およびは細かいに分割します視野点、原理はデカップリングの最大の程度となるよう、これらの領域のそれぞれは、単一のことをすることを確認することです。
一例として、実際のプロジェクトは、プロジェクトは、三つのモジュール、すなわち、マイクロ起動クラスのサービスモジュール、コアビジネスモジュール、共通のミドルウェア技術のモジュールに分割されます。モール、ショッピングカート、受注、および支払い：各モジュールは、二つのモジュールの数を持っていると、各モジュールは、サービスモジュールでこのような二つのモジュールとして、2つのフィールドが、あるあります。技術的なモジュール：Redisのモジュール、闊歩モジュール、データベースモジュール、およびので、メッセージキューモジュール。ビジネス・モジュールおよび技術モジュールは、2つのモジュールは、サービスが使用されているマイクロモジュールに必要かを決定し、クラスモジュールを起動することによって、統合を統一されています。この構成は、既存のモジュールに最大の柔軟性のために組み合わせることができます。
いくつかの少し高度な技術スタッフは、現在のシーンの設計のための唯一のより適切な完璧なアーキテクチャの設計、存在しないことを知っています。良いアーキテクチャは、一度、すべて将来の問題のために解決することはできませんが、間違いなく問題を解決するにはあなたに大きな利便性を提供することができます。
二、ユーレカとダボ
今オンライン、より多くのは、ダボと春クラウドと比較したマイクロモジュールの機能やサービスからの類似点と相違点を比較することです。しかし、ダボ測位サービスのガバナンスがより行うことです、少しバイアスされているのではなく、マイクロサービスアーキテクチャソリューションのパッケージを提供し、それはこの関数の結果よりであるこの比較は春の雲はその機能を持っているが、これはありませんダボということではありません。今日は、一般的に使用されるユーレカスプリング・クラウドとダボ比較して、サービスガバナンスの観点から、両者の間の類似点と相違点を見てください。
両方が分散フレームワークは、整合性のみのC、2 Aの可用性、3のPパーティションネットワークフォールトトレランスを満たすことができる、CAP分散アーキテクチャ論に言及しなければならないと言うことは、それは不可能です3両方の中に。
ZKはCPを満たすためのフレームワークである一方、この観点から、ダボは、ZKのための選択のレジストリを推奨。ユーレカは、APに、そのアーキテクチャの、より焦点を絞りました。
フォールトトレランスのために、ダボ自体は、そのようなフェイルオーバーフェイルオーバー、迅速な故障フェイルファーストとして、エラー処理の数を実装等のフェールセーフフェールセーフ、ユーレカは、フォールトトレランスの実装でヒューズHytrix春の雲によるものです。
負荷分散のために、ダボ自体ランダム重みとして負荷分散方法、ハッシュ一貫性の多様性を達成するために、エウレカはまた、リボンを介するなど、この機能を入れているが、負荷分散を実現しています。
サービスの登録と発見、ダボ自体はNettyClientや他のコミュニケーションツールをカプセル化し、ユーレカは、アプリケーション層通信のHttpClientに基づいています。
これは、フレーム自体を用いたマイクロサービスは、どのモジュールのどのような組み合わせでモジュールのような、別のモジュールに分割アートデザイン、比較的独立したスプリット異なる機能である、見ることができます。この観点から、より多くのダボはユーレカと他のコンポーネントと組み合わせて、全体的な機能はシンプル、軽量かつよりある非分割を提供することです。
追伸
実際には、あなたがして、パフォーマンスを生成し、マイクロサービスのDDDの概念のこの感覚は、人間社会の分裂と比較することができる、さらに拡張することができます。フィールドの代わりに作業のすべての種類は、異なる内部領域は分業を通じて、その機能を行うことができます大幅に全体として、フィールドを分割することにより、社会の生産性を高めることができるだけでなく、フレームワーク、組織の作業効率を向上させることができます。すべてすべての連絡先、私は心からいじめていない古代人を持っています。