[[343325]]

今天討論下在微服務(wù)架構(gòu)實(shí)踐中經(jīng)常遇到的一些問題的思考，其中有些來源于我們自己的微服務(wù)改造項(xiàng)目，有些來源于客戶現(xiàn)場(chǎng)微服務(wù)架構(gòu)實(shí)施項(xiàng)目和售前方案溝通。

本文僅針對(duì)關(guān)鍵問題點(diǎn)進(jìn)行討論，具體如下：

• 微服務(wù)下數(shù)據(jù)庫(kù)劃分
• 微服務(wù)開發(fā)和技術(shù)框架的選擇
• 微服務(wù)和DevOps，容器云集成
• 微服務(wù)網(wǎng)關(guān)和注冊(cè)中心
• 微服務(wù)相關(guān)關(guān)鍵技術(shù)，如限流熔斷，安全，服務(wù)鏈監(jiān)控等

對(duì)于微服務(wù)相關(guān)的基礎(chǔ)知識(shí)，大家在網(wǎng)上基本都可以搜索到就不再重復(fù)敘述，對(duì)于SOA和微服務(wù)，中臺(tái)架構(gòu)等的區(qū)別等，也可以參考我前面發(fā)布過的文章。

數(shù)據(jù)庫(kù)拆分是否和微服務(wù)必須1對(duì)1

在最早談微服務(wù)架構(gòu)的時(shí)候我們就談到。要確保每個(gè)微服務(wù)都獨(dú)立自治和松耦合，那么微服務(wù)從數(shù)據(jù)庫(kù)到邏輯層到前臺(tái)全部都要進(jìn)行縱向拆分。

即數(shù)據(jù)庫(kù)的拆分是整個(gè)微服務(wù)架構(gòu)設(shè)計(jì)中的一個(gè)關(guān)鍵內(nèi)容。

而這里有一個(gè)關(guān)鍵思考就是，在微服務(wù)實(shí)踐中你會(huì)看到，實(shí)際上你上層的微服務(wù)組件的拆分相當(dāng)來說會(huì)更加細(xì)，一個(gè)不算復(fù)雜的業(yè)務(wù)系統(tǒng)拆分到20到30個(gè)微服務(wù)組件都是正常情況。

而對(duì)于數(shù)據(jù)庫(kù)也拆分為20個(gè)獨(dú)立的DataBase顯然不合理。

這個(gè)一方面是增加了數(shù)據(jù)庫(kù)本身的管理復(fù)雜度，同時(shí)由于數(shù)據(jù)庫(kù)的太細(xì)拆分也引入了更多的分布式事務(wù)處理問題，跨庫(kù)數(shù)據(jù)關(guān)聯(lián)查詢不方便等問題。因此在這里，最好的建議是我們引入一個(gè)業(yè)務(wù)域的概念，即：

可以按業(yè)務(wù)域來進(jìn)行數(shù)據(jù)庫(kù)拆分，每一個(gè)業(yè)務(wù)域相當(dāng)獨(dú)立并對(duì)應(yīng)一個(gè)獨(dú)立數(shù)據(jù)庫(kù)，但是業(yè)務(wù)域里面本身可以有多個(gè)上層的微服務(wù)模塊組件。同一個(gè)業(yè)務(wù)域里面的微服務(wù)仍然通過注冊(cè)中心進(jìn)行訪問和調(diào)用。

即同一個(gè)業(yè)務(wù)域里面的微服務(wù)在邏輯層本身還是解耦的，只能夠通過API接口訪問調(diào)用，以方便分布式部署，但是數(shù)據(jù)庫(kù)層本身不拆分，共享同一個(gè)數(shù)據(jù)庫(kù)。

比如在我們的項(xiàng)目里面，我們會(huì)將4A和流程引擎兩個(gè)微服務(wù)共享一個(gè)數(shù)據(jù)庫(kù)，將費(fèi)用報(bào)賬，差旅報(bào)賬，借款報(bào)賬等獨(dú)立微服務(wù)共享一個(gè)報(bào)賬數(shù)據(jù)庫(kù)。

在這種方式下雖然沒有實(shí)現(xiàn)數(shù)據(jù)庫(kù)的徹底解耦，但是通過在邏輯層的微服務(wù)拆分和解耦，我們可以實(shí)現(xiàn)微服務(wù)部署包的更加細(xì)粒度管理。同時(shí)當(dāng)存在業(yè)務(wù)邏輯變更的時(shí)候，我們也僅僅需要變更相應(yīng)的微服務(wù)模塊，做到變更影響最小化目的。

