Apache APISIX 在移動雲的應用

ApacheCon Asia 2021 在北京時間 8 月 6 日正式開始，在 ASF 中有多個項目與 API、微服務相關，好比 Apache APISIX、Apache Dubbo 等。在 ApacheCon Asia 2021 —— API / 微服務專題中，你們不只能夠了解有關 API、微服務的前沿技術，也會學習到這些 Apache 項目的最佳實踐，來自中國移動雲能力中心的陳焱山將在大會上分享《Apache APISIX 在移動雲對象存儲 EOS 的應用與實踐》。

最近，咱們有幸採訪了中國移動雲能力中心的陳焱山，在採訪中咱們瞭解到中國移動公有云建設發展演進歷程，明白了爲何移動云爲何選擇 Apache APISIX 做爲負載均衡網關，而且知曉移動雲後續的發展規劃。

中國移動雲能力中心，對外也稱「中移（蘇州）軟件技術有限公司」，是中國移動通訊集團 2014 年注資成立的全資子公司，公司定位爲雲設施構建者、雲服務提供者、雲生態匯聚者，三年內推進中國移動雲業務市場份額進入國內雲服務商第一陣營。自 2019 年中國移動啓動「雲改」戰略以來，做爲助力中國移動 5G+AICDE 戰略落地的基石，移動雲通過長足發展，已完成覆蓋全國的「N+31+X」總體資源佈局。同時，移動雲積極打造「雲網、雲數、雲邊、雲智」 差別化特點優點，在業務體量、產品種類、可售資源等方面均實現飛躍式提高。「移動雲」品牌也充分發揮了雲網一體、貼身服務、隨心定製、安全可控的優點，打造 5G 時代「你身邊的智慧雲」，爲行業數字化轉型發展提供「強引擎」。

Q：很是高興今天能跟陳焱山老師進行交流，能夠麻煩您作下自我介紹，簡單陳述下您如今的工做內容嗎？

你們好，我叫陳焱山，目前就任於中國移動雲能力中心 IaaS 產品部，主要負責分佈式對象存儲軟件的總體架構設計與開發工做，負責對象存儲、API 網關的技術選型與方案落地實踐工做。在分佈式存儲領域這塊仍是有比較豐富的經驗的，深度參與了移動雲的建設發展歷程。

當前，我主要關注於對象存儲在交互編排、流量治理等方面的能力，促進咱們第四代對象存儲產品進一步實現架構升級。同時，咱們也但願可以基於 Ingress Controller 的能力，來實現統一流量訪問入口，幷包括灰度發佈、流量管控等功能。這些是咱們當前正在作的一些工做。

Q：您說的這些內容多少都與 Apache APISIX 有關聯，您在今年 ApacheCon 亞洲大會上也有一場分享，想問下您會帶來哪些精彩分享?

首先，我會給你們介紹一下咱們移動雲對象存儲產品 EOS 的總體發展和演進過程，同時重點介紹咱們是如何基於 Apache APISIX 實現對象存儲流量治理的，作了哪些工做，又是如何進行實踐。最後對咱們將來的架構演進作了一些規劃說明。咱們對象存儲的總體演進過程主要經歷了以下四個階段，對於 Apache APISIX 引入主要是從第三代開始引入的，確實給咱們產品在架構上帶來不少便利。

• 第一代：從 2008 年開始投入自研，同年發佈了咱們的第一代對象對象存儲產品；
• 第二代：主要基於開源 Ceph 實現深度定製，實現了接口的標準化，支持 AWS 的 S3 標準接口和 Openstack 的 Swift 接口協議，同時豐富了大量的功能特性；
• 第三代：主要解決內部一些專業公司海量數據上雲需求。在第三代產品中，咱們在性能上實現了一個新的跨越，單一存儲桶同時支持百 PB 容量和百億對象規模，入口帶寬達到 Tb/s 級。同時，咱們還引入了不少子模塊，包括七層流量治理以及可觀測系統。七層流量治理模塊是基於 Apache APISIX 實現的，主要用於實現業務流量的分離治理；可觀測系統則主要是實現了數據的採集、告警以及日誌分析功能。
• 第四代：也是全新一代架構，支持跨區域全局糾刪功能，支持 AZ/Region 級容災。在流量治理方面，支持基於 Apache APISIX 實現的跨地域請求調度能力，支撐極致的業務連續性；同時系統可觀測性進一步提高，落地了集中化日誌分析系統。在可維護性上首次引入了自動駕駛服務和交付編排服務，可以自動有效收斂故障範圍，減輕運維壓力，實現故障隔離和自愈能力。

