有了 NGINX 和 Kong，爲何還須要 Apache APISIX？

2021 年 5 月，雲原生社區技術沙龍·廣州站，Apache APISIX 開源項目創始人 & PMC 王院生在活動上作了《有了 NGINX 和 Kong，爲何還須要 Apache APISIX》的分享，如下是現場分享的文字版。 如下分享僅表明做者我的觀點。

你們好，很是開心給你們分享一個讓我激動的主題《有了 NGINX 和 Kong，爲何還須要 Apache APISIX》。 之因此咱們要作 NGINX 和 Kong 的替代項目，實際和咱們後端架構演變史大背景息息相關，我會先和你們一塊兒分享後端架構演變過程，這很是重要。 首先作下自我介紹，本人叫王院生。和此次大會主辦者淨超同樣咱們都作社區好久，我在 15 年寫了一本電子書叫《OpenResty 最佳實踐》，經過這本書結成了一個超萬人社區。從那個時候開始我的對開源自己愈加感興趣，15 年之前我基本上主要是開源軟件的使用者，而後慢慢變成社區的一個協辦者，再日後變成社區領導者，也許你會問爲何？很簡單，由於這本書是你寫的，別人遇到各類各樣的問題，有高級的也有比較普通的，問得多了我就逐步成爲老師並最終成了社區領導者，像那句名言「走的人多了，也變成了路」。 2019 年我與合夥人溫銘一塊兒創辦了深圳支流科技公司，它是一家以開源爲依託的商業化公司。這家公司承載了我倆不少我的理想，也能夠說是在作每一位普通程序員的理想，不想庸庸碌碌 996，我常常對別人說個人夢想就是「把個人名字刻入史冊」，悲催的是人類已經不須要史冊了。 這是咱們團隊，你們主要是遠程協做，全部人聚在一塊兒比較難。公司早期階段只有五六我的時，還能比較容易的把團隊聚起來，但從今年以後就一直沒聚齊過，這是咱們今年到目前以來最齊的一次（但依然有幾位同窗沒能一塊兒）。 做爲一家技術說了算的商業公司，技術在我司有很是大的話語權，尊重技術從尊重技術人才開始。沒有 996 ，沒有上班打卡，遠程辦公，歡迎感興趣的同窗聯繫咱們，期待有夢想、有理想的你加入我司。 此次演講主題須要一些背景，咱們先說說後端架構演變史。先跟你們回顧一下這張圖，右圖部分從上到下它不是具體數據流程圖，它是咱們後端架構演變史。從最傳統的單體大應用，而後變成面向服務架構(SOA)，而後是微服務，分別出現了 Spring Cloud 和 Kubernetes。Spring Cloud 架構主要服務 JAVA 語言開發者，Kubernetes 是容器編排支持任何語言，以及最近社區比較熱的話題服務網格。 我常常跟公司同事說，我們展望將來五年，甚至是十年以後，哪一個架構是最終極方案？從目前信息看，服務網格會大機率勝出。即便當下它還有不少問題，但我相信這些問題都能被解決。 在創業之初，在腦子裏過這張圖的時候特別有意思。咱們可以看到，隨着咱們後端架構的逐步迭代，咱們引入了各類不一樣組件。好比到了 SOA 也就是面向服務的架構，引入反向代理組件，選型一般是 NGINX，HAProxy。迭代到微服務架構後，一般會選擇一些更現代的 API 網關產品，好比 Kong、Traefik ，固然也有一些用戶由於慣性習慣，還會繼續選擇使用 NGINX，雖然它有能力弱、使用不方便等缺點，但勝在穩定、可靠。說句題外話，從全球市場佔有率看，NGINX 成爲佔有率最高的 Web Server 是在 2019 年 4 月份，感興趣的同窗能夠到看下最新的 netcraft 報告 April 2021 Web Server Survey。

隨着後端架構持續迭代，進入到了 Kubernetes 時代後，流量出入口 Ingress 你們默認會使用官方的 Kubernetes Ingress，這個項目是基於 NGINX 本地配置文件。在國內也有一些公司在使用 Traefik 做爲 Ingress，這與國內 Golang 開發者基數比較大有很大關係。

咱們再看看左側比較有意思的 JAVA ，Spring Cloud 內置 API 網關前後經歷了 ZUUL、ZUUL2，但仍是很差用，性能、架構官方都不滿意，因此 Spring Cloud 官方發起了新項目 Spring Cloud Gateway，最終造成全家桶解決方案。

最後說說右下角部分的服務網格，對於服務網格已經造成一種選擇就是 istio(CP) + envoy(DP)。後面咱們又看到了阿里巴巴開源的 mosn，一句話歸納：Golang 版本的 envoy。

回顧前面的架構演變圖，相信不少同窗都已經發現問題在哪裏。從上到下，從左到右，針對不一樣場景，咱們最終「合理」的引入了各類組件來分別解決咱們的問題，架構師生存法則：選擇當下最適合的。

