Presto 集群配置不管是coordinator還是worker配置項中都有一項discovery.uri,這個是一個比較核心的東西，簡單來說就是服務發現的地址。
coordinator和worker都會將自身注冊到這個服務發現地址上，供彼此發現對方，coordinator可以通過個發現服務知道有多少worker節點，而worker節點可以通過這個發現服務知道coordinator是誰，這樣做的好處是coordinator和worker做到了完全的解耦，彼此都不需要在啟動時配置對方，而是通過第三方服務來發現對方。
無論是Presto on Yarn 還是說 discovery 組件的高可用，一般情況官網 沒有說明其如何做，
在默認的情況下這個發現服務是內嵌在coordinator中的，也就是coordinator在啟動的時候會啟動一個內嵌的發現服務，在這種情況下，coordinator將自身注冊給自身的發現服務，而worker則將發現服務的地址配置成coordinator的發現服務地址，此時coordinator同時充當presto協調者和服務發現的提供者。
以上這種情況在一般的情況下可以良好的運行，但是當我們將presto服務遷移到Presto On Yarn時就會遇到一些問題：
presto on yarn是一種動態的運行策略，在yarn上面，哪個節點運行presto的coordinator和worker是不確定的，這會給外部調用presto的程序帶來困擾
外部的程序和presto的交流一般是通過presto提供的客戶端來調用，而它的客戶端需要事先知道presto的coordinator地址，在presto on yarn的情況下，coordinator的地址是不確定的，有可能會發生變化。
這種情況下的處理方案是：將presto的服務發現方案外置，將presto的服務發現服務獨立於presto的coordinator運行，將presto的coordinator和worker中的discovery.uri配置成外部獨立的發現服務地址，在外部提供具有HA的服務發現，提供穩定的發現服務。
Presto的服務發現是基於airlift的服務發現做的實現，airlift的服務發現可以在這里查看實現和源碼，不過它基本是處於無文檔的狀態，所以理解要多花些功夫。
airlift的服務發現的總體思路是基於http提供一個提供服務發現的HA集群，集群之間通過http通信，通過數據同步方式，提供最終一致性的保證。
這里我們就來說說airlift的服務發現服務的HA安裝。
Airlift Discovery安裝
安裝步驟
下載源碼
git clone https://github.com/airlift/discovery.git
編譯源碼
mvn clean package -DskipTests=true
環境安裝
將target目錄下的discovery-server--SNAPSHOT.tar.gz安裝包copy至安裝機器上進行解壓安裝
環境配置
解壓后在解壓目錄新建etc目錄，並在etc目錄下新建以下配置文件
config.properties
jvm.config
log.properties
node.properties
service-inventory.json
配置文件
config.properties文件為主配置文件，主要配置該discovery服務的主要配置信息，如運行環境，服務端口，節點id等信息，配置信息一般情況如下：
node.environment=test
http-server.http.port=8411
node.id=597A741E-9968-40E2-BB4D-7AF26DE18689
service-inventory.uri=file://
node.environment指定運行環境
http-server.http.port指定服務運行的端口
node.id指定該節點的id
service-inventory.uri指定了該集群擁有的所有節點信息
jvm.config文件主要配置服務jvm的配置信息，該配置和presto的配置文件的jvm配置類似，一般情況按如下信息自行進行調整：
-server
-Xmx2G
-XX:+UseG1GC
-XX:G1HeapRegionSize=32M
-XX:+UseGCOverheadLimit
-XX:+ExplicitGCInvokesConcurrent
-XX:+HeapDumpOnOutOfMemoryError
-XX:OnOutOfMemoryError=kill -9 %p
log.properties主要記錄的日志級別調整，這里不再敘述
node.properties主要記錄的是節點相關的配置，類似於config.properties配置，但是不同點在於config.properties強調集群共有的特性，而node.properites強調節點間相同配置項的不同配置值區別
service-inventory.json這是一個比較重要的文件，里面記錄了整個集群的信息，discovery集群利用這個配置文件獲取集群的所有信息，知道集群中所有部署的情況及如何與其它節點進行通信。它的配置如下：
{
"environment": "test",
"services": [
{
"id": "C8A9EE64-0476-452C-8638-8E72F3EE3CA6",
"nodeId": "597A741E-9968-40E2-BB4D-7AF26DE18689",
"type": "discovery",
"pool": "general",
"location": "/172.17.31.245",
"state": "RUNNING",
"properties": {
"http": "http://172.17.31.245:8411"
}
},
{
"id": "370AF416-5F44-47D3-BFB6-D93A92676D49",
"nodeId": "0BA42FDB-5DBA-4A2C-BE26-9596B7B4368E",
"type": "discovery",
"pool": "general",
"location": "/172.17.31.246",
"state": "RUNNING",
"properties": {
"http": "http://172.17.31.246:8411"
}
}
]
}
以上面的配置中，集群中有兩個節點，並指出了兩個節點的節點id信息，以及他們的通信地址properties.http等信息，有了這份信息，集群中的各節點就知道如何同其它節點進行數據交互與同步了。
運行集群
在集群每個節點的安裝目錄下bin目錄中運行: ./launcher start進行服務的啟動， ./launcher stop 進行服務的停止 ./launcher restart 進行服務的重啟
驗證服務
當服務運行成功后，可以通過瀏覽器進行訪問，若配置的端口為8411，則訪問發現服務的地址為：http://localhost:8411/v1/service
這個地址將返回所有注冊到這個發現服務的服務的列表
高可用
因多台機器共同組成了發現服務，發現服務有最終一致性保障，所以只需要訪問其中一台就可以，但是為了高可用，可以在發現服務前端加入NGINX作流量分擔與負載解決高可用的問題
Presto節點信息注冊到發現服務
將Presto的節點信息注冊到發現服務非常簡單，上面也說過了，Presto節點之前是通過自身位集群的coordinator節點充當服務發現者提供服務的，現在只需要將discovery.uri的配置換成外置的airlift服務發現服務地址就可以了用了。在這個示例中我將配置值修改成了’172.17.31.245:8411’,因為是測試環境，不需要過於要求的HA場景，所以我只配置了服務發現集群中的一個節點。
Presto的客戶端集成
因Presto的客戶端調用需要知道coordinator，而現在Presot On Yarn上了過后，coordinator的地址是不定的，且是注冊到服務發現上的，對於Presto客戶端想知道明確的coordinator地址需要做一些改變：將調用presto客戶端前要先得到coordinator，而要得到coordinator可以通過服務發現獲取，看了下airlift這個框架，它自身提供了服務發現的客戶端的功能，但是看了有點暈眩，大致思路是實現一個http接口去定期輪詢服務發現地址，得到服務地址(coordinator)就可以了，於是我自己實現了一個簡易版本的，通過一個服務發現的網關地址，應用啟動后通過后台線程每隔10s去輪詢一次該服務發現網關，得到更新的coordirnator地址，更新本報的緩存，所有獲取coordinator地址都從本地緩存中獲取，避免每次的服務發現網關輪詢。
目前運行情況
目前運行情況良好，充分解決了Presto On Yarn后的coordinator隨時可變的情況，應用能夠根據coordinator的變化隨時適應變化（10s延時）及時調整，避免因coordinator的變化導致的查詢應用不可用問題。
問題：是否可以根據一個discovery.uri 啟動多個coordinator.?從多個coo 代理進去的任務是否相當於跑在同一集群？？