2019 年 12 月 14 日，又拍雲聯合 Apache APISIX 社群舉辦 API 閘道器與高效能服務最佳實踐丨Open Talk 廣州站活動，Apache APISIX PPMC 溫銘做了題為《Apache APISIX 的 Apache 之路》的分享。本次活動，邀請了來自ApacheAPISIX、又拍雲、騰訊雲、HelloTalk 等企業的技術專家，分享閘道器和高效能服務的實戰經驗。

溫銘，深圳支流科技創始人，Apache APISIX PPMC，《OpenResty 從入門到實戰》專欄作者，創業之前在網際網路安全公司工作了 10 年，主要從事服務端的開發和架構，負責開發過木馬雲查殺、反釣魚系統和企業安全產品。曾在奇虎 360 擔任架構師，開源委員會發起人、委員。支流科技是一家開源底層技術初創公司，致力於微服務相關技術的創新和實現。

下面我會從以下幾個方面介紹今天的主題：

• Apache APISIX 是什麼，能解決什麼問題

• 回顧微服務是怎麼從單體變成現在的 Service Mesh

• 介紹 Service Mesh 是銀彈嗎，以及我眼裡的下一代微服務架構

Apache APISIX

簡單來說 Apache APISIX 是一個微服務 API 閘道器，它不僅可以處理南北向的流量，也可以處理東西向的流量即服務之間的流量。很多 API 閘道器的資料庫可能是 postgreSQL、mysql 等，它在雲原生的環境下需要幾秒鐘才能啟動，而作為 sidecar 也特別重，我們希望 Apache APISIX 在容器裡面能夠很輕巧地、毫秒級別地啟動，和 K8S 的技術棧很接近，基於 Nginx 和 etcd 來實現。

Apache APISIX 集成了控制面板和資料面，與其他 API 閘道器相比，Apache APISIX 的上游、路由、外掛全是動態的，修改這些東西時都不用重啟。並且 Apache APISIX 的外掛也是熱載入，可以隨時插拔、修改外掛。

Apache APISIX 今年快速地成長，從 6 月 6 日開源，7 月被納入 CNCF 全景圖，8 月迎來首家付費央企，9 月份貝殼找房上生產環境，每日處理近 5 億流量。10 月進入 Apache 孵化器，是國內唯一由初創公司貢獻的專案，11 月全面支援 ARM64 平臺，並推出 apisix-ingress-controller，擁有動態路由的能力，解決了官方 K8S 的一些痛點。

上圖是目前 Apache APISIX 的部分使用者，NASA（美國的航空航天局）也在使用 Apache APISIX，而且是在一個很重要的地方——火箭推進實驗室，包括探月專案、火星探測的專案都是在這個實驗室做的，他們使用 Apache APISIX 去處理微服務之間和南北向之間的流量。

Apache APISIX 的功能和作用

API 閘道器的傳統功能包括反向代理、負載均衡、動態 SSL 證書、動態限流限速、主動/被動健康檢查、服務熔斷等功能，這些功能 Nginx 也同樣具備。

在雲原生的架構下，會衍生出很多新的功能需求：

• 對接更多的監控和鏈路追蹤，希望 API 和微服務之間的流量做到視覺化，如 Prometheus、Zipkin、Skywalking

• gRPC 代理和協議轉換（REST <=> gRPC）、websocket

• 身份認證：OpenID Relying Party、OP（Auth0、okta…）

• Serverless

• 高效能、無狀態、隨意擴容和縮容

• 支援多雲、混合雲

• 容器優先，Kubernetes 友好

效能上，Apache APISIX 比空轉的 OpenResty 效能只低了 15%，在我們下一個商業版本里，即使有外掛的邏輯存在，也會保持和 OpenResty 空轉的效能相同，這裡有我們的一些黑科技在裡面。

Apache APISIX 能夠幫助使用者處理 L4、L7 層流量：HTTP、HTTPS、TCP、UDP、MQTT、Dubbo、gRPC、TLS…如果使用者有自定義的 4 層RPC 協議也可以實現。

Apache APISIX 可以替代 Nginx，把它從一個靜態的配置檔案管理的伺服器變成一個純動態的 API 控制的 Web 伺服器。也可以用 Apache APISIX 替代 Envoy 處理服務間的東西向的流量，它會更加高效且穩定。