當咱們趁手工具很少，在功能、動態、性能等之間咱們老是要妥協放棄一些，你們早已習慣甚至麻木。IT 技術發展迅速，時至今日它們是否仍是最合適方案？5G、物聯網等發展迅速，如何彈性擴縮容、動態統一管理等新問題，逼着咱們從新思考。

如圖這些都是 NGINX 缺點，好比 NGINX 的低活躍度社區。雖然咱們能夠在公司層面投入更多資源，但他的社區是真不友好，不友好到什麼程度呢？上面這張圖能夠看獲得，NGINX 在 Github 的倉庫只是鏡像，issue 功能是關閉的，想提交 issue 不可能了，即便你提交 PR 官方也是不會合並的。

除此以外 NGINX 自身路由比較弱，好比說我要根據某個請求參數好比 id 取模運算作灰度，你會發現 NGINX 徹底沒法實現。因此咱們能看到不少小的開源系統，只要解決了上面的灰度場景，就能夠是個獨立開源項目。此外 gRPC 調用在微服務調用中愈來愈流行，但 NGINX 對它的支持只能是「簡單能用」。

最後就是 NGINX 集羣統一管理，幾乎每家互聯網廠商都有本身的 NGINX 配置管理系統，系統雖然大同小異但就是沒有統一方案，十幾年了一直空白。

在進一步聊 Kong 以前，想和你們聊一下什麼是雲原生。這個名詞從誕生到如今好久，但到如今沒有統一明確的定義。我綜合幾家雲廠商定義，歸納雲原生特徵主要有兩點：第一要支持容器，第二要支持彈性伸縮部署。我認爲 Kong 不徹底知足第二條，官方主推的 PostgreSQL 關係型數據庫是單點，沒法支持彈性擴縮容，是它架構選型硬傷。

最後簡單總結一下 NGINX 和 Kong 的問題：

• NGINX 和 Kong 都有各自不一樣應用場景；

• NGINX 缺乏官方集羣統一管理方案；

• Kong 的控制面不是徹底雲原生架構。

在介紹 APISIX 以前，仍是有必要先感謝兩位前輩，站在巨人肩膀思考，確實讓咱們從一開始就有更高起點。APISIX 已經兩歲多，請看架構圖：

這張圖的左右分別是 DP（Date Plane）和 CP（Control Plane），跟你們所熟悉的後端服務體系同樣。APISIX 從架構第一天就沒有想去本身造新東西，因此關於配置中心選擇了當下最成熟的 etcd。

在這個架構裏面，你找不到一個單點。這裏的任何一個服務出現異常宕機等事故，都不會影響 APISIX 正常對外提供服務的能力。當總體架構中的每個點都支持高可用時，用戶生產系統的高穩定性就很是容易實現。

這是 APISIX 的生態圖，從該圖能夠準確看到目前都支持了哪些周邊生態。左側是支持的協議，能夠看到常見的 7 層協議有 HTTP(S)、HTTP二、Dubbo、QUIC 和物聯網協議 MQTT 等，4 層協議有 TCP/UDP 。右側部分則是一些開源或者 SaaS 服務，好比 SkyWalking、Prometheus 、Vault 等。下面就是一些比較常見的操做系統環境、雲廠商和硬件環境，做爲一家全球化公司，咱們也支持 ARM64 等更豐富的平臺。

給你們簡單地彙報一下 APISIX 當前狀態，APISIX 從開源到如今兩年的時間，APISIX 已經成爲了全世界最活躍的開源 API 網關項目，並且這個狀態已經持續了一年多。請記住最下面一句話，APISIX 已經生產可用，功能、性能、架構全面優於 Kong。在 2019 年 9 月份貝殼找房就已經把 APISIX 項目用到生產環境。

簡單解釋一下這張圖，能夠叫它貢獻者增加曲線。橫座標是時間線，縱座標是貢獻者總數。可以看到 APISIX 和 Kong 這兩個項目相對更活躍，APISIX 的增加速度從開源第一天就保持着很是不錯的增加率，在接近 Kong 兩倍的速度成長，可見 APISIX 受歡迎程度。固然評價一個項目活躍度還有不少其餘方法，好比查看每個月活躍 issue、PR 總數等方式，很開心的和你們說，這些方式看 APISIX 的活躍度依然第一。

通過咱們實際的客戶走訪，支持多語言這個特性是很是有必要的。畢竟對於不少公司而言，都有本身熟悉的技術棧，不少公司對 NGINX C 和 Lua 這兩個技術棧是空白。前些日子 APISIX 已經正式宣佈支持多語言，目前已經支持了 Java 語言，後續也將逐步支持 Golang 、Rust、NodeJS 等語言。

APISIX 的全動態、高性能，其實和高質量的周邊生態是分不開的。APISIX 的路由使用我司主導並開源的項目叫 resty-radixtree ，簡單來講它使用 radixtree 方式完成路由匹配，匹配效率相比競品提高了一到兩個數量級。其餘還有 jsonschema、ipmatcher 等周邊庫，它們都比同類開源項目性能強幾個數量級。