是否使用SpringCloud全家桶

可以看到如果采用SpingCLoud微服務(wù)技術(shù)開發(fā)框架，那么對(duì)應(yīng)服務(wù)注冊(cè)中心，限流熔斷，微服務(wù)網(wǎng)關(guān)，負(fù)載均衡，配置中心，安全，聲明式調(diào)用所有能力全部提供。

你需要做的就是采用SpringBoot框架來開發(fā)一個(gè)個(gè)微服務(wù)組件即可。

當(dāng)然在我們實(shí)施的項(xiàng)目里面也存在另外一種方式，即只使用SpringBoot框架進(jìn)行單個(gè)微服務(wù)組件的開發(fā)，其次再去組合和集成當(dāng)前業(yè)界主流的微服務(wù)開源技術(shù)組件產(chǎn)品。

• 服務(wù)注冊(cè)中心：阿里的Nacos注冊(cè)中心
• 服務(wù)配置中心：攜程開源的Apollo配置中心
• 限流熔斷：阿里的Sentinel
• 服務(wù)鏈監(jiān)控：直接對(duì)SkyWalking服務(wù)鏈監(jiān)控進(jìn)行集成
• API網(wǎng)關(guān)：采用Kong網(wǎng)關(guān)來實(shí)現(xiàn)API集成和管控治理

當(dāng)然你也可能完全不采用SpringBoot，而是走更加高效的支持RPC調(diào)用的Dubbo開源框架進(jìn)行微服務(wù)組件的開發(fā)和集成。

如果從微服務(wù)技術(shù)平臺(tái)的構(gòu)建和快速開發(fā)上來說，當(dāng)然是你直接選擇SpingCLoud整個(gè)開源框架和組件來實(shí)現(xiàn)最簡(jiǎn)單，而且基本也完全能夠滿足需求。對(duì)于日常傳統(tǒng)企業(yè)應(yīng)用來說，性能完全足夠，也不存在說性能無法滿足的情況。畢竟不是所有項(xiàng)目都類似互聯(lián)網(wǎng)存在海量數(shù)據(jù)訪問和大并發(fā)下的高性能要求。

如果采用各種開源組件，技術(shù)框架自己集成，那么肯定是存在前期的基礎(chǔ)技術(shù)平臺(tái)搭建，集成驗(yàn)證等相關(guān)的工作量。同時(shí)本身也會(huì)增加整個(gè)基礎(chǔ)架構(gòu)的復(fù)雜度。比如你采用了Nacos注冊(cè)中心，對(duì)于注冊(cè)中心你同樣需要去進(jìn)行集群化配置，以滿足高可用性的需求。

綜合以上描述，簡(jiǎn)單總結(jié)就是：

• 如果圖省事，沒有太高性能要求，直接采用SpingCloud整體框架
• 如果性能要求高，自己技術(shù)儲(chǔ)備足夠，可以自己進(jìn)行開源技術(shù)組件集成

那么在我們實(shí)際的微服務(wù)架構(gòu)實(shí)施項(xiàng)目里面，我們會(huì)看到第三個(gè)場(chǎng)景。

比如一個(gè)集團(tuán)型企業(yè)，本身一個(gè)計(jì)劃管理系統(tǒng)進(jìn)行前期架構(gòu)設(shè)計(jì)后拆分為10個(gè)微服務(wù)模塊，需要招標(biāo)三家軟件開發(fā)商來定制開發(fā)。對(duì)開發(fā)商要求也是進(jìn)行微服務(wù)架構(gòu)化開發(fā)。

在這個(gè)時(shí)候我們就發(fā)現(xiàn)一個(gè)關(guān)鍵問題，各個(gè)廠家自己采用微服務(wù)架構(gòu)沒有關(guān)系，但是從整個(gè)大應(yīng)用角度我們實(shí)際上是存在對(duì)10個(gè)微服務(wù)模塊進(jìn)行統(tǒng)一的微服務(wù)治理和管控需求的。類似API網(wǎng)關(guān)，類似服務(wù)配置中心等。

