理解基於 docker 的現代化的服務發現

糙譯，[Warning] 繼續閱讀可能會感到不適

人一輩子不可能踩到同一灘大便，故而，本文會持續修改。

---

Understanding Modern Service Discovery with Docker

Over the next few posts, I'm going to be exploring the concepts of service discovery in modern service-oriented architectures, specifically around Docker. Many people aren't familiar with service discovery, so I have to start from the beginning. In this post I'm going to be explaining the problem and providing some historical context around solutions so far in this domain.

我要從頭開始講講 service discovery, 而且要八卦一下歷史。

Ultimately, we're trying to get Docker containers to easily communicate across hosts. This is seen by some as one of the next big challenges in the Docker ecosystem. Some are waiting for software-defined networking (SDN) to come and save the day. I'm also excited by SDN, but I believe that well executed service discovery is the right answer today, and will continue to be useful in a world with cheap and easy software networking.

最終，咱們會作到：Docer containers 輕鬆跨主機交流。這是這 Docker 生態中被認爲是另外一個大挑戰。一些觀點期盼 SDN 來實現這一功能。我也以爲 SDN 很是帶勁兒，蛋是，我今天相信 well excuted 的 service discovery 纔是正確答案，爾切，能夠在又賤又容易的網絡中使用。

What is service discovery?

Service discovery tools manage how processes and services in a cluster can find and talk to one another. It involves a directory of services, registering services in that directory, and then being able to lookup and connect to services in that directory.

Service discovery 工具管理這樣的事情：在一個 cluster 中 processes 和 services 可以發現，爾切 互相能夠交談。這包括了，一個目錄 services , 這個目錄中的註冊 services ，爾切，可以查 lookup 和 connect 到目錄中的 services。

At its core, service discovery is about knowing when any process in the cluster is listening on a TCP or UDP port, and being able to look up and connect to that port by name.

這當中的核心問題是，service discovery 知道 什麼時候 cluster 中的 任意 process 在監聽 TCP 和 UDP 端口，可以根據name 查找，連接到端口。

Service discovery is a general idea, not specific to Docker, but is increasingly gaining mindshare in mainstream system architecture. Traditionally associated with zero-configuration networking, its more modern use can be summarized as facilitating connections to dynamic, sometimes ephemeral services.

Service discover 是一個 general 的 idea，並不針對 Docker, 蛋是，她開始成爲主流的系統 architecture。傳統的體系是關於 零配置網絡，更現代的用途是可以 summarized as facilitating connections to dynamic, 有時是一些短暫的 services。

This is particularly relevant today not just because of service-oriented architecture and microservices, but our increasingly dynamic compute environments to support these architectures. Already dynamic VM-based platforms like EC2 are slowly giving way to even more dynamic higher-level compute frameworks like Mesos. Docker is only contributing to this trend.

Name Resolution and DNS

You might think, "Looking up by name? Sounds like DNS." Yes, name resolution is a big part of service discovery, but DNS alone is insufficient for a number of reasons.

你也許會想，「以 name 發現，相似 DNS」 是的，name resolution 是 service discovery 的一大塊內容，蛋是 DNS 單獨是不夠的。

A key reason is that DNS was originally not optimized for closed systems with real-time changes in name resolution. You can get away with setting TTL's to 0 in a closed environment, but this also means you need to serve and manage your own internal DNS. What highly available DNS datastore will you use? What creates and destroys DNS records for your services? Are you prepared for the archaic world of DNS RFCs and server implementations?

一個關鍵的緣由：DNS 不是針對 封閉的實時改變的系統 而原生優化的。能夠調整 TTL 到0，得到封閉的環境，蛋是，這意味着須要設定本身的內部 DNS。這裏存在三個棘手問題。。。

Actually, one of the biggest drawbacks of DNS for service discovery is that DNS was designed for a world in which we used standard ports for our services. HTTP is on port 80, SSH is on port 22, and so on. In that world, all you need is the IP of the host for the service, which is what an A record gives you. Today, even with private NATs and in some cases with IPv6, our services will listen on completely non-standard, sometimes random ports. Especially with Docker, we have many applications running on the same host.

事實上，DNS 解決 service discovery 一個最大的 drawbacks 是 她自己是爲 現實世界 而設計的，她使用標準 ports 來提供服務。。。。。。。。。針對 Docker，有不少 application 運行在同一個 host 中。

You may be familiar with SRV records, or "service" records, which were designed to address this problem by providing the port as well as the IP in query responses. At least in terms of a data model, this brings DNS closer to addressing modern service discovery.

Unfortunately, SRV records alone are basically dead on arrival. Have you ever used a library or API to create a socket connection that didn't ask for the port? Where do you tell it to do an SRV record lookup? You don't. You can't. It's too late. Either software explicitly supports SRV records, or DNS is effectively just a tool for resolving names to host IPs.

