使用 caddy 作為微服務的 API gateway

Lemon_95 發布于2019-06-28 15:40 / 903人閱讀

摘要：它同時也和微服務架構相互促進，并肩前行。為了反向代理的速度，會和后端保持一個連接池。好了，現在我們可以知道，可以很好的勝任微服務架構中的了。我認為并不適合微服務架構，但依然是有個復雜的架構方案的，這個主題改天再說。

背景

大家都知道，Docker這些年讓IT界產生了深刻的變革，
從開發到測試到運維，處處都有它的身影。
它同時也和微服務架構相互促進，并肩前行。

在最新版的 Docker(CE 17.03) 里，隨著 swarm mode 的成熟，
在較簡單的場景里已經可以不再需要專門的基礎設施管理，
服務編排，服務發現，健康檢查，負載均衡等等。

但是API gateway還是需要一個的。或許再加上一個日志收集，
你的微服務架構就五臟俱全了。
我們知道Nginx Plus是可以很好的勝任 API gateway 的工作的，
但它是商業軟件。Nginx我們不說認證啊限流啊統計啊之類的功能，
單就請求轉發這一點最基本的就出了問題。

我們知道Docker是用DNS的方式，均衡同一名稱的服務請求到不同的node，
但是Nginx為了速度，在反向代理的時候會有一個不可取消的 DNS Cache，
這樣我們Docker在根據容器的擴展或收縮動態的更新DNS，可Nginx卻不為所動，
堅持把請求往固定的IP上發，不說均衡，這個IP甚至可能已經失效了呢。

有一個配置文件上的小Hack可以實現Nginx每次去查詢DNS，我本來準備寫一篇文章來著，
現在看來不用了，我們找到了更優雅的API gateway, Caddy 。
我上篇文章也寫了一個它的簡介。

接下來的所有代碼，都在這個demo中，
你可以clone下來玩，也能在此基礎上做自己的實驗。

應用

我們先用golang寫一個最簡單的HTTP API，你可以用你會的任何語言寫出來，
它為GET請求返回 Hello World 加自己的 hostname .

package main

import (
    "io"
    "log"
    "net/http"
    "os"
)

