作者：董紅帥拦英，馬蜂窩微服務(wù)體系建設(shè)以及基礎(chǔ)服務(wù)能力建設(shè)專家迫靖。

馬蜂窩作為旅行社交平臺(tái)院峡，是數(shù)據(jù)驅(qū)動(dòng)的新型旅行電商∠狄耍基于十余年的內(nèi)容積累照激，馬蜂窩通過(guò) AI 技術(shù)與大數(shù)據(jù)算法，將個(gè)性化旅行信息與來(lái)自全球各地的旅游產(chǎn)品供應(yīng)商實(shí)現(xiàn)連接盹牧，為用戶提供與眾不同的旅行體驗(yàn)俩垃。

隨著業(yè)務(wù)的發(fā)展励幼，馬蜂窩架構(gòu)也在跟隨技術(shù)步伐進(jìn)行更迭，開(kāi)始基于 Kubernetes 進(jìn)行更多的延展口柳。在這個(gè)技術(shù)背景下苹粟，需要針對(duì)云服務(wù)開(kāi)啟新一輪的架構(gòu)更新，比如：微服務(wù)場(chǎng)景建設(shè)新的蜂效平臺(tái)及周邊設(shè)施來(lái)支持迭代和流量泳道的能力跃闹，在多 Kubernetes 集群場(chǎng)景引入 Karmada 實(shí)現(xiàn)多集群管理嵌削，在微服務(wù)網(wǎng)關(guān)領(lǐng)域?qū)?Istio + Envoy 的架構(gòu)替換為 Apache APISIX 與 Envoy 共存的微服務(wù)網(wǎng)關(guān)模式。

微服務(wù) 1.0 模式現(xiàn)狀

目前馬蜂窩內(nèi)部的微服務(wù)架構(gòu)經(jīng)歷了兩次迭代辣卒，本文中將針對(duì)原有架構(gòu)的第一次調(diào)整定義為 1.0 版本掷贾。在進(jìn)行微服務(wù) 1.0 架構(gòu)的搭建之前，我們從發(fā)布系統(tǒng)能力荣茫、Kubernetes 容器、服務(wù)發(fā)現(xiàn)和微服務(wù)網(wǎng)關(guān)等角度進(jìn)行了一些考量與目標(biāo)對(duì)齊场靴。比如 Kubernetes 的廣泛應(yīng)用啡莉，需要開(kāi)始考慮基于容器做多語(yǔ)言支持，在 CI/CD 環(huán)節(jié)實(shí)現(xiàn)全面容器化旨剥，并支持多 Kubernetes 集群等咧欣。

在進(jìn)行第一次迭代之前，內(nèi)部架構(gòu)的微服務(wù)網(wǎng)關(guān)使用的是 NGINX Ingress轨帜，但它其實(shí)是存在問(wèn)題的魄咕。比如配置變更基于 NGINX reload，會(huì)造成業(yè)務(wù)有損蚌父；同時(shí)在應(yīng)用范圍內(nèi)僅支持單 Kubernetes 集群哮兰，場(chǎng)景受限；內(nèi)置資源過(guò)于簡(jiǎn)單苟弛，大量匹配規(guī)則依賴 Annotations喝滞，配置繁雜不友好，尤其是對(duì)外部服務(wù)發(fā)現(xiàn)能力支持很弱膏秫。

因此在進(jìn)行微服務(wù) 1.0 迭代落地的過(guò)程中右遭，為了滿足一些業(yè)務(wù)需求，我們進(jìn)行了如下動(dòng)作（選取部分操作列舉）：

• 在 Kubernetes 容器內(nèi)缤削，基于 macvlan 改造容器網(wǎng)絡(luò)窘哈，IDC 機(jī)房網(wǎng)絡(luò)與云廠商網(wǎng)絡(luò)互通（容器互通的通信基礎(chǔ)）；借助網(wǎng)關(guān)或容器直連實(shí)現(xiàn)服務(wù)互訪亭敢，不再使用 Kubernetes Service滚婉。
• 基于 Kubernetes 容器場(chǎng)景部署；基于 Consul 物理機(jī)虛擬機(jī)部署吨拗。
• 增加統(tǒng)一服務(wù)發(fā)現(xiàn)能力满哪，基于 Kubernetes婿斥、Consul 建設(shè)統(tǒng)一的發(fā)現(xiàn)中心 — Atlas；同時(shí)基于 Atlas 擴(kuò)展微服務(wù)網(wǎng)關(guān)哨鸭、Java 生態(tài)民宿、監(jiān)控體系等。
• 在微服務(wù)網(wǎng)關(guān)的選擇上像鸡，基于 Istio + Envoy 架構(gòu)進(jìn)行構(gòu)建活鹰。對(duì) Istio 中 Pilot 進(jìn)行二次開(kāi)發(fā)，對(duì)接 Atlas 發(fā)現(xiàn)中心只估，由于 Atlas 數(shù)據(jù)來(lái)源于多套 Kubernetes 和 Consul志群，進(jìn)而將實(shí)例發(fā)現(xiàn)與 Kubernetes 集群解耦，間接做到網(wǎng)關(guān)對(duì)接多 Kubernetes 集群的能力蛔钙，實(shí)現(xiàn)整個(gè)網(wǎng)關(guān)動(dòng)態(tài)感知識(shí)別的變化锌云。

