dubbo-基礎原語と配置解読
11947 ワード
本文は主にdubboに関する基礎知識を紹介し、プロファイルの解読を紹介し、dubboのより良い理解、学習を助ける.
Overview
Architecture Provider:サービスを暴露するサービスプロバイダ. Consumer:リモート・サービスを呼び出すサービス・コンシューマ. Registry:サービス登録と発見の登録センター. Monitor:サービスのコールセカンダリとコール時間を統計するモニタセンター. Container:サービス実行コンテナ.
Relations
0.サービスコンテナは、サービスプロバイダの起動、ロード、実行を担当します.1.サービスプロバイダは起動時に、登録センターに自分が提供したサービスを登録する.2.サービス消費者は起動時に、登録センターに自分の必要なサービスを購読する.3.登録センターはサービスプロバイダのアドレスリストを消費者に返し、変更があれば、登録センターは長接続に基づいて変更データを消費者にプッシュする.4.サービス消費者は、プロバイダアドレスリストから、ソフトロード等化アルゴリズムに基づいて、1台のプロバイダを選択して呼び出し、呼び出しに失敗した場合、もう1台の呼び出しを選択する.5.サービス消費者とプロバイダは、メモリに呼び出し回数と呼び出し時間を累計し、毎分統計データを監視センタに送信する.6.登録センター、サービス提供者、サービス消費者の三者の間は長い接続であり、監視センターを除く.登録センターは、サービスプロバイダの存在を長い接続で感知する、サービスプロバイダがダウンタイムし、登録センターは直ちにイベントをプッシュして消費者8に通知する.登録センターとモニタセンターはすべてダウンタイムし、実行中のプロバイダと消費者に影響を与えず、消費者はローカルでプロバイダリストをキャッシュします.
Invoker Procedures !important
Configuration Prorioty
Service
メソッドレベルが優先され、インタフェースレベルが次に、グローバル構成が再び行われます.レベルが同じであれば、消費者が優先し、提供者がそれに次ぐ.
Basic
JVM起動-Dパラメータを優先することで、起動時にプロトコルのポートを変更するなど、導入と起動時にパラメータの書き換えを行うことができます.XMLに次いで、XMLに構成があるとdubbo.propertiesの対応する構成項目が無効です.Properties最後に、デフォルト値に相当し、XMLのみが構成されていない場合、dubbo.propertiesの対応する構成項目は有効になります.通常、アプリケーション名などの共通構成を共有するために使用されます.
Features
Check on Start
Fault Tolerance
importantはデフォルトでFailoverを使用していますが、私たちのシステムはこの方法を使用しています.実際には最大の再試行回数を2回制限する必要があります(一般的に1台が失敗するため、他のものも失敗します).
Load Balancing
importantソフト負荷等化アルゴリズムに基づく
Thread Model
イベント処理スレッドの説明
Dispatcher #all default
ThreadPool #fixed default
E.G
パラメータはiothread epollモデルを説明するのでCPUコア数+1
threads intオプション100パフォーマンスチューニングサービススレッドプールサイズ(固定サイズ)2.0.5以上iothreads intオプションcpu個数+1パフォーマンスチューニングioスレッドプールサイズ(固定サイズ)2.0.5以上
Multi-protocol
異なるサービスは、大データ用短接続プロトコル、小データ大同時用長接続プロトコルなど、異なるプロトコルを性能的に適用して伝送される.我々のシステムはdubboプロトコルを用い,長接続プロトコル(伝送サイズに制限がある)に基づいている.大きなファイルであればRMIが使えます
Multi-Registry,Multi-Group,Multi-Version,Group-Aggregation
マニュアルを見ていますが、Group-Aggregationは面白いです.
JSR303 based validation
E.G
Cache
結果キャッシュは、人気データへのアクセス速度を速めるために使用され、Dubboは宣言キャッシュを提供し、ユーザーがキャッシュするワークロードを削減します.
汎話引用、汎話実現
POJOの代わりにMapを使用
エコーテスト
すべてのサービスは自動的にEchoServiceインタフェースを実現し、任意のサービス参照を強制的にEchoServiceに変換するだけで使用できます.
サービスコンテキストと暗黙的なパラメータ、AppContextはこの実装に基づいて
スキーマ＃スキーマ＃
すべての構成情報はURLのパラメータに変換され、文字列プロトコルでHTTP HEADER転送と類似しています.
RpcContextはThreadLocalの一時状態レコーダであり、RPC要求を受信したり、RPC要求を開始したりすると、RpcContextの状態が変化する.
非同期呼び出し、ローカル呼び出しbased on injvm
フローチャート
パラメータコールバック、ローカルルート
パラメータコールバック方式は、ローカルcallbackまたはlistenerを呼び出すのと同じで、Springのプロファイルでどのパラメータがcallbackタイプであるかを宣言するだけでよい.Dubboは、長接続に基づいて逆プロキシを生成し、サーバ側からクライアントロジックを呼び出すことができる.
コードを渡すのではなく
どちらかというと、応用するシーンは思いもよらなかった
ちえんばくろ
露出時間について
!importantはSpringが解析されると、サービスが外部に露出し、Springは他のBeanを初期化します.
Shutdown
サービスプロバイダが停止した場合、新しいリクエストを受信しないとマークし、新しいリクエストが来たときに直接エラーを報告し、クライアントに他のマシンを再試行させる.次に、スレッドプール内のスレッドが実行されているかどうかを検出し、タイムアウトしない限り、すべてのスレッドの実行が完了するまで待機します.
サービス消費者が停止すると、新しい呼び出し要求は開始されず、すべての新しい呼び出しはクライアントでエラーが発生します.その後、リクエストの有無を検出した応答はまだ返されず、タイムアウトしない限り強制的に閉じられます.
DubboはJDKのShutdownHookでエレガントダウンを完了しているので、ユーザーが「kill-9 PID」などの強制クローズコマンドを使用すると、エレガントダウンは実行されず、「kill PID」を通過した場合にのみ実行されます.
私たちのシステムではKill-9で実行されています
Container
サービスコンテナはstandaloneの起動プログラムであり、バックグラウンドサービスはTomcatやJBossなどのWebコンテナの機能を必要としないため、無理にWebコンテナでサービスプロバイダをロードし、複雑さを増やし、リソースを浪費する.サービスコンテナは単純なMainメソッドにすぎず,サービスを暴露するための単純なSpringコンテナをロードする
Overview
Architecture
Relations
0.サービスコンテナは、サービスプロバイダの起動、ロード、実行を担当します.1.サービスプロバイダは起動時に、登録センターに自分が提供したサービスを登録する.2.サービス消費者は起動時に、登録センターに自分の必要なサービスを購読する.3.登録センターはサービスプロバイダのアドレスリストを消費者に返し、変更があれば、登録センターは長接続に基づいて変更データを消費者にプッシュする.4.サービス消費者は、プロバイダアドレスリストから、ソフトロード等化アルゴリズムに基づいて、1台のプロバイダを選択して呼び出し、呼び出しに失敗した場合、もう1台の呼び出しを選択する.5.サービス消費者とプロバイダは、メモリに呼び出し回数と呼び出し時間を累計し、毎分統計データを監視センタに送信する.6.登録センター、サービス提供者、サービス消費者の三者の間は長い接続であり、監視センターを除く.登録センターは、サービスプロバイダの存在を長い接続で感知する、サービスプロバイダがダウンタイムし、登録センターは直ちにイベントをプッシュして消費者8に通知する.登録センターとモニタセンターはすべてダウンタイムし、実行中のプロバイダと消費者に影響を与えず、消費者はローカルでプロバイダリストをキャッシュします.
Invoker Procedures !important
0. Invoker Provider Service ，Invoker Provider Service 。
1. Directory Invoker， List， List ， ， 。
2. Cluster Directory Invoker Invoker， ， ， ， 。
3. Router Invoker ， ， 。
4. LoadBalance Invoker ， ， ， 。
Configuration Prorioty
Service
メソッドレベルが優先され、インタフェースレベルが次に、グローバル構成が再び行われます.レベルが同じであれば、消費者が優先し、提供者がそれに次ぐ.
Basic
JVM起動-Dパラメータを優先することで、起動時にプロトコルのポートを変更するなど、導入と起動時にパラメータの書き換えを行うことができます.XMLに次いで、XMLに構成があるとdubbo.propertiesの対応する構成項目が無効です.Properties最後に、デフォルト値に相当し、XMLのみが構成されていない場合、dubbo.propertiesの対応する構成項目は有効になります.通常、アプリケーション名などの共通構成を共有するために使用されます.
Features
Check on Start
Dubbo ， ， Spring ， ， ， check=true。
# Spring ， API ， check， ，
# ， null ， check=false， ， ， 。
check="false" ， ， ， ， ， 。
Fault Tolerance
Failover Cluster # DEFAULT
， ， 。( )
， 。
retries="2" ( )。
Failfast Cluster
， ， 。
， 。
Failsafe Cluster
， ， 。
。
Failback Cluster
， ， 。
。
Forking Cluster
， 。
， 。
forks="2" 。
Broadcast Cluster
， ， 。(2.1.0 )
。
importantはデフォルトでFailoverを使用していますが、私たちのシステムはこの方法を使用しています.実際には最大の再試行回数を2回制限する必要があります(一般的に1台が失敗するため、他のものも失敗します).
#set max retry time 2
"2" />
OR:
"2" />
OR：
"findFoo" retries="2" />
Load Balancing
importantソフト負荷等化アルゴリズムに基づく
Random LoadBalance
， 。
， ， ， 。
RoundRobin LoadBalance
， 。
， ： ， ， ， ， 。
LeastActive LoadBalance
， ， 。
， 。
ConsistentHash LoadBalance
Hash， 。
， ， ， ， 。
：http://en.wikipedia.org/wiki/Consistent_hashing。
Hash， ， "hash.arguments" value="0,1" />
160 ， ， "hash.nodes" value="320" /> Thread Model
イベント処理スレッドの説明
0. ， IO ， ， IO ， 。
1. ， IO ， ， ， IO ， 。
2. IO ， IO ， ， “ ” ， 。
Dispatcher #all default
0. all ， ， ， ， ， 。
1. direct ， IO 。
2. message ， ， ， IO 。
3. execution ， ， ， ， IO 。
4. connection IO ， ， ， 。
ThreadPool #fixed default
0. fixed ， ， ， 。( )
1. cached ， ， 。
2. limited ， 。( )。
E.G
"dubbo" dispatcher="all" threadpool="fixed" threads="100" />
パラメータはiothread epollモデルを説明するのでCPUコア数+1
threads intオプション100パフォーマンスチューニングサービススレッドプールサイズ(固定サイズ)2.0.5以上iothreads intオプションcpu個数+1パフォーマンスチューニングioスレッドプールサイズ(固定サイズ)2.0.5以上
Multi-protocol
異なるサービスは、大データ用短接続プロトコル、小データ大同時用長接続プロトコルなど、異なるプロトコルを性能的に適用して伝送される.我々のシステムはdubboプロトコルを用い,長接続プロトコル(伝送サイズに制限がある)に基づいている.大きなファイルであればRMIが使えます
Multi-Registry,Multi-Group,Multi-Version,Group-Aggregation
マニュアルを見ていますが、Group-Aggregationは面白いです.
interface="com.xxx.MenuService" group="*">
"getMenuItems" merger="mymerge" /> # ：( ， ， ) interface="com.xxx.MenuService" group="*"> "getMenuItems" merger=".addAll" /> JSR303 based validation
#interface
javax.validation
validation-api
1.0.0.GA
#implement
org.hibernate
hibernate-validator
4.2.0.Final
E.G
"validationService" interface="com.alibaba.dubbo.examples.validation.api.ValidationService" validation="true" /> OR: interface="com.alibaba.dubbo.examples.validation.api.ValidationService" ref="validationService" validation="true" /> Cache
結果キャッシュは、人気データへのアクセス速度を速めるために使用され、Dubboは宣言キャッシュを提供し、ユーザーがキャッシュするワークロードを削減します.
interface="com.foo.BarService">
"findBar" cache="lru" />
汎話引用、汎話実現
POJOの代わりにMapを使用
エコーテスト
すべてのサービスは自動的にEchoServiceインタフェースを実現し、任意のサービス参照を強制的にEchoServiceに変換するだけで使用できます.
MemberService memberService = ctx.getBean("memberService"); //
EchoService echoService = (EchoService) memberService; // EchoService
String status = echoService.$echo("OK"); // サービスコンテキストと暗黙的なパラメータ、AppContextはこの実装に基づいて
スキーマ＃スキーマ＃
すべての構成情報はURLのパラメータに変換され、文字列プロトコルでHTTP HEADER転送と類似しています.
RpcContextはThreadLocalの一時状態レコーダであり、RPC要求を受信したり、RPC要求を開始したりすると、RpcContextの状態が変化する.
RpcContext.getContext()
非同期呼び出し、ローカル呼び出しbased on injvm
フローチャート
パラメータコールバック、ローカルルート
パラメータコールバック方式は、ローカルcallbackまたはlistenerを呼び出すのと同じで、Springのプロファイルでどのパラメータがcallbackタイプであるかを宣言するだけでよい.Dubboは、長接続に基づいて逆プロキシを生成し、サーバ側からクライアントロジックを呼び出すことができる.
コードを渡すのではなく
どちらかというと、応用するシーンは思いもよらなかった
service:
"callbackService" class="com.callback.impl.CallbackServiceImpl" />
interface="com.callback.CallbackService" ref="callbackService" connections="1" callbacks="1000"> "addListener"> "1" callback="true" /> consumer: "callbackService" interface="com.callback.CallbackService" /> callbackService.addListener("http://10.20.160.198/wiki/display/dubbo/foo.bar", new CallbackListener(){
public void changed(String msg) { System.out.println("callback1:" + msg); } }); ちえんばくろ
露出時間について
!importantはSpringが解析されると、サービスが外部に露出し、Springは他のBeanを初期化します.
1. applicationContext.getBean() ， IoC Spring Bean。
2. getBean()， Dubbo Spring 。
3. ， ， Dubbo Spring ， 。
4. getBean()， Spring ， Dubbo Spring 。
Shutdown
サービスプロバイダが停止した場合、新しいリクエストを受信しないとマークし、新しいリクエストが来たときに直接エラーを報告し、クライアントに他のマシンを再試行させる.次に、スレッドプール内のスレッドが実行されているかどうかを検出し、タイムアウトしない限り、すべてのスレッドの実行が完了するまで待機します.
サービス消費者が停止すると、新しい呼び出し要求は開始されず、すべての新しい呼び出しはクライアントでエラーが発生します.その後、リクエストの有無を検出した応答はまだ返されず、タイムアウトしない限り強制的に閉じられます.
DubboはJDKのShutdownHookでエレガントダウンを完了しているので、ユーザーが「kill-9 PID」などの強制クローズコマンドを使用すると、エレガントダウンは実行されず、「kill PID」を通過した場合にのみ実行されます.
私たちのシステムではKill-9で実行されています
Container
サービスコンテナはstandaloneの起動プログラムであり、バックグラウンドサービスはTomcatやJBossなどのWebコンテナの機能を必要としないため、無理にWebコンテナでサービスプロバイダをロードし、複雑さを増やし、リソースを浪費する.サービスコンテナは単純なMainメソッドにすぎず,サービスを暴露するための単純なSpringコンテナをロードする
Spring Container
META-INF/spring Spring 。
：( java -D dubbo.properties )
dubbo.spring.config=classpath*:META-INF/spring/*.xml ---- spring
Jetty Container
Jetty， 。
：( java -D dubbo.properties )
dubbo.jetty.port=8080 ---- jetty
dubbo.jetty.directory=/foo/bar ---- jetty ，
dubbo.jetty.page=log,status,system ---- ，
Log4j Container
log4j ， ， 。
：( java -D dubbo.properties )
dubbo.log4j.file=/foo/bar.log ----
dubbo.log4j.level=WARN ----
dubbo.log4j.subdirectory=20880 ---- ， ，