Despite all this, DNS is still a marvel of engineering, and even SRV records will be useful to us yet. But for all these reasons, on top of the demands of building distributed systems, most large tech companies went down a different path.

Rise of the Lock Service

In 2006, Google released a paper describing Chubby, their distributed lock service. It implemented distributed consensus based on Paxos to provide a consistent, partition-tolerant (CP in CAP theorem) key-value store that could be used for coordinating leader elections, resource locking, and reliable low-volume storage. They began to use this for internal name resolution instead of DNS.

2006年 Google 發佈了一片 paper 描述了 Chubby，分佈式 lock service。

Eventually, the paper inspired an open source equivalent of Chubby called Zookeeper that spun out of the Hadoop Apache project. This became the de facto standard lock server in the open source world, mainly because there were no alternatives with the same properties of high availability and reliability over performance. The Paxos consensus algorithm was also non-trivial to implement.

最終，這片 paper 激發了與 Chubby 等價的 從 Hadoop Apache 項目 分離出來的 Zookeeper。她成爲了開源世界中 lock server 的事實上的標準，主要由於，並沒有一樣高可用和可靠的替代品。 Paxos consensus 算法也同樣。

Zookeeper provides similar semantics as Chubby for coordinating distributed systems, and being a consistent and highly available key-value store makes it an ideal cluster configuration store and directory of services. It's become a dependency to many major projects that require distributed coordination, including Hadoop, Storm, Mesos, Kafka, and others. Not surprisingly, it's used in mostly other Apache projects, often deployed in larger tech companies. It is quite heavyweight and not terribly accessible to "everyday" developers.

Zookeeper 提供了與 Chubby 類似的語義，用來協調分佈式系統，做爲一個 consistent and highly available 的 key-value 存儲，使其成爲理想的 cluster 配置存儲服務和目錄服務。她成爲了不少須要 distributed coordination 項目的主要依賴部件, 包括 Hadoop, Storm, Mesos, Kafka, and others。絕不奇怪，用於其餘的 Apache 項目，常常不屬於大型技術公司。她是一名超重量級選手， not terribly accessible to "everyday" developers.

About a year ago, a simpler alternative to the Paxos algorithm was published called Raft. This set the stage for a real Zookeeper alternative and, sure enough, etcd was soon introduced by CoreOS. Besides being based on a simpler consensus algorithm, etcd is overall simpler. It's written in Go and lets you use HTTP to interact with it. I was extremely excited by etcd and used it in the initial architecture for Flynn.

大約一年以前，發佈了一個叫作 Raft 的算法，這是一個類似而且能夠替代 Paxos 算法的算法。她被做爲階段性的 真正的 Zookeeper 的 alternative，十分肯定的是，etcd 很快引入 CoreOS。由於，基於一個簡單的 consensus algorithm，etc 總體簡化了。用 Go 編寫，使用 HTTP 進行交互。etcd讓我他媽了個逼的嫉妒興奮，我用它初始化 Flynn 的架構。

Today there's also Consul by Hashicorp, which builds on the ideas of etcd. I specifically explore Consul and lock servers more in my next post.

而今，有了 Hashiicorp 的 Consul，基於 etcd 的想法構建。我在下面，特別探索了 Consul 和 lock servers。

Service Discovery Solutions

Both Consul and etcd advertise themselves as service discovery solutions. Unfortunately, that's not entirely true. They're great service directories. But this is just part of a service discovery solution. So what's missing?

We're missing exactly how to get all our software, whether custom services or off-the-shelf software, to integrate with and use the service directory. This is particularly interesting to the Docker community, which ideally has portable solutions for anything that can run in a container.

A comprehensive solution to service discovery will have three legs:

• A consistent (ideally), highly available service directory

• A mechanism to register services and monitor service health

• A mechanism to lookup and connect to services

We've got good technology for the first leg, but the remaining legs, despite how they sound, aren't exactly trivial. Especially when ideally you want them to be automatic and "non-invasive." In other words, they work with non-cooperating software, not designed for a service discovery system. Luckily, Docker has both increased the demand for these properties and makes them easier to solve.

In a world where you have lots of services coming and going across many hosts, service discovery is extremely valuable, if not necessary. Even in smaller systems, a solid service discovery system should reduce the effort in configuring and connecting services together to nearly nothing. Adding the responsibility of service discovery to configuration management tools, or using a centralized message queue for everything are all-to-common alternatives that we know just don't scale.

My goal with these posts is to help you understand and arrive at a good idea of what a service discovery system should actually encompass. The next few posts will take a deeper look at each of the above mentioned legs, touching on various approaches, and ultimately explaining what I ended up doing for my soon-to-be-released project, Consulate.