蜂效 1.0 微服務(wù)網(wǎng)關(guān)架構(gòu)

痛點(diǎn)梳理

在微服務(wù) 1.0 的這套架構(gòu)中，實(shí)踐下來(lái)還是存在一些痛點(diǎn)吁脱。

首先是在發(fā)布系統(tǒng)能力方面桑涎，微服務(wù) 1.0 中的發(fā)布系統(tǒng)，僅僅是一個(gè)發(fā)布系統(tǒng)兼贡，無(wú)法有效融合項(xiàng)目需求的管理（發(fā)布也是度量的一環(huán)）攻冷；同時(shí)這套發(fā)布系統(tǒng)基于 PHP 構(gòu)建，無(wú)法很好地支持自動(dòng)化滾動(dòng)部署遍希、多版本滾動(dòng)部署容量變更等較為復(fù)雜的部署場(chǎng)景等曼；當(dāng)多人對(duì)同一個(gè)項(xiàng)目開(kāi)發(fā)，或一個(gè)需求關(guān)聯(lián)多個(gè)項(xiàng)目時(shí)凿蒜，缺少機(jī)制讓流量在同一個(gè)迭代中自動(dòng)串聯(lián)（流量泳道）禁谦。同時(shí)對(duì)多 Kubernetes 集群管理并不方便，當(dāng) Kubernetes 下線時(shí)需要業(yè)務(wù)側(cè)參與篙程，給業(yè)務(wù)線帶來(lái)了時(shí)間成本等枷畏。

其次就是微服務(wù)網(wǎng)關(guān)架構(gòu)層面。前文也提到了 1.0 架構(gòu)下網(wǎng)關(guān)是基于 Istio+Envoy 對(duì) Pilot 做了二次開(kāi)發(fā)虱饿，主要是對(duì)接 Atlas 發(fā)現(xiàn)中心拥诡。隨著業(yè)務(wù)的應(yīng)用數(shù)量越來(lái)越多，訪問(wèn)規(guī)則也越來(lái)越多氮发，這就導(dǎo)致我們線上的網(wǎng)關(guān)生效延遲也越來(lái)越高渴肉。在流量巔峰狀態(tài)下，大概有 15 秒左右的延遲爽冕。這個(gè)延遲主要來(lái)自于 CRD 資源仇祭，幾乎全都在相同的 namespace 下，同時(shí)上下線時(shí)會(huì)觸發(fā)全量更新導(dǎo)致延遲較高颈畸。

而在早期的使用過(guò)程中乌奇，Envoy 在數(shù)據(jù)全量推送過(guò)程中還會(huì)出現(xiàn)鏈接中斷的狀況没讲，造成 503 問(wèn)題的產(chǎn)生。除此之外礁苗，Envoy 還存在使用內(nèi)存持續(xù)增長(zhǎng)導(dǎo)致 OOM 的情況爬凑，當(dāng)網(wǎng)關(guān)出現(xiàn)問(wèn)題時(shí)，對(duì) Envoy 和 Pilot 進(jìn)行排錯(cuò)的成本較高试伙。當(dāng)使用一些高階配置時(shí)嘁信，需要借助 Envoy Filter 實(shí)現(xiàn)，其上手門檻較高疏叨，對(duì)于想簡(jiǎn)單實(shí)現(xiàn)熔斷潘靖、限流、Auth 鑒權(quán)等功能而言蚤蔓，成本較高卦溢。

除此之外，兩個(gè)社區(qū)（Istio 和 Envoy）的發(fā)展速度很快秀又，這也導(dǎo)致我們的架構(gòu)比較難跟進(jìn)上游社區(qū)的發(fā)展既绕。

