基於 Apache APISIX 的下一代微服務架構

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 可以幫助用戶處理 L四、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 裏作流量管理的控制。

以上是我今天的所有分享，謝謝你們！

演講視頻觀看及PPT下載：

基於 Apache APISIX 的下一代微服務架構