Q：從您的講述中能夠感覺到，這個系統不只很是龐大，並且還很是重要。對於這樣重要的系統，爲何會選擇 Apache APISIX？主要出於哪些方面的考慮呢？

是的，在技術選型初期咱們也調研過不少的 API 網關，包括 Nginx 等，不過咱們最終仍是選擇了 Apache APISIX。Apache APISIX 不只可以知足當前的業務要求，同時還能在系統可用性、可維護性上爲咱們提供比較多的思路和選擇，跟咱們的總體產品演進規劃和技術棧比較吻合。歸結起來選擇 Apache APISIX 主要基於如下幾點：

第一，內部驅動產品架構優化須要，促使咱們開始在一些技術架構上尋找更高的突破點

在 2019 年的時候，中國移動從集團層面提出了「雲改」戰略轉型，隨後咱們雲能也就成了整個移動在雲改轉型上的戰略支撐點。這也促使咱們要在產品系統架構上作進一步的優化，可以知足將來 3~5 年以上的發展須要。不只須要在功能和性能上進行提高，並且須要在可維護性、可觀測性等方面上來引入更多的組件，來保證咱們系統的穩定運行，提供可持續的、有保證的 SLA 服務等級。

第二，基於自身業務實現須要，同時 Apache APISIX 功能插件全面，業務場景匹配度高

由於自身業務對網關能力的須要，咱們經過對自有業務需求進行詳細梳理分析，這其中就包括精細化路由、內/外網隔離以及訪問控制，自動熔斷保護，跨 AZ 請求調度等場景。同時，「運維友好」，這方面 Apache APISIX 作得很是好。

你們都知道，Apache APISIX 可以友好對接 Prometheus，前面我提到的可觀測系統，它就是基於 Prometheus + Grafana + Loki 來實現的，因此之因此選擇 Apache APISIX，很重要的一點是它能與咱們現有的技術棧完美結合，這些都是咱們比較看重的。

此外另外還有一個關鍵點，這也是 Apache APISIX 與其餘網關產品的重要區別 —— 全動態加載，由於咱們更但願全部的插件、路由都可以動態的擴展，這些是 Nginx這樣的產品所不具有的。舉一個簡單的應用場景的例子：前面我有提到過咱們有一個子系統叫自動駕駛 Manager，當我後端的索引存儲空間不足時，咱們就是經過 Manager 自動使能一條默認高優先級的路由，禁用 PUT 和 POST 等功能，從而實現自動後端保護。

第三，對社區開源文化的認同感

和其餘網關產品不一樣，Apache APISIX 是 Apache 開源頂級項目，孵化時間也是最短的，足見項目的成功，產品已經被不少企業應用於生產環境下。此外不得不說社區也是十分活躍的，代碼貢獻者和使用者都很是多，與社區的溝通交流方式也不少樣化，好比 maillist，issues，QQ羣，微信羣，線上線下的 Meetup，溝通起來十分便捷且迅速有效。社區大佬也十分友好，樂於回覆你們的提問。因此咱們對 Apache APISIX 社區的將來也是很是看好的。

另外，Apache APISIX 的全產品線作得也很是好，包括 K8s Ingress Controller，以及 Service Mesh 等，雖然這些技術棧咱們當前還用不到，但我以爲社區在產品定位、發展方向上都是很是清晰的，這也給了咱們更充分的信心。

Q：就像您說的，其實 Apache APISIX 不只是但願可以知足用戶當前的需求和架構的設計，咱們更但願可以知足你們 3~5 年，甚至更長時期的架構變遷。* 如今 Apache APISIX 有跑在中國移動的一些業務系統上嗎？*