基于 APISIX 的微服務(wù) 2.0 模式

新平臺(tái)與新架構(gòu)

面對(duì) 1.0 架構(gòu)下存在的痛點(diǎn)與問(wèn)題，內(nèi)部對(duì)于這套微服務(wù)架構(gòu)進(jìn)行了再次迭代涮坐，來(lái)到了 2.0 時(shí)代。2.0 架構(gòu)場(chǎng)景下誓军，我們新增了一套發(fā)布平臺(tái)——蜂效平臺(tái)袱讹。

蜂效平臺(tái)重點(diǎn)突出了以下能力：

• 融合了需求管理，支持了迭代部署能力昵时，使得發(fā)布系統(tǒng)可以增益度量捷雕。
• 將容器部署和機(jī)器部署（物理機(jī)部署）在產(chǎn)品能力上進(jìn)行了統(tǒng)一。
• 增強(qiáng)了精細(xì)化的流量管理能力壹甥、回滾能力（回滾策略：批次救巷、實(shí)例數(shù)、間隔等）
• 與 Java 生態(tài)融合共建句柠，支持了流量泳道能力浦译，環(huán)境流量隔離。
• 網(wǎng)關(guān)基于 APISIX 進(jìn)行重構(gòu)溯职，解決 Envoy OOM 及規(guī)則生效延遲較高的同時(shí)精盅，通過(guò) APISIX 產(chǎn)品化能力降低了問(wèn)題排錯(cuò)成本，降低了擴(kuò)展和配置網(wǎng)關(guān)的上手門檻谜酒。

在蜂效平臺(tái)產(chǎn)品側(cè)中叹俏，我們將需求管理與迭代部署關(guān)聯(lián)結(jié)合，并且為了支持了多種迭代流水線模式僻族。在流量管理方面粘驰，我們借助 Atlas Instance 模型中的 env 屬性以及擴(kuò)展屬性屡谐，實(shí)現(xiàn)了流量泳道能力◎蚴基于流量泳道模型愕掏，在上層產(chǎn)品側(cè)構(gòu)建迭代流量環(huán)境調(diào)用鏈路隔離。

規(guī)劃蜂效 2.0

在周邊生態(tài)建設(shè)方面籽前，Java SDK 側(cè)做到了應(yīng)用在迭代環(huán)境中可以實(shí)現(xiàn)隔離的鏈路調(diào)用亭珍，網(wǎng)關(guān)側(cè)也進(jìn)行了類似的操作。只是網(wǎng)關(guān)側(cè)作為整個(gè)流量的入口枝哄，我們是通過(guò) Cookie 的規(guī)則肄梨，也就 Cookie 的方式進(jìn)行配置的∧幼叮基線環(huán)境的流量只能到達(dá)基線環(huán)境的版本中众羡，迭代環(huán)境的流量就會(huì)轉(zhuǎn)發(fā)到迭代的版本上去。

v1 與 v2 版本的流量分配

同時(shí)在部署層的 Kubernetes 多集群管理層面蓖租，我們則借助 Karmada 實(shí)現(xiàn)了一個(gè)多 Kubernetes 集群的管理粱侣。在整個(gè)架構(gòu)中（如下圖所示），底層的能力主要是由 Kubernetes 多集群和流量網(wǎng)關(guān) Envoy 與 APISIX蓖宦、發(fā)現(xiàn)中心 Atlas齐婴、日志服務(wù)與監(jiān)控服務(wù)等組成。

而蜂效平臺(tái)在整個(gè)架構(gòu)中主要是進(jìn)行配置管理稠茂、構(gòu)建部署柠偶、擴(kuò)縮容和上下線等等，同時(shí)包含任務(wù)流的模塊睬关。最上方則是應(yīng)用市場(chǎng)的一些能力诱担，比如迭代能力和插件能力等。

蜂效平臺(tái) 2.0 架構(gòu)圖

整體來(lái)說(shuō)电爹，我們基于應(yīng)用中心和服務(wù)打造出了 2.0 新架構(gòu)蔫仙。這套新架構(gòu)在 Kubernetes 集群發(fā)生變更時(shí)，可通過(guò) PropagationPolicy丐箩、OveridePolicy 等策略摇邦，實(shí)現(xiàn) Deployment 等在 Kubernetes 集群級(jí)別的資源分發(fā)，減少集群變更時(shí)業(yè)務(wù)參與的成本雏蛮，減輕了業(yè)務(wù)研發(fā)側(cè)的一些壓力涎嚼。