而這些組件就不太適合再使用SpingCLoud里面的技術(shù)組件，而是需要從單個(gè)微服務(wù)架構(gòu)體系里面提取出來，形成一個(gè)共享的服務(wù)能力。在這種時(shí)候，我們的建議就是盡量去集成和使用第三方的其它開源技術(shù)組件來進(jìn)行管控治理。

比如上面這個(gè)例子，三家供應(yīng)商可以保留最基礎(chǔ)的配置。

即某家供應(yīng)商開發(fā)A，B，C三個(gè)微服務(wù)模塊的時(shí)候，可以啟用Eureka+Feign+Ribbon來完成自己開發(fā)的三個(gè)組件的內(nèi)部集成，API接口注冊(cè)和調(diào)用。

但是三個(gè)供應(yīng)商之間的模塊要協(xié)同的時(shí)候則統(tǒng)一使用外部搭建的共享技術(shù)服務(wù)平臺(tái)。

• 比如API接口注冊(cè)到統(tǒng)一的Kong網(wǎng)關(guān)上，Kong網(wǎng)關(guān)由平臺(tái)集成商管理
• 比如涉及到三家的一些共性配置由SpingCloud Config統(tǒng)一轉(zhuǎn)到Apollo配置中心

因此再簡(jiǎn)單總結(jié)下就是，評(píng)估是否采用SpingCLoud全套方案的時(shí)候，還需要評(píng)估是否存在跨有明確邊界的團(tuán)隊(duì)協(xié)同的情況。或者是否存在類似集團(tuán)型企業(yè)，多個(gè)業(yè)務(wù)系統(tǒng)微服務(wù)大集成的情況。如果存在，那么一些共性技術(shù)服務(wù)能力就必須抽出獨(dú)立建設(shè)。

開發(fā)團(tuán)隊(duì)如何拆分的問題？

我們?cè)趯?shí)施微服務(wù)和云原生轉(zhuǎn)型的時(shí)候，你看起來好像是IT系統(tǒng)分為了多個(gè)微服務(wù)，但是更加重要的是業(yè)務(wù)組織和團(tuán)隊(duì)本身需要分解為微服務(wù)，分解高度獨(dú)立自治的業(yè)務(wù)團(tuán)隊(duì)。

每個(gè)團(tuán)隊(duì)都配置獨(dú)立的前后端開發(fā)，需求，測(cè)試人員高度自治。

那么在拆分為多為業(yè)務(wù)團(tuán)隊(duì)后，如何保證原來一個(gè)大應(yīng)用和產(chǎn)品的概念一致性或架構(gòu)完整性。在這里我們提出，對(duì)于整體的產(chǎn)品規(guī)劃和總體架構(gòu)設(shè)計(jì)仍然需要集中化統(tǒng)一進(jìn)行，然后在拆分和分配到各個(gè)微服務(wù)開發(fā)團(tuán)隊(duì)。

那么這里的架構(gòu)設(shè)計(jì)包括哪些內(nèi)容呢？具體如下：

• 各個(gè)微服務(wù)模塊的功能列表清單
• 各個(gè)微服務(wù)模塊的接口清單
• 數(shù)據(jù)庫(kù)的拆分和數(shù)據(jù)表的Owner歸屬

以上三點(diǎn)就是最重要的架構(gòu)設(shè)計(jì)需要提前進(jìn)行的點(diǎn)。這個(gè)清楚后即可以分配到各個(gè)微服務(wù)團(tuán)隊(duì)，那么微服務(wù)團(tuán)隊(duì)高度自治和扁平化，各個(gè)團(tuán)隊(duì)之間之間進(jìn)行協(xié)同和溝通，而不需要再通過架構(gòu)師來協(xié)同增加溝通路徑。

即產(chǎn)品規(guī)劃和架構(gòu)師很類似微服務(wù)架構(gòu)里面的注冊(cè)控制中心的職責(zé)。這也是我們常說的技術(shù)上的微服務(wù)拆分，實(shí)際上真正先行的業(yè)務(wù)組織團(tuán)隊(duì)的架構(gòu)調(diào)整和職責(zé)拆分。

那么這個(gè)開發(fā)團(tuán)隊(duì)如何拆？

首先不可能你拆分了20個(gè)微服務(wù)，就拆分出20個(gè)開發(fā)團(tuán)隊(duì)。這里面仍然有域劃分的概念在里面，即對(duì)20個(gè)微服務(wù)還要進(jìn)行歸類，以方面拆分。