// HelloServer the web server
func HelloServer(w http.ResponseWriter, req *http.Request) {
    hostname, _ := os.Hostname()
    log.Println(hostname)
    io.WriteString(w, "Hello, world! I am "+hostname+" :)
")
}

func main() {
    http.HandleFunc("/", HelloServer)
    log.Fatal(http.ListenAndServe(":12345", nil))
}

Docker 化

我們需要把上面的應用做成一個docker鏡像，暴露端口12345。
接著才有可能使用Docker Swarm啟動成集群。
本來做鏡像特別簡單，但我為了讓大家直接拉鏡像測試時快一點，用了兩步構建，
先編譯出應用，然后添加到比較小的alpine鏡像中。大家可以不必在意這些細節。
我們還是先來看看最終的docker-compose.yml編排文件吧。

version: "3"
services:
    app:
        image: muninn/caddy-microservice:app
        deploy:
            replicas: 3
    gateway:
        image: muninn/caddy-microservice:gateway
        ports:
            - 2015:2015
        depends_on:
            - app
        deploy:
            replicas: 1
            placement:
                constraints: [node.role == manager]

這是最新版本的docker-compose文件，不再由docker-compose命令啟動，而是要用docker stack deploy命令。
總之現在這個版本在編排方面還沒有完全整合好，有點暈，不過能用。現在我們看到編排中有兩個鏡像：

muninn/caddy-microservice:app 這是我們上一節說的app鏡像，我們將啟動3個實例，測試上層的負載均衡。

muninn/caddy-microservice:gateway 這是我們接下來要講的gateway了，它監聽2015端口并將請求轉發給app。

用 caddy 當作 gateway

為了讓caddy當作gateway，我們主要來看一下Caddyfile:

:2015 {
    proxy / app:12345
}

好吧，它太簡單了。它監聽本機的2015端口，將所有的請求都轉發到 app:12345 。
這個app，其實是一個域名，在docker swarm的網絡中，它會被解析到這個名字服務隨機的一個實例。

將來如果有很多app，將不同的請求前綴轉發到不同的app就好啦。
所以記得寫規范的時候讓一個app的endpoint前綴盡量用一樣的。

然后caddy也需要被容器化，感興趣的可以看看Dockerfile.gateway .

運行服務端

理解了上面的內容，就可以開始運行服務端了。直接用我上傳到云端的鏡像就可以。本文用到的三個鏡像下載時總計26M左右，不大。
clone我背景章節提到的庫進入項目目錄，或者僅僅復制上文提到的compose文件存成docker-compose.yml，然后執行如下命令。

docker-compose pull
docker stack deploy -c docker-compose.yml caddy

啊，對了，第二個stack命令需要你已經將docker切到了swarm模式，如果沒有會自動出來提示，根據提示切換即可。
如果成功了，我們檢查下狀態：

docker stack ps caddy

如果沒問題，我們能看到已經啟動了3個app和一個gateway。然后我們來測試這個gateway是否能將請求分配到三個后端。

測試

我們是可以通過訪問http://{your-host-ip}:2015來測試服務是不是通的，用瀏覽器或者curl。
然后你會發現，怎么刷新內容都不變啊，并沒有像想象中的那樣會訪問到隨機的后端。

不要著急，這個現象并非因為caddy像nginx那樣緩存了dns導致均衡失敗，而是另一個原因。
caddy為了反向代理的速度，會和后端保持一個連接池。當只有一個客戶端的時候，用到總是那第一個連接呢。
為了證明這一點，我們需要并發的訪問我們的服務，再看看是否符合我們的預期。

同樣的，測試我也為大家準備了鏡像，可以直接通過docker使用。

docker run --rm -it muninn/caddy-microservice:client

感興趣的人可以看client文件夾里的代碼，它同時發起了30個請求，并且打印出了3個后端被命中的次數。

另外我還做了一個shell版本，只需要sh test.sh就可以，不過只能看輸出拉，沒有自動檢查結果。

好了，現在我們可以知道，caddy可以很好的勝任微服務架構中的 API Gateway 了。

API Gateway

什么？你說沒看出來這是個 API Gateway 啊。我們前邊只是解決了容器項目中 API Gateway 和DNS式服務發現配合的一個難題，
接下來就簡單了啊，我們寫n個app，每個app是一個微服務，在gateway中把不同的url路由到不同的app就好了啊。

進階

caddy還可以輕松的順便把認證中心做了，微服務建議用jwt做認證，將權限攜帶在token中，caddy稍微配置下就可以。
我后續也會給出教程和demo 。auth2.0我認為并不適合微服務架構，但依然是有個復雜的架構方案的，這個主題改天再說。

caddy還可以做API狀態監控,緩存,限流等API gateway的職責，不過這些就要你進行一些開發了。
你還有什么更多的想法嗎？歡迎留言。

GPU云服務器云服務器物聯網使用云平臺作為服務器直播平臺使用的api caddy 將平臺作為服務器的云計算

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/26826.html

使用 caddy 作為微服務的 API gateway

摘要：它同時也和微服務架構相互促進，并肩前行。為了反向代理的速度，會和后端保持一個連接池。好了，現在我們可以知道，可以很好的勝任微服務架構中的了。我認為并不適合微服務架構，但依然是有個復雜的架構方案的，這個主題改天再說。背景大家都知道，Docker這些年讓IT界產生了深刻的變革，從開發到測試到運維，處處都有它的身影。它同時也和微服務架構相互促進，并肩前行。在最新版的 Docker(CE...

jubincn 2019-06-24 17:53 評論0 收藏0
新興的web服務器caddy

摘要：是一個像或的服務器。得益于的特性，只是一個小小的二進制文件，沒有依賴，很好部署。我們來試試在當前目錄創建這樣一個叫的文件這次，我們改變了端口，并且啟用了自動壓縮數據。據說全世界四分之一的站點都是搭建的，而公認是世界上最好的語言。 caddy 是一個像 Apache, nginx, 或 lighttpd 的web服務器。你要問nginx已經很好了，為什么要用caddy呢? 我覺得cadd...

CollinPeng 2019-07-25 13:53 評論0 收藏0
清新脫俗的 Web 服務器 Caddy

摘要：清新脫俗的服務器作為新興服務器，提供了很多簡單易用的功能而沒有歷史的包袱，其默認支持并且能幫你自動配置，對于都有很好的支持。清新脫俗的 Web 服務器 Caddy 從屬于筆者的服務端應用程序開發與系統架構，我司之前一直使用 Nginx，不過其配置包括一些特性支持相較于 Caddy 略顯復雜，可以參考筆者的 Nginx 基本配置備忘。 showImg(https://segmentf...

alphahans 2019-07-25 13:53 評論0 收藏0
清新脫俗的 Web 服務器 Caddy

摘要：清新脫俗的服務器作為新興服務器，提供了很多簡單易用的功能而沒有歷史的包袱，其默認支持并且能幫你自動配置，對于都有很好的支持。清新脫俗的 Web 服務器 Caddy 從屬于筆者的服務端應用程序開發與系統架構，我司之前一直使用 Nginx，不過其配置包括一些特性支持相較于 Caddy 略顯復雜，可以參考筆者的 Nginx 基本配置備忘。 showImg(https://segmentf...

raledong 2019-07-24 10:36 評論0 收藏0
[譯] 用 Node.js 搭建 API Gateway

摘要：協議轉換微服務架構允許使用不同的協議以便于獲得使用不同技術的優勢。過于龐大的在實現時，應當避免將非通用邏輯如領域特定數據轉換放入其中。服務應始終對其數據域擁有完全的所有權。構建一個過于龐大的，從服務團隊爭奪控制權，這違反了微服務的理念。我們團隊的后端服務中，一開始只有一個大服務，所有的東西都往里面寫，可以想象下，當這個服務變得不斷的龐大，將會變得多么難以維護。后來逐漸把一些數據服務抽...

鄒強 2019-08-21 11:49 評論0 收藏0