caddy 作為微服務的 API gateway

**：

大家都知道，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 .

func main()我們需要把上面的應用做成乙個docker映象，暴露埠12345。

接著才有可能使用docker swarm啟動成集群。

本來做映象特別簡單，但我為了讓大家直接拉映象測試時快一點，用了兩步構建，

先編譯出應用，然後新增到比較小的alpine映象中。大家可以不必在意這些細節。

我們還是先來看看最終的docker-compose.yml編排檔案吧。

version: '3'

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

總之現在這個版本在編排方面還沒有完全整合好，有點暈，不過能用。現在我們看到編排中有兩個映象：

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

:2015

docker-compose pull

docker stack deploy -c docker-compose.yml caddy

如果成功了，我們檢查下狀態：

docker stack ps caddy

然後你會發現，怎麼重新整理內容都不變啊，並沒有像想象中的那樣會訪問到隨機的後端。

不要著急，這個現象並非因為caddy像nginx那樣快取了dns導致均衡失敗，而是另乙個原因。

caddy為了反向**的速度，會和後端保持乙個連線池。當只有乙個客戶端的時候，用到總是那第乙個連線呢。

為了證明這一點，我們需要併發的訪問我們的服務，再看看是否符合我們的預期。

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

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

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

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

caddy還可以輕鬆的順便把認證中心做了，微服務建議用jwt做認證，將許可權攜帶在token中，caddy稍微配置下就可以。

我後續也會給出教程和demo 。auth2.0我認為並不適合微服務架構，但依然是有個複雜的架構方案的，這個主題改天再說。

caddy還可以做api狀態監控,快取,限流等api gateway的職責，不過這些就要你進行一些開發了。

微服務 關於微服務的思考

通過kafka進行日誌收集，並結合elk進行日誌聚合 並通過日誌展示平台進行管理 引入elasticsearch 將所有微服務的資料庫需要查詢的資料同步到es中，增刪改仍然保持原有的mybatis運算元據庫 目前微服務之間的呼叫 bff呼叫基礎服務 使用的是rest請求方式，本質上還是http協議，...

作為web微服務的科學計算視覺化

今天閱讀 vis 2019 會議大資料與降維領域的 scientific visualization as a microservice 作者是田納西大學電氣工程與電腦科學系的mohammad raji alok hota tanner hobson 和 jian huang。傳統的科學視覺化通常是...

微服務 服務的拆分

我在思考乙個問題 我們為什麼要搞微服務，整體式服務就不能滿足嗎？為什麼一定要用微服務呢？服務的粒度拆的約來越細呢？當我們的業務複雜之後，設計乙個系統難度會加大，還要適應快速迭代，就更難了。將業務的功能拆分之後，會讓每個模組的設計變得簡單。對於需求的變更，採用增加 修改模組的方式來實現也比較方便。但是...