• 方式1：按縱向業(yè)務(wù)域進(jìn)行歸類，參考我們前面數(shù)據(jù)庫(kù)拆分方法
• 方式2：按橫向分層歸類，比如平臺(tái)層團(tuán)隊(duì)，中臺(tái)層團(tuán)隊(duì)，前臺(tái)和APP應(yīng)用團(tuán)隊(duì)

在團(tuán)隊(duì)拆分后，我們可以看到每一個(gè)開發(fā)小組必須配置前端開發(fā)，后端開發(fā)和測(cè)試人員。對(duì)于需求可以統(tǒng)一進(jìn)行配置不拆分到開發(fā)組。當(dāng)然也可以每個(gè)開發(fā)組配置一個(gè)需求細(xì)化人員，而僅僅在整個(gè)大團(tuán)隊(duì)配置產(chǎn)品經(jīng)理出產(chǎn)品需求。對(duì)產(chǎn)品需求的細(xì)化還是到開發(fā)組內(nèi)部完成。

為何如此強(qiáng)調(diào)開發(fā)團(tuán)隊(duì)要拆？

簡(jiǎn)單來說，就是各個(gè)開發(fā)團(tuán)隊(duì)內(nèi)部的工作應(yīng)該是對(duì)其它開發(fā)團(tuán)隊(duì)透明不可見的。開發(fā)團(tuán)隊(duì)之間高度直治，只能夠通過粗粒度的接口交付。

如果開發(fā)團(tuán)隊(duì)本身不拆分，你會(huì)看到，一個(gè)開發(fā)團(tuán)隊(duì)管理多個(gè)微服務(wù)模塊的時(shí)候，我們?cè)谇懊嬷朴喌母鞣N微服務(wù)開發(fā)規(guī)范，規(guī)約等很容易就被破壞，而這些事后審計(jì)和修改都會(huì)花費(fèi)大量的時(shí)間進(jìn)行變更和返工。

舉個(gè)簡(jiǎn)單的例子，拆分為2個(gè)DataBase庫(kù)后，同一個(gè)開發(fā)人員管理的時(shí)候，往往就省事的通過兩個(gè)庫(kù)間的跨庫(kù)關(guān)聯(lián)查詢來解決問題，而這在微服務(wù)開發(fā)規(guī)約里面是不允許的。

當(dāng)然從軟件企業(yè)本身的IT治理管控來說，這也是最好的方案，對(duì)于一個(gè)大項(xiàng)目或大應(yīng)用系統(tǒng)，并不是每個(gè)開發(fā)人員都能夠看到所有項(xiàng)目模塊源代碼，其它非自己Owner的組件只能夠消費(fèi)和使用接口，其它內(nèi)容都是不可見。

對(duì)于服務(wù)注冊(cè)中心和API網(wǎng)關(guān)選擇

對(duì)于服務(wù)注冊(cè)中心和API網(wǎng)關(guān)，在前面我有專門文章詳細(xì)分析。

什么時(shí)候需要使用API網(wǎng)關(guān)？

如果一個(gè)微服務(wù)架構(gòu)下，雖然不會(huì)外部的其它應(yīng)用進(jìn)行交互和集成，但是整個(gè)應(yīng)用本身存在APP應(yīng)用端，而APP應(yīng)用端通過前后端分析開發(fā)，同時(shí)需要通過互聯(lián)網(wǎng)訪問。本身存在需要一個(gè)統(tǒng)一訪問API訪問入口，同時(shí)也需要考慮和內(nèi)部微服務(wù)模塊進(jìn)一步進(jìn)行安全隔離。

當(dāng)我們談到這里的時(shí)候，你會(huì)發(fā)現(xiàn)我們常說的API網(wǎng)關(guān)的服務(wù)代理或透?jìng)髂芰Γ瑢?shí)際和我們常說的Ngnix反向代理或路由是一個(gè)意思。

如果你僅僅是為了統(tǒng)一API接口的訪問出口，并考慮類似DMZ區(qū)的安全隔離，那么在你架構(gòu)前期完全不需要馬上實(shí)施API網(wǎng)關(guān)，直接采用Ngnix進(jìn)行服務(wù)路由代理即可。因?yàn)樵谶@種架構(gòu)下，API接口消費(fèi)端，提供端全部是一個(gè)開發(fā)團(tuán)隊(duì)開發(fā)，各種問題分析排查都相當(dāng)方便，類似API接口安全訪問等也可以通過JWT，Auth2.0等統(tǒng)一實(shí)現(xiàn)，而且這個(gè)過程也并不復(fù)雜。

