ダボの設定プロセス、原則とアーキテクチャのコメント

A.何ダボこと？ダボは何ですか？

ビジネスが急速に成長を続け、インターネットの発展に伴い、急激な変化のための市場の需要は、ウェブサイトでは、分散コンピューティングおよび単一のアプリケーション・アーキテクチャからのモバイルインフラストラクチャのためのサービスアーキテクチャを進化させてきました。分散アーキテクチャの文脈では、ローカルにこの非処理（リモート）内のリソースの再配置が不可避となります。したがって、そのようなので、上のApacheスリフト、ヘッセ、gRPCやなどの枠組みのRPC（リモートプロシージャコール）の数の後半に登場。しかし、RPCフレームワークの促進との深い、より多くのサービス状況の使用の増加にも新しいビジネス要件を生み出しました。

（1）あまりにも多くのサービスURLを管理する方法

（2）消費者がサービスを利用したい、あなたが知っていると、直接サービス側に対処提供するサービスを理解する必要があります。一度変更背景サービスアドレス、彼らはこの関係が非常に高く、メンテナンスの使用を結合し、消費者への通知を必要とします。

（3）質量のサービスは、これらの共通の障害にサービス管理機能を提供するために、どのように、多くのミスを拡張されます。

この文脈では、アリババグループが対処し、RPCフレームワークでこれらの現在の需要とボトルネックを軽減するためのダボ分散フレームワークを開始しました。次のように具体的な施策は以下のとおりです。

（1）サービスの依存関係を管理し、アドレス・サービス・プロバイダー、ソフトのロードバランシングとフェイルオーバーのリストを取得するために、サービスレジストリレジストリを導入することで、消費者側におけるF5ハードウェアロードバランサへの依存を減らします。

（2）消費者が唯一のハードコーディングされたサービスプロバイダーのアドレスの必要性を排除し、サービス自体を気にする必要があるように、レジストリのサブスクリプション解除機構で提供。サービスプロバイダーのレジストリベースのクエリインターフェイス名、IPアドレス、サービスプロバイダは、バックサービスコンシューマへの動的に対処します。

（3）専門の独立したサービス管理センターを、統一されたクラスタノードがオンラインサービスの管理を行う、経営効率を向上させます。

第二ダボ作品（公式ドキュメントを参照してください。https://github.com/apache/dubbo）

1）ノード説明：

プロバイダ：サービスプロバイダが露出
消費者：サービスの消費者のリモートサービスを呼び出す
サービスの登録と発見レジストリは：レジストリ
モニター：通話の監視センターの数と統計サービス時間を呼び出す
コンテナ：コンテナサービスを実行

2）呼び出し元のプロセスと動作原理：

0 サービスコンテナコンテナ起動、ロード、実行するサービスプロバイダ、メイン関数でSpringコンテキストを初期化し、各サービスリリース（サービスプロバイダのXML構成ファイルに応じたプロトコルで指定された各サービスのプロトコルのポート番号は、対応する独自を有しますプロトコル、ポートので、複数のサービスの初期化を完了）、。

1. 起動時に、サービス・プロバイダ・プロバイダに、サービスアドレスレジストリ設定レジストリ接続サービスレジストリによれば、レジストリにレジストリ（例えばZooKeeperの）、登録サービス自体（上記）にサービスプロバイダ情報を公開します。

2. サービスの消費者の消費者のスタートアップ、サービス利用者のXML設定ファイルに基づいて、消費者の参照情報サービスは、レジストリに接続、あなたはサービスレジストリに登録する必要があります。

3. 消費者サービス加入関係に従って、サービスレジストリに、消費者にアドレスリストサービスプロバイダを返し、変更がある場合、レジストリは、消費者に新しいサービスのアドレス情報をプッシュするために長い接続に基づいて行われます（リスナー・プロセスが別のダボですNotifyListrenerが完了するまでに援助を提供し、コンクリートが）プレゼンテーションの次のセクションを参照してくださいすることができます。

4. サービスコンシューマリモートサービスコールは、ルーティングポリシーに応じて、選択したプロバイダのローカルキャッシュ内のアドレスサービスプロバイダのリストから選択呼び出しが失敗した場合、その後、確立したリンクプロトコルタイプ、クロスプロセスは、サービスプロバイダを呼び出しました、その後、別のコールを選択します。