網(wǎng)關(guān)選型

在 2.0 模式的架構(gòu)中，流量網(wǎng)關(guān)我們提到了兩個(gè)網(wǎng)關(guān)產(chǎn)品挑秉，即 Envoy 與 APISIX法梯。Envoy 作為之前 1.0 版本的選擇，我們并沒(méi)有完全放棄石挂，在 2.0 中我們也因?yàn)橐恍┬枨蠛彤a(chǎn)品期望救军，開(kāi)始考慮新的網(wǎng)關(guān)產(chǎn)品進(jìn)行替代，比如：

• 訪問(wèn)規(guī)則變化時(shí)啸胧，網(wǎng)關(guān)的生效速度需要控制在毫秒級(jí)（生效慢铛绰，會(huì)導(dǎo)致網(wǎng)關(guān)生效速度不一诈茧，在使用了 CDN 場(chǎng)景下可能導(dǎo)致業(yè)務(wù)資源長(zhǎng)時(shí)間 404）。
• 可在現(xiàn)有場(chǎng)景中捂掰，完全替換 Istio+Envoy 架構(gòu)敢会；同時(shí)支持 HTTP、gRPC这嚣，并兼容現(xiàn)有路由策略鸥昏。
• 需要降低問(wèn)題的排查成本，最好有產(chǎn)品化支持（如 Dashboard）姐帚。
• 產(chǎn)品足夠穩(wěn)定吏垮，社區(qū)活躍，功能強(qiáng)（對(duì)限流等場(chǎng)景支持）罐旗。
• 不需要二次開(kāi)發(fā)即可支持公司現(xiàn)有架構(gòu)的替換膳汪。
• 在替換 Istio+Envoy 架構(gòu)過(guò)程中，需要保持雙架構(gòu)可用（Istio九秀、Envoy 與新網(wǎng)關(guān)并存）遗嗽，如果新架構(gòu)有問(wèn)題可快速回退至原來(lái)方案。

在調(diào)研了一些關(guān)鍵網(wǎng)關(guān)產(chǎn)品的模型之后鼓蜒，我們最終將方案鎖定在了 Apache APISIX媳谁。APISIX 的架構(gòu)也分為控制面和數(shù)據(jù)面，同時(shí)還附帶 Dashboard 產(chǎn)品友酱。在功能使用上，APISIX 提供了豐富的插件柔纵，比如限流缔杉、熔斷、日志安全和監(jiān)控等等搁料。我們可以通過(guò) APISIX 的 Admin API 提供的接口或详，去完整操作 APISIX 的所有能力，比如 Upstream郭计、Consumer 還有各種插件等霸琴。對(duì)我們而言，APISIX 還有一個(gè)特別有優(yōu)勢(shì)的點(diǎn)昭伸，就是 APISIX 在升級(jí)時(shí)梧乘，能夠做到對(duì)低版本的 API 進(jìn)行統(tǒng)一的兼容。

APISIX 架構(gòu)

除此之外，我們認(rèn)為 APISIX 還有以下幾個(gè)優(yōu)勢(shì)：

• APISIX 基于 Openresty 的性能很好选调，相比 Envoy 來(lái)說(shuō)夹供，性能損耗很少。在經(jīng)過(guò)我們測(cè)試之后仁堪，在 QPS 的表現(xiàn)上哮洽，APISIX 損耗 3%，而 Envoy 損耗 16%弦聂；在時(shí)延表現(xiàn)上鸟辅，APISIX 平均轉(zhuǎn)發(fā)耗時(shí) 2ms，而 Envoy 耗時(shí) 7ms莺葫。數(shù)據(jù)的體現(xiàn)匪凉，已經(jīng)展示了 APISIX 在性能上的卓越優(yōu)勢(shì)。
• APISIX 還附有 Dashboard 支持徙融，對(duì)于路由匹配異常等場(chǎng)景可快速判斷是否為規(guī)則配置錯(cuò)誤洒缀。
• 作為開(kāi)源產(chǎn)品，APISIX 的社區(qū)更為活躍欺冀。在產(chǎn)品的功能上树绩，在限流、鑒權(quán)隐轩、監(jiān)控等方面相比 Envoy 成本更低饺饭，支持性更好。
• APISIX 相比 Envoy 內(nèi)存占用很低职车，但在配置的動(dòng)態(tài)變更上相比 Envoy 要弱（Envoy 幾乎大部分配置可動(dòng)態(tài)下發(fā)）瘫俊，但也足夠滿足需求。