能力開放或多應(yīng)用外部集成對(duì)API管控治理需要

但是當(dāng)我們面臨是和多個(gè)外部應(yīng)用集成，或者說將自己的API接口服務(wù)能力開放給外部多個(gè)合作伙伴使用的時(shí)候，這個(gè)時(shí)候?qū)τ贏PI接口的管控治理要求自然增加。

即在常規(guī)的服務(wù)代理路由基礎(chǔ)上，需要增加類似負(fù)載均衡，安全，日志，限流熔斷等各種能力，而且我們不希望這些能力在API接口開發(fā)的時(shí)候考慮，而是希望這些能力是在API接入到網(wǎng)關(guān)的時(shí)候統(tǒng)一靈活配置來實(shí)現(xiàn)管控。

那么這個(gè)時(shí)候使用API網(wǎng)關(guān)作用就體現(xiàn)出來。

多個(gè)開發(fā)團(tuán)隊(duì)協(xié)同，服務(wù)治理標(biāo)準(zhǔn)化需要

這個(gè)是我理解的需要API網(wǎng)關(guān)的第二個(gè)場(chǎng)景，這個(gè)有點(diǎn)類似于傳統(tǒng)IT架構(gòu)下對(duì)ESB服務(wù)總線的需求。當(dāng)存在多個(gè)開發(fā)團(tuán)隊(duì)的時(shí)候，我們就需要對(duì)各個(gè)開發(fā)團(tuán)隊(duì)注冊(cè)和接入的API接口服務(wù)進(jìn)行統(tǒng)一管理，而這個(gè)時(shí)候就需要有API網(wǎng)關(guān)來實(shí)現(xiàn)。

即跨開發(fā)團(tuán)隊(duì)的API接口集成交付的統(tǒng)一管控都由API網(wǎng)關(guān)來復(fù)制，包括安全，日志審計(jì)，流量控制等，這些內(nèi)容在多團(tuán)隊(duì)協(xié)同的時(shí)候不可能再依賴單個(gè)團(tuán)隊(duì)內(nèi)部的一些技術(shù)，開發(fā)規(guī)范約定，而是需要有一個(gè)統(tǒng)一的標(biāo)準(zhǔn)。

同時(shí)多個(gè)開發(fā)團(tuán)隊(duì)協(xié)同和集成，必須有一個(gè)統(tǒng)一的集成方來解決協(xié)同中的問題。即使是在ServiceMesh服務(wù)網(wǎng)格架構(gòu)下，我們也可以看到有一個(gè)控制中心來統(tǒng)一協(xié)調(diào)。

在使用API網(wǎng)關(guān)后技術(shù)組件的選擇上

注意，對(duì)于API網(wǎng)關(guān)本身具備負(fù)載均衡，限流熔斷，服務(wù)代理的能力。

即在注冊(cè)中心下，Eureka+Feign+Ribbon+Hystrix全部可以轉(zhuǎn)由API網(wǎng)關(guān)來完成。但是一個(gè)應(yīng)用的完整微服務(wù)架構(gòu)可能存在一個(gè)API接口既要滿足內(nèi)部組件的API消費(fèi)調(diào)用，又需要將該接口通過API網(wǎng)關(guān)暴露給外部應(yīng)用使用。

通過API網(wǎng)關(guān)對(duì)外保留Http Rest API接口，傳統(tǒng)API消費(fèi)訪問而不再是類似Feign聲明式方式進(jìn)行類似內(nèi)部API接口方式調(diào)用。如下圖：

可以看到，微服務(wù)A既需要滿足內(nèi)部微服務(wù)B作為消費(fèi)方，通過服務(wù)注冊(cè)中心進(jìn)行消費(fèi)調(diào)用，也需要滿足外部APP通過API網(wǎng)關(guān)接口進(jìn)行消費(fèi)調(diào)用。

那么進(jìn)入到微服務(wù)A集群的流量實(shí)際上是沒有一個(gè)統(tǒng)一的入口的。