APISIX 支持多語言的特性，已經放到開源項目，歡迎感興趣的同窗能夠隨時關注並參與。這個實現方案的優點是簡單、通用，你們能夠原生的使用本身熟悉語言。

聊了這麼多，給你們介紹下 APISIX 有哪些優點？請看上圖。

前面三個（基金會項目、安全、穩定）我以爲是最重要的，做爲基金會項目，它已經不屬於某我的或某家公司，而是全人類的財產，咱們能夠永遠使用它。與之相對應的是商業公司開源項目，它能夠隨時修改開源項目 License，你們最近都聽過相似的消息。APISIX 的安全和穩定得益於它的基石 NGINX，可以成爲目前最流行、使用量最廣的 web server，底蘊仍是很厲害的。

高性能、動態、社區活躍是 APISIX 的王牌，它們已經造成了良性互動。

若是一句話歸納 APISIX 的自豪，我認爲是：APISIX，全世界最活躍的 API 網關項目。在此共識下，咱們把更多資源傾斜給社區，咱們相信社區會讓 APISIX 穩健健康成長。

看到這張圖臺下的你估計一會兒就明白了 APISIX 要幹什麼。APISIX 目標：統一代理基礎設施。

也許臺下的你這裏會有疑問：APISIX 要支持這麼多場景，是否會讓 APISIX 變得四不像？這裏我簡單解釋一下，APISIX 的核心是高性能代理服務，自身不綁定任何環境屬性。當它演變爲 Ingress、服務網格等產品，都是外部服務與 APISIX 配合，變化的是外部程序而不是 APISIX 自身，後面逐步爲你們說明 APISIX 是如何具體支持這些場景。

針對傳統的 LB 和 API Gateway 場景，APISIX 比較大的優點就是從靜態變成所有動態，不再須要 reload，要知道不少科技公司的 NGINX reload 是半小時起步。前面提到的根據請求 id 取模運算灰度場景，在 APISIX 裏使用精細化路由能夠很容易完成。

APISIX Ingress Controller 則完整解決了上面提到的全部問題，繼承了 APISIX 的全部優點，此外還支持原生 k8s CRD ，方便用戶遷移。

服務網格，這裏面有必要跟你們重點聊聊。將來五年或者十年以後，最有可能主流的服務端架構是什麼？若是讓我回答，我選擇服務網格。

右圖部分就是 APISIX Mesh 的內部架構圖。

聊了這麼多 APISIX 的當下，也和你們聊聊 APISIX 的將來。

由於 APISIX 目前是 Apache 基金會項目，因此它已經再也不屬於我的或公司，而是全人類共享財產。這樣社區中的每個你，都有權利決定他往哪一個方向發展。

開源版本 APISIX 目前默認搭配的配置中心是 etcd ，雖然目前它依舊是最好的選擇，但咱們在和用戶溝通時依然常常會聽到是否支持其餘配置中心，比較常見的緣由是 etcd 這個產品太新了，公司現有運維產品支持列表中沒有它。因此咱們計劃讓 APISIX 能夠與其餘配置中心協做。

APISIX 已經走在全流量數據面這條路上，相信你們都會問一些問題，好比：爲何要統一流量轉發？統一是否給企業帶來價值？對技術人員有什麼收益？帶着這些問題，咱們看下圖：

統一自己不是目標，統一以後的收益纔是咱們追求的背後邏輯，下面分別給出幾個不一樣角度來分別闡述。

• 運維角色：使用相同的運維工具收集日誌、Metric 指標等，複用已有積累；

• 開發角色：基於標準化的 APISIX 插件開發，能力能夠方便複用，而且積累的經驗能夠應用到 LB、API Gateway、K8s Ingress 等不一樣產品線；

• 公司價值：統一技術棧，下降公司運營成本，下降過渡到微服務、雲原生的難度，加速企業數字化轉型。

關於 Apache APISIX

Apache APISIX 是一個動態、實時、高性能的開源 API 網關，提供負載均衡、動態上游、灰度發佈、服務熔斷、身份認證、可觀測性等豐富的流量管理功能。Apache APISIX 能夠幫忙企業快速、安全的處理 API 和微服務流量，包括網關、Kubernetes Ingress 和服務網格等。 全球已有數百家企業使用 Apache APISIX 處理關鍵業務流量，涵蓋金融、互聯網、製造、零售、運營商等等，好比美國航空航天局（NASA）、歐盟的數字工廠、中國航信、中國移動、騰訊、華爲、微博、網易、貝殼找房、360、泰康、奈雪的茶等。 200 餘位貢獻者，一同締造了 Apache APISIX 這個世界上最活躍的開源網關項目。聰明的開發者們！快來加入這個活躍而多樣化的社區，一塊兒來給這個世界帶來更多美好的東西吧！

• Apache APISIX 項目地址：github.com/apache/apis…
• Apache APISIX 官網：apisix.apache.org