因此悴灵，在調(diào)研與測(cè)試之后扛芽，我們?cè)谖⒎?wù) 2.0 的架構(gòu)下增添了 Apache APISIX 作為流量網(wǎng)關(guān)加入。由于網(wǎng)關(guān)是整個(gè)微服務(wù)流量的核心积瞒，如果從一套舊架構(gòu)切換到一套新的架構(gòu)川尖，其實(shí)成本是比較高的。所以我們希望微服務(wù)的網(wǎng)關(guān)規(guī)則變化能夠?qū)π屡f兩套網(wǎng)關(guān)（Envoy 與 APISIX）同時(shí)生效茫孔，也就是一套配置可以適用于兩種架構(gòu)叮喳，因此我們?cè)?2.0 架構(gòu)中，針對(duì)這些變動(dòng)做了一些調(diào)整缰贝。

落地方案與實(shí)踐問(wèn)題

首先考慮到成本問(wèn)題馍悟，對(duì)原本的 Istio 架構(gòu)保持不變，并未進(jìn)行改造剩晴。同時(shí)在網(wǎng)關(guān)架構(gòu)中锣咒，引入了新開(kāi)發(fā)的關(guān)鍵組件—— istio-apisix-translator。

istio-apisix-translator 主要是去對(duì)接 Atlas 發(fā)現(xiàn)中心以及 Istio 的 CRD 數(shù)據(jù)。作為數(shù)據(jù)同步服務(wù)宠哄，實(shí)時(shí)將 VirtualService壹将、DestinationRule 等規(guī)則變化轉(zhuǎn)換為 APISIX 路由規(guī)則，將 Atlas Instance 數(shù)據(jù)實(shí)時(shí)轉(zhuǎn)換為 APISIX Upstream 規(guī)則等毛嫉。簡(jiǎn)單來(lái)說(shuō)诽俯，就是通過(guò)這樣一個(gè)服務(wù)組件，實(shí)現(xiàn)了對(duì) Atlas 以及 Istio CRD 的數(shù)據(jù)支持承粤。

借助這種架構(gòu)暴区，我們就實(shí)現(xiàn)了對(duì)兩種網(wǎng)關(guān)的完整支持，如下圖所示辛臊。

蜂效 2.0 微服務(wù)網(wǎng)關(guān)架構(gòu)

網(wǎng)關(guān)架構(gòu)的核心部分則是圖中最下方的 APISIX仙粱，上層的 istio-apisix-translator 則充當(dāng)類似 Istio 架構(gòu)中的 Pilot 角色，將 Instance 與 CR 數(shù)據(jù)整合后彻舰，借由 APISIX Admin API 推送至 APISIX 中伐割，實(shí)例則是對(duì)接到內(nèi)部業(yè)務(wù)的 Atlas 發(fā)現(xiàn)中心。因此刃唤，無(wú)論是訪問(wèn)規(guī)則發(fā)生變化還是 Atlas 的數(shù)據(jù)源發(fā)生變化隔心，都可以將這份數(shù)據(jù)變化轉(zhuǎn)換成 APISIX 的數(shù)據(jù)推到 APISIX 中。目前全鏈路都是基于 Watch 機(jī)制保證數(shù)據(jù)變化的實(shí)時(shí)處理尚胞，因此在實(shí)際應(yīng)用場(chǎng)景下硬霍，基本可以達(dá)到數(shù)據(jù)變化的毫秒級(jí)生效。

當(dāng)然笼裳，在使用 APISIX 的過(guò)程中唯卖，我們也遇到了幾處問(wèn)題。但均已解決并將結(jié)果同步給了社區(qū)進(jìn)行反饋躬柬。

第一個(gè)問(wèn)題就是在 APISIX 使用證書(shū)對(duì)接 etcd 時(shí)拜轨，如果 APISIX 節(jié)點(diǎn)較多，可能會(huì)導(dǎo)致 APISIX Admin API 接口響應(yīng)非常慢允青。這個(gè)問(wèn)題的原因是因?yàn)槟壳?etcd 存在一個(gè)關(guān)于 HTTP/2 的 BUG撩轰。如果通過(guò) HTTPS 操作 etcd（HTTP 不受影響），HTTP/2 的連接數(shù)上限為 Golang 默認(rèn)的 250 個(gè)昧廷。而 APISIX 的控制面和 Istio 架構(gòu)的控制面有區(qū)別，APISIX 節(jié)點(diǎn)是直連 etcd偎箫，當(dāng) APISIX 數(shù)據(jù)面節(jié)點(diǎn)數(shù)較多時(shí)木柬，一旦所有 APISIX 節(jié)點(diǎn)與 etcd 連接數(shù)超過(guò)這個(gè)上限，則 APISIX 的接口響應(yīng)會(huì)非常的慢淹办。

