私たちは紛争の潜在的に大きい事前に定義されたポートを使用する場合より多くの我々は、サービスを提供しています。結局のところ、同じポート上の2つのサービスを監視することはできません。使用百の管理サービスのすべてのポートを閉じるリスト自体が課題です。リストにサービスを必要なデータベースを追加し、数はさらに大きくなります。このような理由から、我々はポートを指定せずにサービスを展開し、させてくださいドッカーを私たちはランダムなサービスを割り当てるします。唯一の問題は、我々は、ポート番号を見つけて、他の人がそれについて知っている必要があるということです。
私たちは、一つのサービス分散システムに複数のサーバーを展開し始めたとき、物事はより複雑になります。私たちは、どのサービスどの事前定義されたようにサーバを選択することができますが、多くの問題を引き起こす可能性があります。私たちは、事前に、それはほとんど不可能である各サービスの展開を定義した場合我々は、可能な限り、サーバーリソースの使用をしなければなりません。もう一つの問題は、自動的にサービスがサーバー障害の自動回復はもちろんのこと、最も困難な拡張されます。一方、我々は、（例えば、コンテナの最小数を実行している）サーバーにサービスを展開する場合、我々はデータのリストのどこかに保存されたと見つける必要にIPを追加する必要があります。
私たちが使っているサービスに関連する情報の一部を格納および取得（見つける）する必要がある場合には、他の多くの例があります。
当社のサービスを見つけることができるようにするために、我々は我々の使用のために、少なくとも次の二つの工程を必要としています。
- サービス登録プロセス、実行されている、少なくともホストとポートサービス店。
- サービス発見他の人が、我々は登録プロセスに格納情報を検索することができ、プロセス、。
これらのプロセスに加えて、我々はまた、いくつかの他の側面を考慮する必要があります。サービスは動作を停止し、展開した場合/私たちはサービスの登録を解除する必要があるかどうか、新しいインスタンスを登録しますか？同じサービスの複数のコピーがある場合はどうなりますか？どのように我々はそれらの間の負荷のバランスをとるのですか？サーバーは、何が起こるか失敗した場合は？これらおよび登録と発見のプロセスに関連する他の多くの問題は密接に関連しています。現在、我々は唯一の有効範囲を制限サービスの発見だけでなく、我々はそのようなタスクのためのよいツール（一般的な2つのプロセス名を含みます）。それらのほとんどは、高可用性の分散キー/値ストアのいくつかの種類があります。
サービス検出ツール
サービス検出ツールの主な目標は、見つけて相互に通信するためのサービスを支援することです。その職務を行うためには、彼らは、各サービスの場所を知っている必要があります。この概念は、ドッカーが存在していたずっと前に誕生した新しい、多くのツールではありません。しかし、コンテナは、そのようなツールは、全く新しいレベルに達している必要があります。
サービス検出の基本的な考え方、新しい各インスタンスのサービス（またはアプリケーション）は、彼らの現在の環境を確認し、情報を保存することができます。それ自体は、典型的には、キー/値のフォーマットを実行するために、レジストリに格納されています。この発見は、一般的に、分散システムで使用されているので、レジストリは、クラスタとフォールトトレラントのすべてのノード間で分散、スケーラブルです。このストレージの主な目的は、少なくともIPとポートのすべての関係者と通信するためのサービスを提供する必要があるかもしれないです。これらのデータは、通常、他の種類の情報で拡張されています。
ディスカバリーツールは、サービスは、サービスに関する情報を見つけるために自分自身と他人を登録するためにそれを使用することができ、APIのいくつかの種類を提供する傾向があります。
我々は2つのサービスがあるとします。一つは、プロバイダであり、他方は、消費者です。展開プロバイダの後、我々は情報を保存する必要が選ばサービス発見レジストリ内を。消費者がプロバイダにアクセスしようとすると、後で、それは最初にレジストリを照会して、レジストリから取得したコール・プロバイダーのIPとポートを使用します。分離のレジストリで特定の人物を提供するために、私たちはしばしばいくつかの種類の使用プロキシサービスを。このように、消費者は常に機関内に存在する固定アドレスからの情報を要求し、ひいては機関が情報を見つけるために、ディスカバリサービスプロバイダを使用して、要求をリダイレクトします。我々はなりリバースプロキシ後でブックインチ さて、3人の参加者に基づいてプロセスを理解することは非常に重要であり、 消費者、エージェントおよびプロバイダー。
私たちはデータを見つけるためのサービスツールを見つけました。少なくとも我々は、サービスの場所を見つけることができるはず、と保健サービスは、サービスを構成しています。以来、私たちは、複数のサーバに分散システムを構築しているので、強力なツールの必要性、およびノードの障害は、データを危険にさらすべきではありません。また、各ノードは、データの正確に同じコピーを有していなければなりません。加えて、我々は、任意の順序でサービスを開始し、それらを破壊することができるか、新しいバージョンに置き換えることができるように願っています。また、当社のサービスを再構成し、それに応じてデータを表示することができるはずです。
我々が設定した共通の目標を達成するために、いくつかのオプションを見てみましょう。
手動設定
ほとんどのサービスはまだ手動で管理されています。私たちは、その構成が何であるか、どこのサービスを展開するには、事前に決定し、それが最後まで作業を続けることを願っています。この方法では、拡大することは困難です。サービスの展開の2番目のインスタンスは、私たちが完全に手動のプロセスをアクティブにする必要があることを意味します。私たちは、新しいサーバを起動したり、利用が低いリソースを見つけるために、構成や展開の新しいセットを作成する必要があります。手動で物事を管理する場合、反応時間は、通常、非常に遅いので、ハードウェアの障害状況の場合には、より複雑です。可視性は、ビューの他の痛みを伴う点です。私たちは知っている静的な構成はい。結局のところ、私たちは事前に準備が整いました。しかし、ほとんどのサービスは、動的に生成された情報の数が多いです。この情報は見ることは容易ではありません。私たちはこれらのデータを必要とするとき、我々は、単一の場所を照会することはできません。
管理し、疑わしい監視するために最も困難な手動操作の可動部品の数が多い、反応時間は必然的に遅い、弾力以来。
過去またはサービスおよび/または少数のサーバに手動で行う作業が言い訳ですが、サービス発見ツールの登場で、その言い訳はすぐに消えてしまうということですが。
飼育係、ZKを参照し、飼育係
ZooKeeperのは、プロジェクトのこの種の最古の一つです。それが構築さHadoopクラスタのさまざまなコンポーネントを維持するためにある、Hadoopの世界で始まりました。それは、成熟した、信頼性、および多くの大企業（YouTubeの、イーベイ、ヤフーなど）を使用することです。これは、ファイルシステムの編成と同様のデータ形式を格納します。サーバークラスタ上で実行されている場合は、Zookeperの構成状態は、すべてのノード間で共有しました。各クラスタには、リーダーを選択し、クライアントがデータを取得するために、任意のサーバに接続することができます。
主な利点は、飼育係の成熟度、堅牢性と機能豊富なを持っています。しかし、それはまた、独自の欠点があり、Javaや複雑さが主犯です。多くのユースケースのためのJavaは素晴らしいですが、この種の仕事のために、それは非常に重いです。が、飼育係のJavaの使用だけでなく、依存関係の相当数は、競争の中で、それより希少な資源になります。これらの問題に加えて、飼育係はまた、非常に複雑です。それは私たちがアプリケーションより多くの知識のこのタイプから期待するものよりも維持する必要があります。これは、負債の一部から自体に機能豊富な利点があります。機能のチャンスでより多くのアプリケーションでは、我々はすべての機能がされる必要はありません。だから、私たちは結局、我々は複雑な形状で代金を支払う必要が正確に何ではありません。
飼育係は、他の人に道を開いた、とかなりの進歩を遂げました。何より良い選択肢がなかったので、「ビッグプレイヤーは」、それを使用しています。今日、飼育係は、その年齢を示し、私たちの選択肢がより良いです。
ETCD
etcdは、HTTP /値のストレージを介してアクセス結合です。これは、階層的な構成は、建物のサービス検出のためのシステムを持つ、配布されています。これは、導入が簡単で、セットアップと使用、信頼性の高いデータの永続性、セキュリティ、および非常に良いドキュメントを提供しています。
理由は、そのシンプルさのため、飼育係より良い選択よりもetcd。しかし、それはターゲットを見つけるために、サードパーティ製ツールの数が少ないと連携してサービスを提供する必要があります。
现在我们有了一个存储与我们服务相关的信息的地方，我们需要一个能够自动将该信息发送给etcd的工具。毕竟，如果可以自动完成，我们为什么要手动将数据输入到etcd。即使我们想要将信息手动输入到etcd，我们通常也不知道该信息是什么。请记住，服务可能部署到运行最少容器的服务器，并且可能已分配随机端口。理想情况下，该工具应监视所有节点上的Docker，并在运行新容器或停止现有容器时更新etcd。可以帮助我们实现这一目标的工具之一是Registrator。
Registrator
Registrator通过检查容器在线或停止时自动注册和取消注册服务。它目前支持etcd，Consul和SkyDNS 2。
Registrator结合etcd是一个强大而简单的组合，它允许我们练习许多高级技术。每当我们调出容器时，所有数据都将存储在etcd中并传播到集群中的所有节点。我们对这些信息的处理取决于我们。
还有一块拼图丢失了。我们需要一种方法来创建配置文件，其中包含存储在etcd中的数据，以及在创建这些文件时运行一些命令。
confd
confd是一个轻量级的配置管理工具。常见用法是使用存储在etcd，consul和少数其他数据注册表中的数据使配置文件保持最新。它还可用于在配置文件更改时重新加载应用程序。换句话说，我们可以将它用作使用etcd（或许多其他注册表）中存储的信息重新配置所有服务的方法。
关于etcd，Registrator和confd组合的最终想法
当etcd，Registrator和confd相结合时，我们会得到一种简单而强大的方法来自动化我们所有的服务发现和配置需求。这种组合还证明了正确组合“小”工具的有效性。这三个人正是我们需要他们做的事情。不到这一点，我们就无法实现摆在我们面前的目标。另一方面，如果它们的设计考虑到更大的范围，我们会在服务器资源上引入不必要的复杂性和开销。
在我们做出最终判决之前，让我们看一下具有类似目标的另一种工具组合。毕竟，我们不应该在没有调查替代方案的情况下解决某些问题。
Consul
Consul是一个强大的一致数据存储区，它使用八卦来形成动态集群。它具有分层键/值存储，不仅可用于存储数据，还可用于注册可用于各种任务的监视，从发送有关数据更改的通知到运行运行状况检查和自定义命令（取决于其输出）。
与Zookeeper和etcd不同，Consul实现嵌入式服务发现系统，因此无需构建自己的服务或使用第三方服务。此发现包括对其上运行的节点和服务的运行状况检查。
ZooKeeper和etcd仅提供原始的K / V存储，并要求应用程序开发人员构建自己的系统以提供服务发现。另一方面，Consul为服务发现提供了内置框架。客户端只需要使用DNS或HTTP接口注册服务并执行发现。其他两个工具需要手工解决方案或使用第三方工具。
Consul为多个数据中心和八卦系统提供开箱即用的本机支持，这些系统不仅适用于同一集群中的节点，也适用于数据中心。
Consul有另一个很好的功能，可以区别于其他功能。它不仅可用于发现有关已部署服务及其所在节点的信息，还可通过HTTP请求，TTL（生存时间）和自定义命令轻松扩展运行状况检查。
Registrator
Registrator有两个Consul协议。所述consulkv协议产生类似的结果作为与该ETCD协议获得的那些。
除了通常与etcd或consulkv协议一起存储的IP和端口之外，Registrator的consul协议还存储了更多信息。我们获取有关运行服务的节点的信息以及服务ID和名称。除了少量额外的环境变量，我们还可以以标签的形式存储其他信息
consul模板
confd可以与consul一样使用，与etcd一样。然而，Consul拥有自己的模板服务，其功能更符合Consul提供的服务。
该模板是建立与confd获得的值文件非常方便的方式。作为额外的奖励，它还可以在文件更新后运行任意命令。就像confd一样，consul-template也使用Go Template格式。
consul健康检查，Web UI和数据中心
监视群集节点和服务的运行状况与测试和部署本身一样重要。虽然我们应该致力于拥有永不失败的稳定环境，但我们也应该承认意外的失败发生并准备采取相应的行动。例如，我们可以监视内存使用情况，如果达到某个阈值，则将某些服务移动到集群中的其他节点。这将是在“灾难”发生之前执行的预防措施的一个例子。另一方面，并非所有潜在的故障都能及时检测到我们按时采取行动。单个服务可能会失败。由于硬件故障，整个节点可能会停止工作。在这种情况下，我们应该准备尽可能快地采取行动，例如，用新的节点替换节点并移动失败的服务。领事有一个简单，优雅，
如果您搜索“etcd ui”或“etcd仪表板”，您可能会看到有一些可用的解决方案，可能会问我们为什么没有提供它们。原因很简单; etcd是一个键/值存储，而不是更多。拥有用于呈现数据的UI并没有多大用处，因为我们可以通过etcdctl轻松获取它。这并不意味着etcd UI没有用，但由于其范围有限，它没有太大的区别。
Consul不仅仅是一个简单的键/值存储。正如我们已经看到的，除了存储简单的键/值对之外，它还具有服务概念以及属于它的数据。它还可以执行运行状况检查，从而成为仪表板的良好候选者，可用于查看在其上运行的节点和服务的状态。最后，它理解多个数据中心的概念。所有这些功能相结合，让我们看到了对不同灯光仪表板的需求。
使用Consul Web UI，我们可以查看所有服务和节点，监控运行状况检查及其状态，读取和设置键/值数据以及从一个数据中心切换到另一个数据中心。
关于Consul，Registrator，Template，健康检查和Web UI的最终想法
在许多情况下，Consul与我们探索的工具一起比etcd提供的解决方案更好。它的设计考虑了服务架构和发现。它很简单，但功能强大。它提供了一个完整的解决方案，而且不会牺牲简单性，在许多情况下，它是服务发现和健康检查需求的最佳工具。
结论
所有工具都基于类似的原则和架构。它们在节点上运行，需要仲裁才能运行并且非常一致。它们都提供某种形式的键/值存储。
zk是三个中最老的，年龄表现在其复杂性，资源利用和目标。它的设计时间与我们评估的其他工具的年龄不同（即使它不是很老）。
ETCD与Registrator和confd是可以解决大部分，如果不是所有的我们的服务发现的需求，一个非常简单但非常强大的组合。它还展示了我们在结合简单和非常具体的工具时可以获得的强大功能。它们中的每一个都执行一项非常具体的任务，通过完善的API进行通信，并且能够使用相对自治。他们自己在建筑和功能方面都是微服务。
Consul的不同之处在于，无需使用第三方工具即可支持多个数据中心和健康检查。这并不意味着使用第三方工具很糟糕。实际上，在整个博客中，我们尝试通过选择性能优于其他工具而不引入不必要的功能开销来组合不同的工具。当我们使用正确的工具完成工作时，可以获得最佳结果。如果该工具的功能超过我们所需的工作，其效率就会下降。另一方面，不做我们需要它的工具是没用的。领事达到了正确的平衡。它做的事情很少，而且做得很好。
領事使用ゴシップスプレッドの知識は、特に大規模なデータセンターの場合には、etcdを設定するよりも簡単な方法をクラスタ化します。サービスの能力がより完全かつ有用な（領事も、このオプションを持っているが）比でキー/値ストアetcdを行うようにデータが格納されています。我々は、複数のキーを挿入することができますが同じことを達成するためにetcdが、サービスは領事の結果は、よりコンパクトな、一般的にサービスに関連するすべてのデータを取得するために、単一のクエリを必要とし実施することができます。最も重要なことは、レジは領事テンプレートをするとき、この画像に追加された場合は特に、その両方の良い組み合わせ作り、非常に良い領事プロトコルを持っています。領事のWeb UIは、ケーキの上の桜、視覚的なサービスと健康を提供するための良い方法のようなものです。
私は、領事が明確な勝者であると言うことはできません。逆に、etcdと比較して、それがわずかに有利です。コンセプトとサービス発見ツールとして、我々は使用することができ、我々はこの分野での変化の多くを期待することができるように新しいです。オープンマインドを持っており、この記事からいくつかのアドバイスを学ぶしようとします。さまざまなツールを試してみて、自分自身の結論を出します。
：からの翻訳 https://technologyconversations.com/2015/09/08/service-discovery-zookeeper-vs-etcd-vs-consul/