The Evolution of Apache APISIX

COSCUP 2021 的讲稿

Transcript

1. The Evolution of Apache APISIX
2. 自我介绍 • APISIX 和 OpenResty 的核心開發者 • 給許多相關的開源項目貢獻過代碼，比如 etcd、ingress- nginx、Envoy、Tengine • 全職在做 APISIX 的開發和維護 • GitHub ID：https://github.com/spacewander/
3. “Apache APISIX 是一個動態、實時、 高性能的 API 網關，提供負載均衡、 動態上游、灰度發佈、服務熔斷、身 份認證、可觀測性等豐富的流量管理 功能。”
4. etcd
5. Why etcd • etcd 天然分佈式，容易支持 APISIX 橫向拓展 • etcd 提供了獲取給定鍵值和獲取增量更新的接口，實現全量更 新和增量更新很簡單，不需要自己額外做很多封裝工作 • 連 k8s 都敢把全部配置都放在 etcd，APISIX 的數據量肯定沒 法跟 k8s 集羣相比，我們選擇 etcd 就更有信心了
6. etcd 2.x to 3.x 2.x 3.x
7. etcd 2.x to 3.x • 默認採用 gRPC。如果需要用回之前的 HTTP 1 的接口，要開啓 gRPC-gateway，把純 HTTP 的請求代理到 gRPC server • 解決方法：頂層接口（watchdir / readdir）保持不變，用 v3 的 API 模擬 v2 的 API
8. etcd 2.x to 3.x 我們在模擬 v2 API 的時候，採用佔位符來充當 v2 API 的 dir。我們 實際存儲在 etcd 裏面的數據是這樣的： /apisix/routes/ init_dir /apisix/routes/1 {"plugins"...
9. etcd 2.x to 3.x • 默認 4MiB 的 MaxCallRecvMsgSize • “grpc: received message larger than max”
11. 多語言插件
12. • WASM 對 C 系編程語言（如 C++ 、 Rust）支持得不錯，但是對 於 Go 和 Java 的支持就不行了。舉個例子，WASM 裏面對 coroutine 的原生支持還停留在 purposal 階段，所以 Go 的協程 調度在 WASM 裏面會受到限制。 • 把 Go 代碼編譯成共享庫的 Go filter 方案： https://github.com/envoyproxy/envoy/issues/15152。這個方案也 有一些限制： 1. 沒有標準 2. Go 的協程調度依然需要額外操作
13. 重拾跨進程通訊的老路。儘管這條路有性能天花板，但是它保證用 到的技術都是成熟可靠的，不需要用戶去趟坑。
15. 選擇一種跨進程通訊方式 * SYSV 消息队列 * 共享内存 * Unix socket * pipe IO
16. 選擇一種序列化方式 * msgpack * protobuf * capnproto * flatbuffer
17. 目前我們已經實現了 Java 和 Go 兩個 Plugin Runner。這兩個 runner 還處於早期階段，歡迎大家參與進來，多多試用、一起完 善。 當然，我們並沒有完全放棄 WASM 的想法。我們還會關注 WASM 對主流語言的支持程度，包括 coroutine 的原生支持。如果時機合 適，我們會實現 WASM 版的多語言插件方案。
18. Join Us： • https://github.com/apache/apisix/ • dev@apisix.apache.org