為了解決這個(gè)問(wèn)題眉枕，我們也在 etcd 和 APISIX 的社區(qū)均進(jìn)行了反饋，后續(xù)也通過(guò)升級(jí)版本（etcd 3.4 升級(jí)到 3.4.20 及以上，etcd 3.5 升級(jí)到 3.5.5 及以上）解決了這個(gè)問(wèn)題速挑。同時(shí)我們也已將這個(gè)結(jié)果同步到了 APISIX 社區(qū)官網(wǎng) Q&A 文檔中谤牡，方便后續(xù)用戶遇到同樣問(wèn)題時(shí)，可以有所參考姥宝。

第二個(gè)問(wèn)題就是在使用 APISIX 的過(guò)程中會(huì)遇到性能抖動(dòng)的問(wèn)題翅萤。

首先是會(huì)出現(xiàn) 499 響應(yīng)抖動(dòng)，這個(gè)問(wèn)題主要出現(xiàn)在連續(xù)兩次以上過(guò)快的 post 請(qǐng)求（也不止 post）的場(chǎng)景下腊满。這種情況是 NGINX 認(rèn)定為不安全的連接套么，則主動(dòng)斷開(kāi)了客戶端的連接。為了處理這個(gè)問(wèn)題碳蛋，只需將 proxy_ignore_client_abort 的配置調(diào)整為 on 即可胚泌。

除此之外，當(dāng) APISIX Admin API 接口請(qǐng)求密集時(shí)肃弟，也會(huì)出現(xiàn) APISIX 數(shù)據(jù)面少部分響應(yīng)超時(shí)的狀況玷室。這個(gè)主要是因?yàn)?istio-apisix-translator 在重啟時(shí)，會(huì)將 Atlas笤受、Istio CR 數(shù)據(jù)聚合穷缤，全量同步至 APISIX 中，大量請(qǐng)求引發(fā) APISIX 數(shù)據(jù)變更感论，APISIX 數(shù)據(jù)面密集的同步變更導(dǎo)致小部分響應(yīng)超時(shí)绅项。為此，我們引入?yún)f(xié)程池和令牌桶限流比肄，減少 APISIX 數(shù)據(jù)密集變更的場(chǎng)景來(lái)應(yīng)對(duì)此問(wèn)題快耿。

總結(jié)與發(fā)展

馬蜂窩當(dāng)前是基于 Kubernetes 容器部署以及基于 Consul 的機(jī)器部署場(chǎng)景，自建 Atlas 服務(wù)發(fā)現(xiàn)中心芳绩，同時(shí)掀亥，在 Java 生態(tài)、微服務(wù)網(wǎng)關(guān)妥色，微服務(wù)體系的流量泳道搪花，以及監(jiān)控體系做對(duì)接和適配。

在微服務(wù)網(wǎng)關(guān)前期嘹害，是基于 Istio 1.5.10 對(duì) Pilot 二次開(kāi)發(fā)撮竿，也在網(wǎng)關(guān)側(cè)支持非容器部署場(chǎng)景。目前階段則是保持了 Istio+Envoy 架構(gòu)與 APISIX 架構(gòu)同時(shí)支持笔呀，通過(guò)引入外部服務(wù)組件幢踏，讓 APISIX 也復(fù)用 Istio CRD 資源。

從網(wǎng)關(guān)發(fā)展視角來(lái)看许师，未來(lái)我們也會(huì)跟隨網(wǎng)關(guān)的一些趨勢(shì)房蝉。比如現(xiàn)在很多產(chǎn)品都開(kāi)始支持 Gateway API僚匆，像 APISIX Ingress、Traefik搭幻、Contour 等咧擂；同時(shí)網(wǎng)關(guān)的動(dòng)態(tài)化配置也是未來(lái)非常明顯的趨勢(shì)，對(duì)于運(yùn)維或者基礎(chǔ)研發(fā)的同學(xué)來(lái)說(shuō)檀蹋，在后續(xù)考慮網(wǎng)關(guān)架構(gòu)的選型和迭代時(shí)松申，也可以更多關(guān)注網(wǎng)關(guān)動(dòng)態(tài)配置的方面。