在這種場(chǎng)景下如果企業(yè)了Hystrix限流熔斷，那么也僅僅是對(duì)內(nèi)部的微服務(wù)模塊組件間的消費(fèi)調(diào)用進(jìn)行控制。而對(duì)于外部APP限流，仍然還需要啟用網(wǎng)關(guān)上的限流熔斷功能。

微服務(wù)架構(gòu)和容器云集成的集群和負(fù)載均衡

最后談下微服務(wù)架構(gòu)和Kubernetes+Docker容器云集成后的服務(wù)發(fā)現(xiàn)和負(fù)載均衡問題。

前面談到在采用Eureka服務(wù)注冊(cè)中心的時(shí)候，對(duì)于同一個(gè)微服務(wù)模塊A，我們可以啟動(dòng)多個(gè)微服務(wù)實(shí)例，不同的端口號(hào)。在端口啟動(dòng)后通過Eureka來實(shí)現(xiàn)服務(wù)的自動(dòng)注冊(cè)和發(fā)現(xiàn)。然后通過Ribbon來實(shí)現(xiàn)服務(wù)訪問的負(fù)載均衡處理。

也就是說我們添加和部署微服務(wù)模塊A節(jié)點(diǎn)是手工完成的。

但是在DevOps持續(xù)集成下，在實(shí)施Kubernetes+Docker容器云后，我們可以通過k8s來實(shí)現(xiàn)微服務(wù)節(jié)點(diǎn)資源的動(dòng)態(tài)擴(kuò)展。擴(kuò)展的Pod資源統(tǒng)一由Kubernetes來實(shí)現(xiàn)集群負(fù)載均衡均衡，即對(duì)外只需要通過Node+端口號(hào)訪問即可。

所以在這個(gè)時(shí)候?qū)嶋H有兩種做法。

做法1：不再使用Eureka服務(wù)注冊(cè)和發(fā)現(xiàn)

在這種時(shí)候，不再使用Eureka服務(wù)注冊(cè)發(fā)現(xiàn)，而是通過Kubernates動(dòng)態(tài)部署后的VIP進(jìn)行訪問，由Kubernates來進(jìn)行后臺(tái)節(jié)點(diǎn)的負(fù)載均衡。

這個(gè)時(shí)候我們只能夠按常規(guī)調(diào)用Http Rest API接口的方式進(jìn)行接口消費(fèi)和調(diào)用，類似原來的Feign聲明式調(diào)用可能不再適合。也就是說在這種場(chǎng)景下你只使用SpringBoot開發(fā)獨(dú)立的能夠暴露Http Rest API接口的微服務(wù)。不再使用SpringCLoud框架中的Eureka+Feign+Ribbon。

做法2：采用Eureka來替代Kubernetes中的Service

在這種場(chǎng)景下，即不使用Kubernetes本身的集群功能，而是將動(dòng)態(tài)部署出來的微服務(wù)模塊還是自動(dòng)化注冊(cè)到Eureka服務(wù)注冊(cè)中心統(tǒng)一管理。也就是還是按傳統(tǒng)的SpringCLoud框架體系來進(jìn)行架構(gòu)搭建。

在這種思路下可以進(jìn)一步保留SpingCLoud下的限流，容錯(cuò)，心跳監(jiān)測(cè)等方面的關(guān)鍵能力。

做法3：進(jìn)一步的思路還是ServiceMesh

實(shí)際上我們看到進(jìn)一步的思路還是類似Istio的完全去中心化微服務(wù)治理方案。在這種模式下可以更好的通過Sidecar來實(shí)現(xiàn)相關(guān)服務(wù)注冊(cè)，發(fā)現(xiàn)，限流熔斷，安全等各種關(guān)鍵服務(wù)治理管控能力。

如果微服務(wù)模塊全部是通過Kubernetes部署到Docker容器里面，那么我們可以看到完全可以在k8s進(jìn)行鏡像制作和容器部署的時(shí)候?qū)ideCar的內(nèi)容附加到具體的部署包里面實(shí)現(xiàn)集成。

簡(jiǎn)單來說，就是：

我們?cè)陂_發(fā)微服務(wù)模塊的時(shí)候完全不需要考慮太多的分布式API接口集成交互，但是和Kubernetes和Service Mesh集成后就具備了分布式接口調(diào)用和集成的能力。同時(shí)也具備了對(duì)API接口的安全，日志，限流熔斷的管理能力。