此外，你也可以把 Apache APISIX 作為 k8s ingress controller ；基於靈活的外掛，提供了 MQTT 的外掛可以作為 IoT 閘道器，藉助 IdP 外掛成為零信任閘道器。我們希望 Apache APISIX 能夠快速處理所有業務的流量。

微服務演進史

我們先來回顧微服務的演進史，回顧歷史才能更好地知道未來做什麼。

• 從單體到微服務

如上圖，這其實是一個單體，下面有 3 個服務，3 個服務分別做了 3 件不同的事，但它們裡面有很多重複的功能，比如限流限速、身份認證等，是每個介面都要做的。每個 API 做了很多與業務不關但是又不得不做的事情。這種模式的痛點是做了大量的重複開發，如果在容器裡面跑，不僅重，修改起來也麻煩，並且一旦把限流限速的邏輯修改了，那麼每個服務都要修改。

API 閘道器的作用就是把業務無關的功能剝離出來，讓你的 API 只關心業務本身，與業務無關的功能全都丟給 API 閘道器，包括協議的轉換、限流限速、安全、統計、可追蹤、快取、日誌報表等。如此，業務才能跑得更快，這就是為什麼微服務會從單體變成 API 閘道器的架構。

• 微服務從類庫到 proxy

很多 Java 工程師微服務架構會選擇 Spring Cloud 或者 Dubbo， 這種是語言繫結的，它用類庫的方式放在程式碼裡，升級困難，如果團隊是多語言就需要維護多個類庫，假設你有 10 個版本，10 個語言，就需要維護 100 個類庫。

這裡可以使用 proxy 的方式來解決，即 API 閘道器，它用代理的方式把多版本和多語言的問題解決了。

• 微服務從 proxy 到 sidecar

很多 proxy 都是基於 Nginx 來實現的，眾所周知 Nginx 所有的功能都是根據配置檔案實現的，因此 proxy 存在路由、上游、證書等不能動態的痛點。在 K8S 體系下，上游與證書經常會發生變化，如果使用 Nginx 來處理就需要頻繁重啟服務，因此我們就拋棄了 proxy 的方式，轉而採用 sidecar 的模式，即 Service Mesh。

服務對 Sidecar 是無感知的，進來的流量和出去的流量都會被邊車劫持。API 閘道器做的與業務無關的功能，都在邊車裡面來實現。簡單地來說，把 API 閘道器打橫了，其實就變成了邊車，功能基本相同，區別就在於一個是處理南北向流量，一個處理東西向流量，

• 從 sidecar 到 Service Mesh

如果只是簡單的邊車，它還不夠通用，並且抽象的層次也不足，因此有了 Service Mesh 想作為基礎設施下沉到每個服務旁邊。在此之前，邊車其實是可選的，但是在 Service Mesh 裡邊車是一個必選項，Istio 和 Envoy 一個做控制面，一個做資料面，掛在每個服務旁邊。

但是這種方式也是存在問題的，每個微服務都要帶 sidecar，如果做多次流量轉發，效能是有問題的，Istio 和 Envoy 經常會被大家吐槽效能的問題和穩定性。

下一代微服務

我認為 sidecar 的模式到最後也會消失，它會變成一個可選項，而非在 ServiceMesh 裡的必選項。我們希望通過 Apache APISIX 把 sidecar 從微服務的邊車模式抽取出來，使用者可以部署一個或多個 APISIX，可以和微服務部署在同一臺機器上，也可以分開部署，走向中心節點或者叢集的模式。我們認為下一代的閘道器可以替代掉 Service Mesh，因為大家解決使用者的問題是一樣的，包括服務治理、流量管理、及時動態感知變化等。

Apache APISIX 能夠做到全動態、全協議支援、高效能、雲原生友好。我們希望 Apache APISIX 不僅能把 Nginx 的南北向流量吃掉，同時把微服務東西向的流量吃掉，我們也希望 Apache APISIX 不僅能做 API 閘道器，也能做 k8s ingress controller，更可以在 Service Mesh 裡做流量管理的控制。

推薦閱讀

從 0 到 1：Apache APISIX 的 Apache 之路

說說 WebSocket，3 分鐘讓你全面認識