使用 caddy 作為微服務(wù)的 API gateway

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

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

背景

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

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

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

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

有一個(gè)配置文件上的小Hack可以實(shí)現(xiàn)Nginx每次去查詢DNS，我本來準(zhǔn)備寫一篇文章來著，
現(xiàn)在看來不用了，我們找到了更優(yōu)雅的API gateway, Caddy 。
我上篇文章也寫了一個(gè)它的簡介。

接下來的所有代碼，都在這個(gè)demo中，
你可以clone下來玩，也能在此基礎(chǔ)上做自己的實(shí)驗(yàn)。

應(yīng)用

我們先用golang寫一個(gè)最簡單的HTTP API，你可以用你會(huì)的任何語言寫出來，
它為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 化

我們需要把上面的應(yīng)用做成一個(gè)docker鏡像，暴露端口12345。
接著才有可能使用Docker Swarm啟動(dòng)成集群。
本來做鏡像特別簡單，但我為了讓大家直接拉鏡像測試時(shí)快一點(diǎn)，用了兩步構(gòu)建，
先編譯出應(yīng)用，然后添加到比較小的alpine鏡像中。大家可以不必在意這些細(xì)節(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命令啟動(dòng)，而是要用docker stack deploy命令。
總之現(xiàn)在這個(gè)版本在編排方面還沒有完全整合好，有點(diǎn)暈，不過能用?，F(xiàn)在我們看到編排中有兩個(gè)鏡像：

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

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

用 caddy 當(dāng)作 gateway

為了讓caddy當(dāng)作gateway，我們主要來看一下Caddyfile:

:2015 {
    proxy / app:12345
}

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

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

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

運(yùn)行服務(wù)端

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

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

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

docker stack ps caddy

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

測試

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

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

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

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

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

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

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

API Gateway

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

進(jìn)階

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

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

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

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

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

發(fā)表評論

登陸后可評論

0條評論

jubincn

男|高級講師

我要關(guān)注我要私信

TA的文章

#yyds干貨盤點(diǎn)#安全漏洞頻出，信息系統(tǒng)中安全防護(hù)如何有效構(gòu)建？

閱讀 3559·2021-11-22 15:11
測評racknerd雙11促銷款VPS，看看近期的racknerd到底如何

閱讀 4634·2021-11-18 13:15
如何閱讀《JavaScript高級程序設(shè)計(jì)》（一）

閱讀 2702·2019-08-29 14:08
symbol

閱讀 3576·2019-08-26 13:49
關(guān)于NaN

閱讀 3091·2019-08-26 12:17
awesome-typescript-loader報(bào)watchRun問題

閱讀 3288·2019-08-26 11:54
ES6 class繼承與super關(guān)鍵詞深入探索

閱讀 3111·2019-08-26 10:58
運(yùn)算符比較運(yùn)算符

閱讀 2031·2019-08-26 10:21

国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

上云采購季！| 2核2G4M爆款云服務(wù)器低至59元/年，更有多臺、長期優(yōu)惠，快來選購！

使用 caddy 作為微服務(wù)的 API gateway

相關(guān)文章