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 里做流量管理的控制。