使用 caddy 作為微服務的 API gateway

jubincn 發(fā)布于2019-06-24 17:53 / 1093人閱讀

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

背景

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

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

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

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

有一個配置文件上的小Hack可以實現(xiàn)Nginx每次去查詢DNS，我本來準備寫一篇文章來著，
現(xiàn)在看來不用了，我們找到了更優(yōu)雅的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鏡像中。大家可以不必在意這些細節(jié)。
我們還是先來看看最終的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命令。
總之現(xiàn)在這個版本在編排方面還沒有完全整合好，有點暈，不過能用。現(xiàn)在我們看到編排中有兩個鏡像：

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

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

用 caddy 當作 gateway

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

:2015 {
    proxy / app:12345
}

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

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

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

運行服務端

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

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

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

docker stack ps caddy

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

測試

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

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

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

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

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

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

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

API Gateway

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

進階

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

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

云服務器 GPU云服務器物聯(lián)網(wǎng)使用云平臺作為服務器直播平臺使用的api caddy 將平臺作為服務器的云計算

文章版權歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。

轉(zhuǎn)載請注明本文地址：http://www.ezyhdfw.cn/yun/11775.html

使用 caddy 作為微服務的 API gateway

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

Lemon_95 2019-06-28 15:40 評論0 收藏0
新興的web服務器caddy

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

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

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

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

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

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

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

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