Synapse

一個用於連接 SOA 的透明服務發現框架
2,034
作者Igor Serebryany

Synapse 是 Airbnb 新的服務發現系統。Synapse 解決了雲端中自動故障轉移的問題，因為在雲端環境中，透過網路重新配置來進行故障轉移是不可能的。最終結果是能夠以可擴展、容錯的方式將內部服務連接在一起。

動機

Synapse 的出現是源於在雲端環境中維護高可用性應用程式的需求。傳統的高可用性技術，例如使用像 pacemaker 這樣的 CRM，在最終使用者無法控制網路的環境中無法運作。在像 Amazon 的 EC2 這樣的環境中，所有可用的解決方案都不是最佳的。

  • 輪詢 DNS：收斂速度慢，且當應用程式快取 DNS 查詢時（情況很常見）無法正常運作
  • 彈性 IP：收斂速度慢，數量有限，且僅面向公眾，這使得它們對於內部服務不太有用
  • ELB：同樣，僅面向公眾，且僅適用於 HTTP

這個問題的一個解決方案是像 Apache Zookeeper 這樣的發現服務。然而，Zookeeper 和類似的服務也有它們自己的問題

  • 服務發現嵌入在所有應用程式中；通常，整合並不簡單
  • 發現層本身也可能發生故障
  • 需要額外的伺服器/實例

Synapse 以簡單且容錯的方式解決了這些困難。

Synapse 的運作方式

Synapse 在您的應用程式伺服器上執行；在 Airbnb，我們只是將它部署在我們部署的每個機器上。Synapse 的核心實際上是 HAProxy，一個穩定且經過驗證的路由組件。對於您的應用程式所連接的每個外部服務，我們在 localhost 上分配一個 Synapse 本機連接埠。Synapse 建立從本機連接埠到服務的代理，然後您重新配置您的應用程式以連接到該代理。

Synapse 帶有一些 watchers，負責服務發現。Synapse watchers 負責重新配置代理，使其始終指向可用的伺服器。我們包含了一些預設的 watchers，包括查詢 Zookeeper 的和使用 AWS API 的。您可以輕鬆地為您的使用案例編寫自己的 watchers，並且我們鼓勵您將它們提交回專案。

遷移範例

假設您的 Rails 應用程式依賴於 PostgreSQL 資料庫實例。database.yaml 檔案中硬編碼了資料庫主機和連接埠

production:
  database: mydb
  host: mydb.example.com
  port: 5432

您希望在原始資料庫死機時能夠故障轉移到不同的資料庫。假設您的實例在 AWS 中執行，並且您正在使用標籤 'proddb' 設定為 'true' 來指示生產資料庫。您設定 Synapse 在 synapse.conf.yaml 檔案中代理 localhost:3219 上的資料庫連線。在 services 下新增一個看起來像這樣的雜湊

---
 services:
  proddb:
   default_servers:
    -
     name: "default-db"
     host: "mydb.example.com"
     port: 5432
   discovery:
    method: "awstag"
    tag_name: "proddb"
    tag_value: "true"
   haproxy:
    port: 3219
    server_options: "check inter 2000 rise 3 fall 2"
    frontend: mode tcp
    backend: mode tcp

然後將您的 database.yaml 檔案變更為如下所示

production:
  database: mydb
  host: localhost
  port: 3219

啟動 Synapse。它將使用從 localhost:3219 到您的資料庫的代理配置 HAProxy。它將嘗試使用 AWS API 尋找資料庫；如果此方法無效，它將預設為 default_servers 中提供的資料庫。在最壞的情況下，如果 AWS API 關閉並且您需要變更應用程式所連接的資料庫，只需編輯 synapse.conf.json 檔案，更新 default_servers 並重新啟動 Synapse。HAProxy 將會透明地重新載入，並且您的應用程式將會繼續運作，不會受到任何影響。

連結