有的。從咱們的第三代對象存儲產品開始，咱們除了解決容量、性能以及擴容性的問題以外，咱們還利用 Apache APISIX 來解決咱們七層流量治理的需求。第三代對象存儲從它的研發歷程來看，先後加起來還不到半年的時間，並可以在 2020 年 7 月的時候在移動雲十期中完成上線運行，主要服務於內部的一些專業公司數據上雲的需求。主要是存儲用戶的一些攝像監控數據，因此對帶寬的要求仍是比較高的。目前總體投入生產運行已經有一年多了，從接入層到後端服務的運行狀況仍是很是平穩的，幾乎沒有出過什麼問題。

Q：在使用 Apache APISIX 的時候會作一些二次開發嗎？另外，這些二次開發的成果是否有計劃迴歸到社區呢？

二次開發是有的，並且還有很多。

針對一些通用的功能，咱們也會把他們貢獻給社區。但咱們的一些開發內容都是爲了知足一些特定業務場景，好比跨 AZ 請求調度。該功能主要是面向咱們第四代對象存儲，它是一個全局跨域的版本，支持 AZ 級容災，因此對業務的連續性要求很是高。爲了解決請求調度的一些需求，咱們在 Apache APISIX 上寫了一個 Plugin，而後去運行。

經過這個 Plugin 的請求，首先會選擇本節點上游去處理；若是本節點上游出現問題，就會轉向到本 AZ 內的其餘一些上游去進行處理。若是本 AZ 全部上游都出現故障的時候，那就直接採用跨 AZ 的請求調度處理機制。這樣一來，咱們整個業務請求的過程當中，即便出現 AZ 級的故障，請求仍是可以被正常處理。換句話說，咱們利用 Apache APISIX 作了一部分 「多活」 架構的實現。

Q：除了 Apache APISIX 現有的功能以外，大家後續還會有一些什麼樣的計劃嗎？

我以爲後續的話，咱們應該主要會圍繞這幾個方面開展。

第一，容器化編排和統一入口 由於咱們如今主要在開發第四代對象存儲，咱們正在作的事情就是實現全部組件的容器化部署編排。這中間既有數據面也有控制面，控制面咱們已是 K8s 化了，當前正在作數據面組件的容器化部署編排工做。對於外部訪問需求，咱們也在採用 Ingress Controller 來統一訪問入口。

第二，將更多的功能前置到網關層面來處理 前面我有提到，在咱們的控制面有多個子系統，後續咱們但願把流量治理與一些自動駕駛、可觀測子系統可以更多的去融合起來，經過實現故障自愈、故障隔離等功能，從而保證產品對外的訪問能力，這也就要求咱們匹配更多的業務場景能力。

另外，咱們如今的網關接入層主要是實現了流量轉發控制功能，而原來後端的認證、鑑權的那套邏輯是由業務邏輯層處理的，後續會考慮把這一部份內容統一前置到網關層面來處理。在數據遷移這塊，因爲歷史遺留問題比較多，遷移過程還不能影響業務的連續性，不過咱們也已經有了基於 Apache APISIX 的可行方案。

第三，社區代碼貢獻上要加大 咱們也會在這塊加大人員投入，與社區有着更積極的互動，參與到社區的開發當中，爲社區的發展作一些回饋，這也有利於打磨咱們的產品。

第四，推進內部技術棧的統一 目前在咱們內部還存在多種技術棧並行的狀況，同時也有多個團隊在使用 Apache APISIX 網關，後期咱們也將經過溝通，梳理業務模型，實現技術棧的統一，避免重複造輪子的狀況發生，最終實現技術棧的統一，造成統一基座能力。

Q：再次感謝陳老師，看來 Apache APISIX 在中國移動後面應該能夠適用更多的場景，發揮的更多做用了。咱們也十分期待陳老師在 ApacheCon Asia 2021 上的分享《APISIX 在移動雲對象存儲 EOS 的應用與實踐》。

咱們也期待，Apache APISIX 可讓更多的企業受益！歡迎觀看咱們往期的企業案例文章

• 基於Apache APISIX，新浪微博API網關的定製化開發之路

• 360：Apache APISIX 在基礎運維平臺項目中的實踐

  關於 Apache APISIX

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

  • Apache APISIX GitHub：github.com/apache/apis…
  • Apache APISIX 官網：apisix.apache.org/
  • Apache APISIX 文檔：apisix.apache.org/zh/docs/api…