5. 通話の累積数のメモリ内のサービス・プロバイダーと消費者の消費者のプロバイダ、および時間を呼び出し、時間が監視センターモニターに1分ごとに統計データを送りました。

三の.Dubbo基盤となるアーキテクチャの解釈（参考資料：http://dubbo.apache.org/zh-cn/docs/dev/design.html）

（1）二つの層の図から上がってきた、我々は簡単に青色部分の左側は、サービスコンシューマ（ReferenceConfig）で分析することができ、右には、サービスプロバイダは（ServiceConfigのインターフェースを実装する）です。

（2）は、拡張インターフェースが別々のインタフェースは個人によって使用されるサービスに拡張された権利を表す使用する消費者に、左を表します。そして、インターフェイスの途中でサービスプロバイダーと消費者の両方を使用することができます。

（3）作業手順ダボに従って上から下に、合計10層に分割されています。各部分を参照して説明（http://crazyfzw.github.io/2018/06/10/dubbo-architecture/）

界面層のサービス（サービス）は、この層は、サービスプロバイダとサービス・コンシューマ・インタフェースの設計および対応するサービスの実装によれば、実際のビジネス・ロジックに関連しています。
層構成（コンフィグ）：ServiceConfig ReferenceConfig中心への外部構成インターフェースと直接新しいコンフィギュレーション・クラスとすることができ、構成がスプリングを解析してクラスを生成するように構成することができます。
サービスプロキシ層（プロキシ）：透明なプロキシサービスインターフェース、中央ServiceProxy拡張インターフェースProxyFactoryに、サービス顧客端末とサーバスケルトンスタブを生成します。
サービス登録層（レジストリ）：登録と発見のパッケージサービスのアドレスは、中央のURLとして機能するように、拡張されたインタフェースはRegistryFactory、レジストリおよびこのRegistryServiceです。これは、サービスセンター、サービスプロバイダーに直接さらさサービスを登録することはできません。
集群层（Cluster）：封装多个提供者的路由及负载均衡，并桥接注册中心，以Invoker为中心，扩展接口为 Cluster、Directory、Router 和 LoadBalance。将多个服务提供方组合为一个服务提供方，实现对服务消费方来透明，只需要与一个服务提供方进行交互。
监控层（Monitor）：RPC 调用次数和调用时间监控，以 Statistics 为中心，扩展接口为 MonitorFactory、Monitor 和 MonitorService。
远程调用层（Protocol）：封将 RPC 调用，以 Invocation 和 Result 为中心，扩展接口为 Protocol、Invoker 和 Exporter。Protocol 是服务域，它是 Invoker 暴露和引用的主功能入口，它负责 Invoker 的生命周期管理。Invoker 是实体域，它是 Dubbo 的核心模型，其它模型都向它靠扰，或转换成它，它代表一个可执行体，可向它发起 invoke 调用，它有可能是一个本地的实现，也可能是一个远程的实现，也可能一个集群实现。
信息交换层（Exchange）：封装请求响应模式，同步转异步，以 Request 和 Response 为中心，扩展接口为 Exchanger、ExchangeChannel、ExchangeClient 和 ExchangeServer。
网络传输层（Transport）：抽象 mina 和 netty 为统一接口，以 Message 为中心，扩展接口为 Channel、Transporter、Client、Server 和 Codec。
数据序列化层（Serialize）：可复用的一些工具，扩展接口为 Serialization、 ObjectInput、ObjectOutput和ThreadPool。

大致的工作流程是：

　　1.读取配置文件，生成代理对象

　　2.代理对象负责将其注册到注册中心进行备份

　　3.下层monitor层对双方进行业务监控。

在 RPC 中，Protocol 是核心层，也就是只要有 Protocol + Invoker + Exporter 就可以完成非透明的 RPC 调用，然后在 Invoker 的主过程上 Filter 拦截点。

需要注意的是：为了底层可以使用NIO来传输数据，所有的公共api接口都应该实现Serializable.

四.Dubbo的缺点

因为是阿里出品，所以其目前只支持Java语言，对语言的支持性不是很好。